On Thursday, 15 March 2012 at 10:39:04 UTC, Steven Schveighoffer wrote:
> On Thu, 15 Mar 2012 06:19:33 -0400, Jacob Carlborg
>>
>> I think object.d should be empty except for the definition of Object. The rest should be located in their own modules and publicly imported in object.d
>
> I think the compiler would have to change for that to happen.
>
> I would support such a change, but then again, it seems like we'd get little measurable benefit for it, making it difficult to get through Walter.
>
> -Steve

Why would that pose a problem to DMD? object.d is a regular D module and D provides a public import feature. If that fails for some modules it should be considered a bug in the compiler.

I disagree about the side of the benefit. This gains us readability of code which is IMO a MAJOR benefit. It's not just the object.d module but a lot of phobos too.
It frustrates me to no end Andrei's refusal to accept a design proven to work for half a century (which is already utilized by the compiler!) - the File System. Choosing instead to duplicate organization features inside DDOC as sections. This is a classic example of a code smell.

On Thu, Mar 15, 2012 at 11:50:47PM +0400, Dmitry Olshansky wrote: [...]
> >This is one major area that I forgot to mention, and that is, making AA literals work at compile-time. Currently things like this don't work:
> >
> >	enum myAA = ["abc":123, "def":456];
> >
> >I'd like to make that work. That would require compile-time construction of the AA and storing it in some form that the compiler can put into the object file.
> 
> What's wrong with AA structure itself, it's link-pointer based?  At any rate, I stored complex structs as immutable, though links were index-based.

Yes, that's what I had in mind.

In fact, I've starting testing a statically-declared AA (written by hand for now), that uses the same structures as heap-allocated AA's. The basic stuff (declaring Slots statically, linking them together, etc.) works, and in principle can be generated by mixins at compile-time to give us "true" compile-time AA literals (as in, the AA struct is computed at compile-time and stored in the static data segment in the object file). This can be used for implementing immutable AA's at compile-time (and maybe also "fast" initialization of AA literals which can be .dup'd at runtime into mutable AA's when needed).

However, I've run into a major roadblock: the hash computation of the keys itself. Unfortunately, currently there's no (reliable) way to compute the hash of built-in types unless you use its TypeInfo, and TypeInfo's are currently not CTFE-accessible, so hash values cannot be computed at compile-time. :-(


T

-- 
He who laughs last thinks slowest.

On 3/15/12 5:59 PM, foobar wrote:
> It frustrates me to no end Andrei's refusal to accept a design proven to
> work for half a century (which is already utilized by the compiler!) -
> the File System. Choosing instead to duplicate organization features
> inside DDOC as sections. This is a classic example of a code smell.

What, what? What did I do?

Andrei

On Thursday, March 15, 2012 21:10:43 Andrei Alexandrescu wrote:
> On 3/15/12 5:59 PM, foobar wrote:
> > It frustrates me to no end Andrei's refusal to accept a design proven to work for half a century (which is already utilized by the compiler!) - the File System. Choosing instead to duplicate organization features inside DDOC as sections. This is a classic example of a code smell.
>
> What, what? What did I do?

Yeah. That comment makes no sense. More context is needed.

- Jonathan M Davis

On Thu, Mar 15, 2012 at 05:02:06PM +0100, Don Clugston wrote: [...]
> This is good, and very, very important. Do *not* make any attempt at compiler integration until it is *completely* ready.
> 
> This includes AA literals. They need to be accepted somehow. The
> compiler will give you syntax sugar and *nothing* more.
> One possibility might be to accept a pair of array literals,
> representing keys and values.

Alright, I've made a preliminary implementation of AA literals as a function that constructs an AA given an array of keys and and an array of values (just like the current aaA.d implementation).  The changes have been pushed to github:

	https://github.com/quickfur/New-AA-implementation/commit/c272909626f09829f333467499996250c2a1e8d2

Currently this function is a static member; I'm thinking maybe it might be better to make it an external template function instead. That way, we only need the compiler to do array type inference for the input arrays, and the function will use the inferred types to determine the AA key/value types.


> Possibly it should call a CTFE function to convert them into some other form?

I do intend to do more with AA literals, including making them compileable into object code directly (using static struct instances and mixins), but that will be more involved, and will require implementing toHash() for all native types using UFCS, that I proposed in another thread. A quick hand-crafted test earlier today showed that it *can* be done; it's just a matter of getting the various pieces in place.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.

On 2012-03-15 23:59, foobar wrote:
> On Thursday, 15 March 2012 at 10:39:04 UTC, Steven Schveighoffer wrote:

> Why would that pose a problem to DMD? object.d is a regular D module and
> D provides a public import feature. If that fails for some modules it
> should be considered a bug in the compiler.
>
> I disagree about the side of the benefit. This gains us readability of
> code which is IMO a MAJOR benefit. It's not just the object.d module but
> a lot of phobos too.
> It frustrates me to no end Andrei's refusal to accept a design proven to
> work for half a century (which is already utilized by the compiler!) -
> the File System. Choosing instead to duplicate organization features
> inside DDOC as sections. This is a classic example of a code smell.
>

I completely agree.

-- 
/Jacob Carlborg

H. S. Teoh:

> Alright, I've made a preliminary implementation of AA literals as a function that constructs an AA given an array of keys and and an array of values (just like the current aaA.d implementation).

See also: http://d.puremagic.com/issues/show_bug.cgi?id=5502 http://d.puremagic.com/issues/show_bug.cgi?id=5466

Bye,
bearophile

On Fri, Mar 16, 2012 at 08:25:08AM -0400, bearophile wrote:
> H. S. Teoh:
> 
> > Alright, I've made a preliminary implementation of AA literals as a function that constructs an AA given an array of keys and and an array of values (just like the current aaA.d implementation).
> 
> See also: http://d.puremagic.com/issues/show_bug.cgi?id=5502 http://d.puremagic.com/issues/show_bug.cgi?id=5466
[...]

I took a look at these issues, but they seem tricky to implement in druntime because they depend on phobos features. So probably constructing an AA from zip() should be in phobos; the current AA methods should be already be good enough for implementing this.

For iterating AA's as key/value pairs, though, I'll have to think about how to do it in a nice way. Internally, there's already a Range struct that iterates by Slot (which amounts to the same thing as iterating by pairs), so it's just a matter of exposing this in the right way to the phobos code that will implement by-pair iteration.


T

-- 
This is a tpyo.