On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote:
> Am Sat, 28 Apr 2012 15:39:49 -0400
> schrieb "Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com>:
>
>> "q66" <quaker66@gmail.com> wrote in message news:ihqjguujvoukhlqcwkyi@forum.dlang.org...
>> >
>> > - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl
>> > - Properties - they're kinda broken at this point and the value is questionable
>> > - @trusted @system
>> > - Exception handling - a lot of runtime, questionable value
>> 
>> That's just craziness!
>
> Madness even! AAs are soon mostly in the library and that's a good trade-off; @trusted @system needs to be there as long as there is @safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each.
> I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly.
> I can agree on the rest.


I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation.

On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis wrote:
> But even just storing it in a local variable to use later
> could destroy the locality enough to defeat LDC's optimization.

Huh? I can't think of a situation where a hash table lookup would entail less indirections than dereferencing a pointer stored in a register (resp. the stack, depending on scheduling).

David

"SomeDude" <lovelydear@mailmetrash.com> wrote in message news:jrdmqmchgbibqmrwzwsk@forum.dlang.org...
> On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote:
>> Am Sat, 28 Apr 2012 15:39:49 -0400
>>
>> Madness even! AAs are soon mostly in the library and that's a good trade-off; @trusted @system needs to be there as long as there is @safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each. I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. I can agree on the rest.
>
>
> I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation.

There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that "behind the scenes" their implementation will move from DMD to Druntime.

"Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com> wrote in message news:jnit81$29uh$1@digitalmars.com...
> "SomeDude" <lovelydear@mailmetrash.com> wrote in message news:jrdmqmchgbibqmrwzwsk@forum.dlang.org...
>> On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote:
>>> Am Sat, 28 Apr 2012 15:39:49 -0400
>>>
>>> Madness even! AAs are soon mostly in the library and that's a good trade-off; @trusted @system needs to be there as long as there is @safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each. I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. I can agree on the rest.
>>
>>
>> I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation.
>
> There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that "behind the scenes" their implementation will move from DMD to Druntime.
>

In fact, don't regular arrays already work like this?

On Sunday, April 29, 2012 10:07:38 David Nadlinger wrote:
> On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis
> 
> wrote:
> > But even just storing it in a local variable to use later could destroy the locality enough to defeat LDC's optimization.
> 
> Huh? I can't think of a situation where a hash table lookup would entail less indirections than dereferencing a pointer stored in a register (resp. the stack, depending on scheduling).

If you have something like

if(key in aa)
{
    // lots of code
    func(aa[key]);
}

the compiler is not necessarily going to be able to determine that the AA has not been changed such that aa[key] can use the same lookup that key in aa did rather than redoing the lookup. A prime example would be

if(key in aa)
{
    foo(aa);
    func(aa[key]);
}

The compiler doesn't necessarily know that foo won't remove key from aa, so it can't save the result of key in aa to reuse rather than calling aa[key], whereas the programmer could know that foo doesn't do anything to aa which would make a pointer to the element invalid and can guarantee that only one lookup occurs by doing

if(auto value = key in aa)
{
    foo(aa);
    func(value);
}

And that's just one case where the compiler can't make such an optimization but the programmer can. It's _far_ better iMHO to have in return a pointer than to rely on the compiler removing extraneous lookups.

- Jonathan M Davis

On Sunday, 29 April 2012 at 01:06:54 UTC, bearophile wrote:
> retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient.
> Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases...

Slightly related: For this:

---
import core.stdc.stdio;
import std.algorithm;
import std.range;

void main() {
  int sum;
  foreach (i; retro(iota(11))) sum += i;
  printf("%d\n", sum);
}
---

LDC produces
---
__Dmain:
	pushq	%rax
	movl	$0x00000037,%esi
	xorb	%al,%al
	leaq	_.str24(%rip),%rdi # str24 = "%d\n"
	callq	_printf
	xorl	%esi,%esi
	movl	%eax,0x04(%rsp)
	movl	%esi,%eax
	popq	%rdx
	ret
---

Now that's constant folding… ;)

David

On Sunday, 29 April 2012 at 08:20:59 UTC, Jonathan M Davis wrote:
> The compiler doesn't necessarily know that foo won't remove key from aa, so it
> can't save the result of key in aa to reuse rather than calling aa[key],
> whereas the programmer could know that foo doesn't do anything to aa which
> would make a pointer to the element invalid and can guarantee that only one
> lookup occurs by doing
> […]

Yes, point taken, but what does this have to do with locality?

David

On 04/29/2012 06:36 AM, Andrej Mitrovic wrote:
> On 4/29/12, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>> - 'in' operator returning a pointer to the element.
>
> AFAIK this is a property of how the opIn_r function is implemented,
> nothing much to do with the language itself.
>

Well, AAs are part of the language.

> But it does allow for some neat tricks, like:
>
>      int[int] hash;
>      hash[1] = 2;
>      int value = *enforce(1 in hash, new Exception("1 not in hash"));
>      assert(value == 2);
> or:
>      if (auto val = 1 in hash)
>          ...use val pointer (+ if it's a class/struct pointer you still
> have access to the dot syntax)
>      else
>          ... errors..

I know, but 'in' is somewhat of a misnomer. Anyway, it is not a huge issue.

On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote:
>
> There will still be sugar in the compiler so they appear to be builtins.
> When the switch happens, I'm sure it'll be transparent - average users
> probably won't even notice. It's just that "behind the scenes" their
> implementation will move from DMD to Druntime.

Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good.

I'd rather keep the integrated the AAs, which are fine for most applications, and have templated AAs in the library for heavier use. Even though it may seem redundant, it's just as redundant as having arrays in the core language and std.array. Noone would want to remove arrays from the core language, right ?

On Sunday, April 29, 2012 10:22:44 David Nadlinger wrote:
> On Sunday, 29 April 2012 at 08:20:59 UTC, Jonathan M Davis wrote:
> > The compiler doesn't necessarily know that foo won't remove key
> > from aa, so it
> > can't save the result of key in aa to reuse rather than calling
> > aa[key],
> > whereas the programmer could know that foo doesn't do anything
> > to aa which
> > would make a pointer to the element invalid and can guarantee
> > that only one
> > lookup occurs by doing
> > […]
> 
> Yes, point taken, but what does this have to do with locality?

I think that you're thinking of something completely different about the term locality than I meant. I meant locality in terms of how close the aa[key] expression was to the key in aa expression within the function - i.e. how local they were to each other. I may have misused the term though. I don't know.

- Jonathan M Davis