• bearophile (5/5) Sep 14 2009 Don has recently said that adding dynamic arrays at compile-time looks e...
• Justin Johansson (6/12) Sep 15 2009 Hear, hear, I second the motion .. especially if such feature can be use...
• Ellery Newcomer (3/10) Sep 15 2009 Giving enums a tupleof property would make more sense, I think. I've
• bearophile (5/7) Sep 15 2009 While we wait some years for a saner solution, you may use this bad look...
• Don (9/12) Sep 15 2009 Indeed. I think perfect hashing is one of the primary appeals of a
• Jeremie Pelletier (2/16) Sep 15 2009 Just out of curiosity, how are compile time AAs implemented? The D runti...
• Don (7/24) Sep 15 2009 The funny thing is, there are AA literals, but they can only be used at

bearophile <bearophileHUGS lycos.com> writes:

Don has recently said that adding dynamic arrays at compile-time looks easy.
I'd also like to have compile-time associative arrays. So you can fill them
inside a CT function (the compiler may try to do the same for AAs created
inside a static this(){}), and save some run time.
Even if such compile-time AAs have to be immutable at run-time they can be
useful anyway.
A smarter implementation of such CT AAs may even use a perfet hashing, to make
them quite fast.

Bye,
bearophile

Justin Johansson <procode adam-dott-com.au> writes:

Hear, hear, I second the motion .. especially if such feature can be used to
implement reverse enums.

It's tedious writing reverse mapping tables (in C++) for converting the runtime
value of an enum back to its symbolic (lexical) name for debug purposes. 
Sounds like bearophile's CT AA might help to achieve this facility with ease in
D.  Then again, the features of D that I'm still learning about continue to
amaze me so perhaps one can do this (reverse enum) thing in D already .. just
that it (the mystery feature) hasn't found me yet.

Cheers
Justin Johansson

<_/>


bearophile Wrote:

 Don has recently said that adding dynamic arrays at compile-time looks easy.
I'd also like to have compile-time associative arrays. So you can fill them
inside a CT function (the compiler may try to do the same for AAs created
inside a static this(){}), and save some run time.
 Even if such compile-time AAs have to be immutable at run-time they can be
useful anyway.
 A smarter implementation of such CT AAs may even use a perfet hashing, to make
them quite fast.
 
 Bye,
 bearophile

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

Justin Johansson wrote:
 Hear, hear, I second the motion .. especially if such feature can be used to
implement reverse enums.
 
 It's tedious writing reverse mapping tables (in C++) for converting the
runtime value of an enum back to its symbolic (lexical) name for debug
purposes.  Sounds like bearophile's CT AA might help to achieve this facility
with ease in D.  Then again, the features of D that I'm still learning about
continue to amaze me so perhaps one can do this (reverse enum) thing in D
already .. just that it (the mystery feature) hasn't found me yet.
 
 Cheers
 Justin Johansson
 

Giving enums a tupleof property would make more sense, I think. I've
always wondered why they don't have it.

bearophile <bearophileHUGS lycos.com> writes:

Ellery Newcomer:
 Giving enums a tupleof property would make more sense, I think. I've
 always wondered why they don't have it.

While we wait some years for a saner solution, you may use this bad looking
hack (D2):
http://www.digitalmars.com/d/2.0/phobos/std_typecons.html#defineEnum

Bye,
bearophile

Don <nospam nospam.com> writes:

bearophile wrote:
 Don has recently said that adding dynamic arrays at compile-time looks easy.
I'd also like to have compile-time associative arrays. So you can fill them
inside a CT function (the compiler may try to do the same for AAs created
inside a static this(){}), and save some run time.
 Even if such compile-time AAs have to be immutable at run-time they can be
useful anyway.
 A smarter implementation of such CT AAs may even use a perfet hashing, to make
them quite fast.

Indeed. I think perfect hashing is one of the primary appeals of a 
compile-time AA.

BTW, you can use AAs inside CTFE already. There's probably missing 
functionality, though -- create a Bugzilla test case for anything you 
find. The primary thing which is missing is that you can't use an AA 
literal to populate a runtime AA (this is a backend issue, not a CTFE 
limitation). You can get the AA keys and values as arrays, though, so 
you could populate the AA yourself.

Jeremie Pelletier <jeremiep gmail.com> writes:

Don Wrote:

 bearophile wrote:
 Don has recently said that adding dynamic arrays at compile-time looks easy.
I'd also like to have compile-time associative arrays. So you can fill them
inside a CT function (the compiler may try to do the same for AAs created
inside a static this(){}), and save some run time.
 Even if such compile-time AAs have to be immutable at run-time they can be
useful anyway.
 A smarter implementation of such CT AAs may even use a perfet hashing, to make
them quite fast.

 
 Indeed. I think perfect hashing is one of the primary appeals of a 
 compile-time AA.
 
 BTW, you can use AAs inside CTFE already. There's probably missing 
 functionality, though -- create a Bugzilla test case for anything you 
 find. The primary thing which is missing is that you can't use an AA 
 literal to populate a runtime AA (this is a backend issue, not a CTFE 
 limitation). You can get the AA keys and values as arrays, though, so 
 you could populate the AA yourself.

Just out of curiosity, how are compile time AAs implemented? The D runtime
already handles the creation and lookups of these arrays, so let's suppose I
changed my runtime to have a completely different AA implementation, what would
happen when you mix both compile time and runtime AAs?

Don <nospam nospam.com> writes:

Jeremie Pelletier wrote:
 Don Wrote:
 
 bearophile wrote:
 Don has recently said that adding dynamic arrays at compile-time looks easy.
I'd also like to have compile-time associative arrays. So you can fill them
inside a CT function (the compiler may try to do the same for AAs created
inside a static this(){}), and save some run time.
 Even if such compile-time AAs have to be immutable at run-time they can be
useful anyway.
 A smarter implementation of such CT AAs may even use a perfet hashing, to make
them quite fast.

 Indeed. I think perfect hashing is one of the primary appeals of a 
 compile-time AA.

 BTW, you can use AAs inside CTFE already. There's probably missing 
 functionality, though -- create a Bugzilla test case for anything you 
 find. The primary thing which is missing is that you can't use an AA 
 literal to populate a runtime AA (this is a backend issue, not a CTFE 
 limitation). You can get the AA keys and values as arrays, though, so 
 you could populate the AA yourself.

 
 Just out of curiosity, how are compile time AAs implemented? The D runtime
already handles the creation and lookups of these arrays, so let's suppose I
changed my runtime to have a completely different AA implementation, what would
happen when you mix both compile time and runtime AAs?

The funny thing is, there are AA literals, but they can only be used at 
compile time. "An AssocArrayLiteral cannot be used to statically 
initialize anything." (expression.html in the spec).
A compile-time AA is just a pointer to an AA literal. It's really 
peculiar, because that's the only time they can be used. So there's 
pretty much zero interaction between compile-time and run-time AAs!