www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Official DMD compiler written in D

reply "Tim Krimm" <twkrimm gmail.com> writes:
Now that D 2.0 is fairly stable, are there any plans of writing 
the official DMD compiler with the D 2.0 language vs the present 
language of C++?

DMD 2.0 would have to be feature frozen and then DMD 3.0 could be 
written with the previous DMD 2.0 compiler.

What are your thoughts?
Jan 08 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/08/2013 10:48 AM, Tim Krimm wrote:
 Now that D 2.0 is fairly stable, are there any plans of writing the
 official DMD compiler with the D 2.0 language vs the present language of
 C++?

 DMD 2.0 would have to be feature frozen and then DMD 3.0 could be
 written with the previous DMD 2.0 compiler.

 What are your thoughts?

There is Denis Koroskin's ddmd: http://forum.dlang.org/thread/i4obl3$kgk$1 digitalmars.com?page=1 If this page is up to date, ddmd is currently at dmd 2.040's level: http://www.dsource.org/projects/ddmd Ali
Jan 08 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/08/2013 01:06 PM, Philippe Sigaud wrote:
 On Tue, Jan 8, 2013 at 8:18 PM, Ali Çehreli<acehreli yahoo.com>  wrote:

 There is Denis Koroskin's ddmd:


    http://www.dsource.org/**projects/ddmd<http://www.dsource.org/projects/ddmd>


 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC

And Aziz Köksal's dil: https://github.com/azizk/dil Ali
Jan 08 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
 ...

 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC


 Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
 past, but did not provide any link to it.

Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore. (eg. the parser cannot parse extern(...) declarations in alias declarations yet, and I need to finish making a minor tweak to how template instances are analyzed in order to get circular dependency detection to work reliably. Furthermore, examples like the following are currently rejected, while I want it to work: enum x = "enum xx = q{int y = 0;};"; struct S{ mixin(xx); mixin(x); } <mixin mxin.d:5>:1:6: error: declaration of 'xx' smells suspiciously fishy enum xx = q{int y = 0;}; ^~ mxin.d:4:11: note: this lookup should have succeeded if it was valid mixin(xx); ^~ It shouldn't be a too large change, as eg. this already works: struct S{ enum z = y; enum x = "enum xx = q{immutable y = 123;};"; mixin(xx); mixin(x); static assert(z == 123); } (DMD chokes on both.) Furthermore, I need to implement exceptions, modules, and some parts of compile time reflection + tons of really small features. (Where all ambiguities and contradictions are detected according to well-defined rules instead of resolved or choked on randomly as DMD likes to do.) Also, it obviously needs a repl. :-) CTFE is basically done (as a portable byte code interpreter, but other strategies, such as JIT, could be easily plugged). This is a snippet of my regression test suite: auto dynRangePrimes(){ DynRange!int impl(int start)=> dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1))))); return impl(2); } static assert(array(take(dynRangePrimes(), 20)) == [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]); ) I also need to decide on a licence. I assume that the alpha will be out in late spring. (I am busy until early spring.)
 But, to answer the OP question: no, there are no plan to switch to D for
 the reference compiler in the near future, as far as I can tell.

Jan 09 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-09 12:05, Timon Gehr wrote:

 Yes, it is in D. Nothing is released yet. It needs to be polished a
 little so that there are no known embarrassing shortcomings anymore.

I've might have missed this front end. Any links ? -- /Jacob Carlborg
Jan 09 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-09 13:54, deadalnix wrote:

 I'm not really a specialist in terms of license, but it'd be nice if it
 is compatible with SDC's.

SDC uses the MIT license. -- /Jacob Carlborg
Jan 09 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/9/13 5:10 AM, Philippe Sigaud wrote:
 On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg<doob me.com>  wrote:
 On 2013-01-09 13:54, deadalnix wrote:

 I'm not really a specialist in terms of license, but it'd be nice if it
 is compatible with SDC's.

SDC uses the MIT license.

Well, I'd use (and hack) any D compiler written in D, whatever the license. Let Timon code it, when the only left is the license, all will be well and good.

Once http://d.puremagic.com/issues/show_bug.cgi?id=9285 is done we'll have a realistic means to progressively port dmd's official front end into D by translating one module at a time and linking together C++ and D code. dtoh would serve as the bridge generator and would allow us to avoid maintaining duplicate declarations. Andrei
Jan 09 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-10 04:49, Timon Gehr wrote:

 Yes, the goal is to have the back-end be fully separate. It should also
 work with no back end at all, eg. for highlighting in code editors.

That's always nice to hear. -- /Jacob Carlborg
Jan 09 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Jan-2013 15:05, Timon Gehr пишет:
 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
 ...

 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC


 Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
 past, but did not provide any link to it.

Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore. (eg. the parser cannot parse extern(...) declarations in alias declarations yet, and I need to finish making a minor tweak to how template instances are analyzed in order to get circular dependency detection to work reliably. Furthermore, examples like the following are currently rejected, while I want it to work:

[snip]
 CTFE is basically done (as a portable byte code interpreter, but other
 strategies, such as JIT, could be easily plugged). This is a snippet of
 my regression test suite:

 auto dynRangePrimes(){
      DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
      return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

 )

Cool! I'd love to take even the very preliminary peek at the speed profile of this CTFE engine. If you are interested I'd love to test a small (the code though contains a lot of static data) CTFE benchmark that is the bottleneck in the compilation of current ctRegex. See the attachment here: http://d.puremagic.com/issues/show_bug.cgi?id=7442 would be nice to see some rough numbers for this vs DMD.
 I also need to decide on a licence. I assume that the alpha will be out
 in late spring. (I am busy until early spring.)

-- Dmitry Olshansky
Jan 10 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/10/2013 08:52 PM, Dmitry Olshansky wrote:
 09-Jan-2013 15:05, Timon Gehr пишет:
 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:
 ...

 Isn't SDC also in D? (Bernard Helyer and friends)
 https://github.com/bhelyer/SDC


 Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
 past, but did not provide any link to it.

Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore. (eg. the parser cannot parse extern(...) declarations in alias declarations yet, and I need to finish making a minor tweak to how template instances are analyzed in order to get circular dependency detection to work reliably. Furthermore, examples like the following are currently rejected, while I want it to work:

[snip]
 CTFE is basically done (as a portable byte code interpreter, but other
 strategies, such as JIT, could be easily plugged). This is a snippet of
 my regression test suite:

 auto dynRangePrimes(){
      DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
      return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

 )

Cool! I'd love to take even the very preliminary peek at the speed profile of this CTFE engine. If you are interested I'd love to test a small (the code though contains a lot of static data) CTFE benchmark that is the bottleneck in the compilation of current ctRegex. See the attachment here: http://d.puremagic.com/issues/show_bug.cgi?id=7442 would be nice to see some rough numbers for this vs DMD.

I'll let you know as soon as the example runs. Currently this is blocked by the missing implementation for the following language features: - import declarations - UFCS - Optional parens on function calls - Struct literals - Static struct data - debug declarations - Some of the built-in array operations - Missing object.d (no string, size_t, hash_t alias.) - (static) foreach - __ctfe I will prioritize those features. Except import declarations, they are mostly easy to implement, but I haven't gotten around to them yet. For the meantime, maybe these quick measurements are somewhat useful: int[] erathos(int x){ bool[] p; for(int i=0;i<=x;i++) p~=true; for(int i=3;i*i<=x;i+=2){ if(p[i]) for(int k=i*i;k<=x;k=k+i) p[k]=false; } int[] r; if(x>=2) r~=2; for(int i=3;i<=x;i+=2) if(p[i]) r~=i; return r; } pragma(msg, "erathos: ",erathos(40000).length); The frontend (32-bit dmd build, without -inline, otherwise DMD ICEs): $ time ./d erathos.d erathos: 4203U real 0m0.077s user 0m0.076s sys 0m0.000s DMD 2.060 (64 bit): $ time dmd -o- erathos.d erathos: 4203u real 0m2.594s user 0m0.716s sys 0m1.696s ... pragma(msg, "erathos: ",erathos(400000)); // (that is one 0 more) The frontend: erathos: 33860U real 0m0.662s user 0m0.660s sys 0m0.000s DMD: brings down the machine pragma(msg, "erathos: ",erathos(4000000)); // (yet another 0 more) The frontend: erathos: 283146U real 0m6.867s user 0m6.832s sys 0m0.016s // pragma(msg, "erathos: ",erathos(4000000)); void main(){ import std.stdio; writeln(erathos(4000000).length); } $ dmd -O -release -inline -noboundscheck erathos.d && time ./erathos dmd: module.c:829: void Module::semantic3(): Assertion `semanticstarted == 2' failed. (I'll see if it also fails with DMD 2.061.) $ dmd -O -release -noboundscheck erathos.d && time ./erathos 283146 real 0m0.144s user 0m0.132s sys 0m0.008s So CTFE in the front end seems to be ~50 times slower than a optimized DMD build of the same code in this case. But note that it is powered by a simple-minded bytecode interpreter I hacked together mostly during two weekends. (the array append is the one from druntime) A lot more is possible. I guess it is already fast enough to power std.regex.
Jan 10 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Jan-2013 05:43, Timon Gehr пишет:
 On 01/10/2013 08:52 PM, Dmitry Olshansky wrote:

 Cool! I'd love to take even the very preliminary peek at the speed
 profile of this CTFE engine.

 If you are interested I'd love to test a small (the code though contains
 a lot of static data) CTFE benchmark that is the bottleneck in the
 compilation of current ctRegex.

 See the attachment here:
 http://d.puremagic.com/issues/show_bug.cgi?id=7442

 would be nice to see some rough numbers for this vs DMD.

I'll let you know as soon as the example runs. Currently this is blocked by the missing implementation for the following language features: - import declarations - UFCS - Optional parens on function calls - Struct literals - Static struct data - debug declarations - Some of the built-in array operations - Missing object.d (no string, size_t, hash_t alias.) - (static) foreach - __ctfe

I guess that core.bitop intrinsics too. Either way, thanks in advance.
 I will prioritize those features. Except import declarations, they are
 mostly easy to implement, but I haven't gotten around to them yet.

 For the meantime, maybe these quick measurements are somewhat useful:

They truly are. As I've been long wondering that CTFE could be quite fast if it wasn't for it's current architecture in DMD. Just needed the hard data to go by.
 int[] erathos(int x){
      bool[] p;
      for(int i=0;i<=x;i++) p~=true;
      for(int i=3;i*i<=x;i+=2){
          if(p[i]) for(int k=i*i;k<=x;k=k+i) p[k]=false;
      }
      int[] r;
      if(x>=2) r~=2;
      for(int i=3;i<=x;i+=2) if(p[i]) r~=i;
      return r;
 }

 pragma(msg, "erathos: ",erathos(40000).length);


 The frontend (32-bit dmd build, without -inline, otherwise DMD ICEs):
 $ time ./d erathos.d
 erathos: 4203U

 real    0m0.077s
 user    0m0.076s
 sys    0m0.000s


 DMD 2.060 (64 bit):
 $ time dmd -o- erathos.d
 erathos: 4203u

 real    0m2.594s
 user    0m0.716s
 sys    0m1.696s


 ...

 pragma(msg, "erathos: ",erathos(400000)); // (that is one 0 more)

 The frontend:
 erathos: 33860U

 real    0m0.662s
 user    0m0.660s
 sys    0m0.000s

 DMD: brings down the machine

 pragma(msg, "erathos: ",erathos(4000000)); // (yet another 0 more)

 The frontend:
 erathos: 283146U

 real    0m6.867s
 user    0m6.832s
 sys    0m0.016s

 // pragma(msg, "erathos: ",erathos(4000000));
 void main(){
      import std.stdio;
      writeln(erathos(4000000).length);
 }

 $ dmd -O -release -inline -noboundscheck erathos.d && time ./erathos
 dmd: module.c:829: void Module::semantic3(): Assertion `semanticstarted
 == 2' failed.

I bet this one was fixed in 2.061, I've recently seen the similar bug as resolved "works for me".
 (I'll see if it also fails with DMD 2.061.)

 $ dmd -O -release -noboundscheck erathos.d && time ./erathos
 283146

 real    0m0.144s
 user    0m0.132s
 sys    0m0.008s

 So CTFE in the front end seems to be ~50 times slower than a optimized
 DMD build of the same code in this case. But note that it is powered by
 a simple-minded bytecode interpreter I hacked together mostly during two
 weekends.

Yes, yes and yes! Simple bytecode interpreter is what I've been waiting for :)
 (the array append is the one from druntime) A lot more is
 possible. I guess it is already fast enough to power std.regex.

Sure and a simple threaded-code interpreter should make it fly (when D has e.g. explicit tail call). -- Dmitry Olshansky
Jan 11 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
10-Jan-2013 09:45, H. S. Teoh пишет:
 On Thu, Jan 10, 2013 at 04:51:35AM +0100, Timon Gehr wrote:
 On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:

 Whoa!!! Now you really caught my interest!

 Can it handle CTFE-computed mixins that declare and reference
 variables?  If it can, I will finally be able to write a library AA
 implementation that allows static AA literals (no runtime
 init/allocation needed)!

Probably yes, but I am not sure what you mean. Can you provide an example?

The basic idea behind static AA literals is to use CTFE to compute the hashes of the keys, and therefore which slot(s) they will fall in, at compile time.

Why not try to make an AA literal a universal entity for all kinds of user-defined associative arrays? Then the actual construction of AA is done via constructor taking some type like AALiteral!(Key, Value) which is a sequence of Key, Value pairs. It could be even presorted.
 Armed with this information, we can create an array of
 slots at compile-time that contains the AA entries by declaring each
 slot as a static variable and using the slot assignment information to
 initialize the hash table (array of pointers to slots) to point to these
 slots.

 Now, there are some challenges to be overcome here. For example, the
 slots need to be declared as local variables, and therefore need unique
 names (the hash table array needs to be able to refer to the addresses
 of these variables), so the only way I can think of to do this at
 compile-time is to have the CTFE code generate mixins to declare those
 variables. So here's the tricky part. Suppose you have this CTFE code:

 	// Not the real code, just a rough sketch to give the idea
 	string aaComputeAASlots(K,V)(K[V] aaLiteral) {
 		// Create slots
 		string slotVars;
 		foreach (key, value; aaLiteral) {
 			size_t slotNum = hashOf(key) % numKeys;
 			string slotName = "aaSlot" ~ slotNum;
 			slotVars ~= "immutable Slot " ~ slotName ~
 				" = Slot(" ~ key ~ ", " ~ value ~ ");";
 		}

 		string mainTable = q{
 			immutable Slot*[] aaTable = {
 				&aaSlot0,
 				&aaSlot1,
 				... // generate these programmatically
 			};
 		};

 		return slotVars ~ mainTable;
 	}

 	// Instantiate AA here, at compile time.
 	mixin(aaComputeAASlots(myLiteral));

 The mixin string would look something like this:

 	"immutable Slot aaSlot0 = Slot(..., ...);
 	 immutable Slot aaSlot1 = Slot(..., ...);
 	 immutable Slot*[] aaTable = {
 	 	&aaSlot0, &aaSlot1, ...
 	 }"

 The question is, will the compile be able to resolve &aaSlot0, &aaSlot1,
 etc., at compile-time?

 Obviously, this code works if you copy-n-paste it into a .d source file.
 It also works if I write it as a string literal, then use mixin().
 However, on DMD, if the string is returned by a CTFE function that
 builds it using ~, for some reason all the pointers in aaTable are null.
 Strangely enough, if I assign the returned string to a string variable
 and print it out at runtime, the correct string is produced.

Seems like a bug.
 So I concluded that somehow, DMD was unable to correctly interpret
 &aaSlot0 inside a mixin string at compile-time.

-- Dmitry Olshansky
Jan 10 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Jan-2013 00:49, Era Scarecrow пишет:
 On Thursday, 10 January 2013 at 20:48:12 UTC, Era Scarecrow wrote:

 func(x); // x is not type string[string], is type xxx!string,string

Thinking about it, if the AA is just syntactical sugar for a struct (say defined in core.memory) which handles that then the problem goes away.

+ user defined implicit conversion so that AALiteral(K,V) --*implicitly*!--> AA!(K,V) The other use case for user-defined implicit conversion were already outlined before so I hope it will make its way in one day. -- Dmitry Olshansky
Jan 10 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/10/13 4:21 PM, Rob T wrote:
 I was wondering the same thing: Why do AA's have to be built directly
 into the language rather than implemented within the standard library?

 AA's may be nice to have, but are they really all that fundamental? For
 example, everyone uses strings, but I suspect not everyone will use AA's.

 It could however be that some fundamental constructs in the D language
 make use of the built in AA's (tuples?), so if that is the case I can
 understand why they would be built in, but I do not know if this is the
 case or not.

The only distinguishing feature is literal syntax. Everything else is a mistake in language design or an insufficiency in the state of the art.
 On a side note, I'm wondering if this may be a way that can help decide
 what should or should not be made a built in component of the language,
 i.e, If the language itself can make good use of the feature internally,
 then it's a good candidate for being built in, but if not, then it's a
 good candidate for being left out and instead implemented in the std lib
 or elsewhere.

Long discussion. Very long. Andrei
Jan 10 2013
prev sibling next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
--20cf30334c5bd6d44204d2cd5176
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 8, 2013 at 8:18 PM, Ali =C3=87ehreli <acehreli yahoo.com> wrote=
:

 On 01/08/2013 10:48 AM, Tim Krimm wrote:

 Now that D 2.0 is fairly stable, are there any plans of writing the
 official DMD compiler with the D 2.0 language vs the present language of
 C++?

 DMD 2.0 would have to be feature frozen and then DMD 3.0 could be
 written with the previous DMD 2.0 compiler.

 What are your thoughts?

There is Denis Koroskin's ddmd: http://forum.dlang.org/thread/**i4obl3$kgk$1 digitalmars.com?**page=3D1=

 If this page is up to date, ddmd is currently at dmd 2.040's level:

   http://www.dsource.org/**projects/ddmd<http://www.dsource.org/projects/=

 Ali

Isn't SDC also in D? (Bernard Helyer and friends) https://github.com/bhelyer/SDC Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the past, but did not provide any link to it. But, to answer the OP question: no, there are no plan to switch to D for the reference compiler in the near future, as far as I can tell. --20cf30334c5bd6d44204d2cd5176 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, Jan 8, 2013 at 8:18 PM, Ali =C3= =87ehreli <span dir=3D"ltr">&lt;<a href=3D"mailto:acehreli yahoo.com" targe= t=3D"_blank">acehreli yahoo.com</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 01/08/2013 10:48 AM, Tim Krimm w= rote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> Now that D 2.0 is fairly stable, are there any plans of writing the<br> official DMD compiler with the D 2.0 language vs the present language of<br=

<br> DMD 2.0 would have to be feature frozen and then DMD 3.0 could be<br> written with the previous DMD 2.0 compiler.<br> <br> What are your thoughts?<br> </blockquote> <br></div></div> There is Denis Koroskin&#39;s ddmd:<br> <br> =C2=A0 <a href=3D"http://forum.dlang.org/thread/i4obl3$kgk$1 digitalmars.co= m?page=3D1" target=3D"_blank">http://forum.dlang.org/thread/<u></u>i4obl3$k= gk$1 digitalmars.com?<u></u>page=3D1</a><br> <br> If this page is up to date, ddmd is currently at dmd 2.040&#39;s level:<br> <br> =C2=A0 <a href=3D"http://www.dsource.org/projects/ddmd" target=3D"_blank">h= ttp://www.dsource.org/<u></u>projects/ddmd</a><span class=3D"HOEnZb"><font = color=3D"#888888"><br> <br> Ali<br> </font></span></blockquote></div><br><div>Isn&#39;t SDC also in D? (Bernard= Helyer and friends)</div><div><a href=3D"https://github.com/bhelyer/SDC">h= ttps://github.com/bhelyer/SDC</a></div><div><br></div><div><br></div><div> Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the pas= t, but did not provide any link to it.</div><div><br></div><div><br></div><= div>But, to answer the OP question: no, there are no plan to switch to D fo= r the reference compiler in the near future, as far as I can tell.</div> <div><br></div><div><br></div> --20cf30334c5bd6d44204d2cd5176--
Jan 08 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 10, 2013 at 11:18:07PM +0100, Era Scarecrow wrote:
 On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky
 wrote:
+ user defined implicit conversion so that AALiteral(K,V)
--*implicitly*!--> AA!(K,V)


The other use case for user-defined implicit conversion were
already outlined before so I hope it will make its way in one day.

I thought I heard talk of possibly moving AA's to a library implementation rather than a built in feature (Still 'built in' technically).

That's my plan, and Andrei's hope. But it's not going to be easy. The current AA implementation is split between object_.d and aaA.d in druntime, with bits scattered throughout the compiler. Cleaning all of that up is going to be a big job. T -- No! I'm not in denial!
Jan 10 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 10 January 2013 at 22:28:46 UTC, H. S. Teoh wrote:
 On Thu, Jan 10, 2013 at 11:18:07PM +0100, Era Scarecrow wrote:
 On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky
 wrote:
+ user defined implicit conversion so that AALiteral(K,V)
--*implicitly*!--> AA!(K,V)


The other use case for user-defined implicit conversion were
already outlined before so I hope it will make its way in one 
day.

I thought I heard talk of possibly moving AA's to a library implementation rather than a built in feature (Still 'built in' technically).

That's my plan, and Andrei's hope. But it's not going to be easy. The current AA implementation is split between object_.d and aaA.d in druntime, with bits scattered throughout the compiler. Cleaning all of that up is going to be a big job.

You may want to look at this : http://preshing.com/20130107/this-hash-table-is-faster-than-a-judy-array Additionally, can you show me what you have so far ? I'd be interested in using it directly for SDC without using the existing one at all.
Jan 10 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 08, 2013 at 07:48:58PM +0100, Tim Krimm wrote:
 
 Now that D 2.0 is fairly stable, are there any plans of writing the
 official DMD compiler with the D 2.0 language vs the present
 language of C++?
 
 DMD 2.0 would have to be feature frozen and then DMD 3.0 could be
 written with the previous DMD 2.0 compiler.
 
 What are your thoughts?

Philosophically, I like this idea. D should eat its own dogfood to prove its own worth. :) However, having the D compiler itself written in D, means we will have trouble bootstrapping it on new platforms. The advantage of having a C++ implementation is that C/C++ compilers are almost the first thing that gets implemented on a new platform, so you can almost always count on their existence. So you can just compile DMD and away you go. We *could* write a cross-compiler, of course, but it still requires that you first target the D compiler (written in D) to the new platform, and then cross-compile itself to that platform. Whereas with DMD, you just use the target platform's C++ compiler and you're up and running. T -- What's a "hot crossed bun"? An angry rabbit.
Jan 08 2013
parent 1100110 <0b1100110 gmail.com> writes:
On 01/08/2013 06:38 PM, H. S. Teoh wrote:
 On Wed, Jan 09, 2013 at 01:33:35AM +0100, David Nadlinger wrote:
 On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:
 We *could* write a cross-compiler, of course, but it still requires
 that you first target the D compiler (written in D) to the new
 platform, and then cross-compile itself to that platform.  Whereas
 with DMD, you just use the target platform's C++ compiler and you're
 up and running.

…except that you can't actually use that compiler for anything, because – wait for it – it still needs to be retargeted for the new platform. What kind of new system are you thinking of for which the first use case would be compiling x86 executables?

Heh, you're right. I appear to be having a streak of making a fool of myself today. T

I'm embarrassed to admit that I didn't understand the problem until I read your response... I love the idea of a D compiler in D. Walter might have issues with working on any other compiler backend other than digitalmars, wasn't that what was determined by previous threads?
Jan 08 2013
prev sibling next sibling parent "Nicolas Sicard" <dransic gmail.com> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:
 On Tue, Jan 08, 2013 at 07:48:58PM +0100, Tim Krimm wrote:
 
 Now that D 2.0 is fairly stable, are there any plans of 
 writing the
 official DMD compiler with the D 2.0 language vs the present
 language of C++?
 
 DMD 2.0 would have to be feature frozen and then DMD 3.0 could 
 be
 written with the previous DMD 2.0 compiler.
 
 What are your thoughts?

Philosophically, I like this idea. D should eat its own dogfood to prove its own worth. :) However, having the D compiler itself written in D, means we will have trouble bootstrapping it on new platforms. The advantage of having a C++ implementation is that C/C++ compilers are almost the first thing that gets implemented on a new platform, so you can almost always count on their existence. So you can just compile DMD and away you go. We *could* write a cross-compiler, of course, but it still requires that you first target the D compiler (written in D) to the new platform, and then cross-compile itself to that platform. Whereas with DMD, you just use the target platform's C++ compiler and you're up and running. T

I think the OP implied that we could build DMD2 from its C++ source on any platform and then DMD3 from its D source with DMD2.
Jan 08 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:
 We *could* write a cross-compiler, of course, but it still 
 requires that
 you first target the D compiler (written in D) to the new 
 platform, and
 then cross-compile itself to that platform.  Whereas with DMD, 
 you just
 use the target platform's C++ compiler and you're up and 
 running.

…except that you can't actually use that compiler for anything, because – wait for it – it still needs to be retargeted for the new platform. What kind of new system are you thinking of for which the first use case would be compiling x86 executables? David
Jan 08 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 09, 2013 at 01:33:35AM +0100, David Nadlinger wrote:
 On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:
We *could* write a cross-compiler, of course, but it still requires
that you first target the D compiler (written in D) to the new
platform, and then cross-compile itself to that platform.  Whereas
with DMD, you just use the target platform's C++ compiler and you're
up and running.

…except that you can't actually use that compiler for anything, because – wait for it – it still needs to be retargeted for the new platform. What kind of new system are you thinking of for which the first use case would be compiling x86 executables?

Heh, you're right. I appear to be having a streak of making a fool of myself today. T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Jan 08 2013
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:
 Philosophically, I like this idea. D should eat its own dogfood

+11111!1!!1eleven1!!!!1!
Jan 08 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Jan 9, 2013 at 12:05 PM, Timon Gehr <timon.gehr gmx.ch> wrote:
 Yes, it is in D. Nothing is released yet. It needs to be polished a little
 so that there are no known embarrassing shortcomings anymore.

What? That's FOSS, release early, release often!
 (DMD chokes on both.)

 Furthermore, I need to implement exceptions, modules, and some parts of
 compile time reflection + tons of really small features. (Where all
 ambiguities and contradictions are detected according to well-defined rules
 instead of resolved or choked on randomly as DMD likes to do.)

Makes me salivate.
 Also, it obviously needs a repl. :-)

Obviously. And direct programmatic access to the lexer and the parser. I'm coding a macro system for D right now, as an over-layer above DMD (like rdmd) and having to create the AST by myself to transform them according to the user-defined macros is a pain.
 CTFE is basically done (as a portable byte code interpreter, but other
 strategies, such as JIT, could be easily plugged).

Great!
 This is a snippet of my regression test suite:

 auto dynRangePrimes(){
     DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
     return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

Lazy recursive range, right? As the usual Haskell definition for a prime generator. Nice!
 I also need to decide on a licence.

Unless you've reason not to, I'd advise using the same as Phobos: Boost.
 I assume that the alpha will be out in late spring. (I am busy until early
spring.)

You can count me in to test it (I gather to prefer to code this as you see fit, right now). You could also present it at the D conf. In any cases, congratulations for what seems to be a elegantly done D implementation.
Jan 09 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 9 January 2013 at 11:05:56 UTC, Timon Gehr wrote:
 I also need to decide on a licence. I assume that the alpha 
 will be out in late spring. (I am busy until early spring.)

I'm not really a specialist in terms of license, but it'd be nice if it is compatible with SDC's.
Jan 09 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Wed, Jan 9, 2013 at 1:58 PM, Jacob Carlborg <doob me.com> wrote:
 On 2013-01-09 13:54, deadalnix wrote:

 I'm not really a specialist in terms of license, but it'd be nice if it
 is compatible with SDC's.

SDC uses the MIT license.

Well, I'd use (and hack) any D compiler written in D, whatever the license. Let Timon code it, when the only left is the license, all will be well and good.
Jan 09 2013
prev sibling next sibling parent "Tim Krimm" <twkrimm gmail.com> writes:
On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote:

 We *could* write a cross-compiler, of course, but it still 
 requires that
 you first target the D compiler (written in D) to the new 
 platform, and
 then cross-compile itself to that platform.  Whereas with DMD, 
 you just
 use the target platform's C++ compiler and you're up and 
 running.


 T

I think LDC 2.0 or GDC 2.0 might be able to serve this purpose.
Jan 09 2013
prev sibling next sibling parent "Tim Krimm" <twkrimm gmail.com> writes:
O
 Yes, it is in D. Nothing is released yet. It needs to be 
 polished a little so that there are no known embarrassing 
 shortcomings anymore.
 (eg. the parser cannot parse extern(...) declarations in alias 
 declarations yet, and I need to finish making a minor tweak to 
 how template instances are analyzed in order to get circular 
 dependency detection to work reliably.

How are you implementing the code generating back-end for the compiler? In your design, I would recommend keeping the front-end separate from the back-end so that maybe the front-end can be connected to the LDC or GDC back-ends.
Jan 09 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 09, 2013 at 12:05:55PM +0100, Timon Gehr wrote:
 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:

Also, Timon Gehr spoke of his own front-end (assumed to be in D) in the
past, but did not provide any link to it.

Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore.

 CTFE is basically done (as a portable byte code interpreter, but
 other strategies, such as JIT, could be easily plugged). This is a
 snippet of my regression test suite:
 
 auto dynRangePrimes(){
     DynRange!int impl(int start)=>
 
 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
     return impl(2);
 }
 
 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
 
 )

Whoa!!! Now you really caught my interest! Can it handle CTFE-computed mixins that declare and reference variables? If it can, I will finally be able to write a library AA implementation that allows static AA literals (no runtime init/allocation needed)! T -- Meat: euphemism for dead animal. -- Flora
Jan 09 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 11, 2013 at 08:47:19AM +0100, deadalnix wrote:
 On Thursday, 10 January 2013 at 22:28:46 UTC, H. S. Teoh wrote:
On Thu, Jan 10, 2013 at 11:18:07PM +0100, Era Scarecrow wrote:
On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky
wrote:
+ user defined implicit conversion so that AALiteral(K,V)
--*implicitly*!--> AA!(K,V)


The other use case for user-defined implicit conversion were
already outlined before so I hope it will make its way in one
day.

I thought I heard talk of possibly moving AA's to a library implementation rather than a built in feature (Still 'built in' technically).

That's my plan, and Andrei's hope. But it's not going to be easy. The current AA implementation is split between object_.d and aaA.d in druntime, with bits scattered throughout the compiler. Cleaning all of that up is going to be a big job.

You may want to look at this : http://preshing.com/20130107/this-hash-table-is-faster-than-a-judy-array Additionally, can you show me what you have so far ? I'd be interested in using it directly for SDC without using the existing one at all.

https://github.com/quickfur/New-AA-implementation It's basically just a refactoring of the current AA code to hoist it into object_.d; I didn't introduce any new algorithms or data structures. T -- This is a tpyo.
Jan 11 2013
prev sibling next sibling parent "Timon Gehr" <timon.gehr gmx.ch> writes:
On Wednesday, 9 January 2013 at 12:29:07 UTC, Philippe Sigaud 
wrote:
 On Wed, Jan 9, 2013 at 12:05 PM, Timon Gehr <timon.gehr gmx.ch> 
 wrote:
 Yes, it is in D. Nothing is released yet. It needs to be 
 polished a little
 so that there are no known embarrassing shortcomings anymore.

What? That's FOSS, release early, release often!

I want to release it at a time when I am ready to cope with reactions and bug reports.
 Also, it obviously needs a repl. :-)

Obviously.

Actually, at this point, the main challenge is getting the interactive code editing to work.
 And direct programmatic access to the lexer and the parser. I'm 
 coding
 a macro system for D right now, as an over-layer above DMD 
 (like rdmd)
 and having to create the AST by myself to transform them 
 according to
 the user-defined macros is a pain.

 CTFE is basically done (as a portable byte code interpreter, 
 but other
 strategies, such as JIT, could be easily plugged).

Great!
 This is a snippet of my regression test suite:

 auto dynRangePrimes(){
     DynRange!int impl(int start)=>

 dynRange(cons(start,delay(()=>filter!(a=>a%start)(impl(start+1)))));
     return impl(2);
 }

 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);

Lazy recursive range, right? As the usual Haskell definition for a prime generator. Nice!

It uses the usual range templates + dynRange, which wraps a range using delegates in order to hide some static type information and allow recursion.
 I also need to decide on a licence.

Unless you've reason not to, I'd advise using the same as Phobos: Boost.

I'll need to give it some thought, my knowledge about licensing is still rather limited.
 I assume that the alpha will be out in late spring. (I am busy 
 until early spring.)

You can count me in to test it (I gather to prefer to code this as you see fit, right now).

Thanks!
 You could also present it at the D conf.

I'd like to, but I probably cannot make it.
 In any cases, congratulations for what seems to be a elegantly 
 done D implementation.

Thanks! (Well, it makes extensive use of string mixins to simulate a coroutine-based system with low overhead.)
Jan 09 2013
prev sibling next sibling parent "Timon Gehr" <timon.gehr gmx.ch> writes:
On Wednesday, 9 January 2013 at 15:45:15 UTC, Tim Krimm wrote:
 O
 Yes, it is in D. Nothing is released yet. It needs to be 
 polished a little so that there are no known embarrassing 
 shortcomings anymore.
 (eg. the parser cannot parse extern(...) declarations in alias 
 declarations yet, and I need to finish making a minor tweak to 
 how template instances are analyzed in order to get circular 
 dependency detection to work reliably.

How are you implementing the code generating back-end for the compiler?

Currently, not at all. It's just a front-end.
 In your design, I would recommend keeping the front-end 
 separate from the back-end so that maybe the front-end can be 
 connected to the LDC or GDC back-ends.

Yes, the goal is to have the back-end be fully separate. It should also work with no back end at all, eg. for highlighting in code editors.
Jan 09 2013
prev sibling next sibling parent "Timon Gehr" <timon.gehr gmx.ch> writes:
On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:
 On Wed, Jan 09, 2013 at 12:05:55PM +0100, Timon Gehr wrote:
 On 01/08/2013 10:06 PM, Philippe Sigaud wrote:

Also, Timon Gehr spoke of his own front-end (assumed to be in 
D) in the
past, but did not provide any link to it.

Yes, it is in D. Nothing is released yet. It needs to be polished a little so that there are no known embarrassing shortcomings anymore.

 CTFE is basically done (as a portable byte code interpreter, 
 ...
 
 static assert(array(take(dynRangePrimes(), 20)) ==
 [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71]);
 
 )

Whoa!!! Now you really caught my interest! Can it handle CTFE-computed mixins that declare and reference variables? If it can, I will finally be able to write a library AA implementation that allows static AA literals (no runtime init/allocation needed)!

Probably yes, but I am not sure what you mean. Can you provide an example?
Jan 09 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 10, 2013 at 04:51:35AM +0100, Timon Gehr wrote:
 On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:

Whoa!!! Now you really caught my interest!

Can it handle CTFE-computed mixins that declare and reference
variables?  If it can, I will finally be able to write a library AA
implementation that allows static AA literals (no runtime
init/allocation needed)!

Probably yes, but I am not sure what you mean. Can you provide an example?

The basic idea behind static AA literals is to use CTFE to compute the hashes of the keys, and therefore which slot(s) they will fall in, at compile time. Armed with this information, we can create an array of slots at compile-time that contains the AA entries by declaring each slot as a static variable and using the slot assignment information to initialize the hash table (array of pointers to slots) to point to these slots. Now, there are some challenges to be overcome here. For example, the slots need to be declared as local variables, and therefore need unique names (the hash table array needs to be able to refer to the addresses of these variables), so the only way I can think of to do this at compile-time is to have the CTFE code generate mixins to declare those variables. So here's the tricky part. Suppose you have this CTFE code: // Not the real code, just a rough sketch to give the idea string aaComputeAASlots(K,V)(K[V] aaLiteral) { // Create slots string slotVars; foreach (key, value; aaLiteral) { size_t slotNum = hashOf(key) % numKeys; string slotName = "aaSlot" ~ slotNum; slotVars ~= "immutable Slot " ~ slotName ~ " = Slot(" ~ key ~ ", " ~ value ~ ");"; } string mainTable = q{ immutable Slot*[] aaTable = { &aaSlot0, &aaSlot1, ... // generate these programmatically }; }; return slotVars ~ mainTable; } // Instantiate AA here, at compile time. mixin(aaComputeAASlots(myLiteral)); The mixin string would look something like this: "immutable Slot aaSlot0 = Slot(..., ...); immutable Slot aaSlot1 = Slot(..., ...); immutable Slot*[] aaTable = { &aaSlot0, &aaSlot1, ... }" The question is, will the compile be able to resolve &aaSlot0, &aaSlot1, etc., at compile-time? Obviously, this code works if you copy-n-paste it into a .d source file. It also works if I write it as a string literal, then use mixin(). However, on DMD, if the string is returned by a CTFE function that builds it using ~, for some reason all the pointers in aaTable are null. Strangely enough, if I assign the returned string to a string variable and print it out at runtime, the correct string is produced. So I concluded that somehow, DMD was unable to correctly interpret &aaSlot0 inside a mixin string at compile-time. T -- It's bad luck to be superstitious. -- YHL
Jan 09 2013
prev sibling next sibling parent "Timon Gehr" <timon.gehr gmx.ch> writes:
On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:
 ...

 So I concluded that somehow, DMD was unable to correctly 
 interpret
 &aaSlot0 inside a mixin string at compile-time.


 T

If so, then that is a bug.
Jan 09 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:
 On Thu, Jan 10, 2013 at 04:51:35AM +0100, Timon Gehr wrote:
 On Wednesday, 9 January 2013 at 18:45:56 UTC, H. S. Teoh wrote:

Whoa!!! Now you really caught my interest!

Can it handle CTFE-computed mixins that declare and reference
variables?  If it can, I will finally be able to write a 
library AA
implementation that allows static AA literals (no runtime
init/allocation needed)!

Probably yes, but I am not sure what you mean. Can you provide an example?

The basic idea behind static AA literals is to use CTFE to compute the hashes of the keys, and therefore which slot(s) they will fall in, at compile time. Armed with this information, we can create an array of slots at compile-time that contains the AA entries by declaring each slot as a static variable and using the slot assignment information to initialize the hash table (array of pointers to slots) to point to these slots. Now, there are some challenges to be overcome here. For example, the slots need to be declared as local variables, and therefore need unique names (the hash table array needs to be able to refer to the addresses of these variables), so the only way I can think of to do this at compile-time is to have the CTFE code generate mixins to declare those variables. So here's the tricky part. Suppose you have this CTFE code: // Not the real code, just a rough sketch to give the idea string aaComputeAASlots(K,V)(K[V] aaLiteral) { // Create slots string slotVars; foreach (key, value; aaLiteral) { size_t slotNum = hashOf(key) % numKeys; string slotName = "aaSlot" ~ slotNum; slotVars ~= "immutable Slot " ~ slotName ~ " = Slot(" ~ key ~ ", " ~ value ~ ");"; } string mainTable = q{ immutable Slot*[] aaTable = { &aaSlot0, &aaSlot1, ... // generate these programmatically }; }; return slotVars ~ mainTable; } // Instantiate AA here, at compile time. mixin(aaComputeAASlots(myLiteral)); The mixin string would look something like this: "immutable Slot aaSlot0 = Slot(..., ...); immutable Slot aaSlot1 = Slot(..., ...); immutable Slot*[] aaTable = { &aaSlot0, &aaSlot1, ... }" The question is, will the compile be able to resolve &aaSlot0, &aaSlot1, etc., at compile-time? Obviously, this code works if you copy-n-paste it into a .d source file. It also works if I write it as a string literal, then use mixin(). However, on DMD, if the string is returned by a CTFE function that builds it using ~, for some reason all the pointers in aaTable are null. Strangely enough, if I assign the returned string to a string variable and print it out at runtime, the correct string is produced. So I concluded that somehow, DMD was unable to correctly interpret &aaSlot0 inside a mixin string at compile-time. T

Jan 10 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
  Eep, seems I hit send...

On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:
 The basic idea behind static AA literals is to use CTFE to 
 compute the hashes of the keys, and therefore which slot(s) 
 they will fall in, at compile time. Armed with this 
 information, we can create an array of slots at compile-time 
 that contains the AA entries by declaring each slot as a static 
 variable and using the slot assignment information to 
 initialize the hash table (array of pointers to slots) to point 
 to these slots.

Hmmm somehow that doesn't seem like a good idea; I mean it will work.... Alternative is to sorta have a pair of static arrays, then either use a balanced tree, or a modulus to best hold (and separate) the values. Modulus based: It could be like... //T obviously replace with appropriate type ref T AA_lookup(name publicName)(uint hash) { //offset for part1 //could be external to.. immutable static int offsets[]; //no need for pointers, right? immutable static T values[]; //contains actual item data enum mod; //divider for table. uint result = hash % mod; //or branch to return empty? But can't be ref then... assert(offsets[result] != -1); return values[offsets[result]]; } Then your CTFE increases the mod in it's calculations until every element can fit only once, and make the offsets based on them. Default values would be -1 (range error if called), course if it's mod is rather large and wastes a lot of space then perhaps it falls back on the tree structure (in those cases, > 3x of array size) Tree: I don't mind a minor performance hit, log(n) is a very small hit in my mind. In that case a statically created tree is rather easy. AA's created ahead of time are likely rather small (<1 Million elements). So a tree structure of: struct Node(T) { //pointers don't seem like they are needed; //Can even be ushorts or ubytes if small enough. uint left, right; T* value; } You get the idea.
Jan 10 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 10, 2013 at 08:38:08PM +0100, Era Scarecrow wrote:
  Eep, seems I hit send...
 
 On Thursday, 10 January 2013 at 05:47:01 UTC, H. S. Teoh wrote:
The basic idea behind static AA literals is to use CTFE to compute
the hashes of the keys, and therefore which slot(s) they will fall
in, at compile time. Armed with this information, we can create an
array of slots at compile-time that contains the AA entries by
declaring each slot as a static variable and using the slot
assignment information to initialize the hash table (array of
pointers to slots) to point to these slots.

Hmmm somehow that doesn't seem like a good idea; I mean it will work.... Alternative is to sorta have a pair of static arrays, then either use a balanced tree, or a modulus to best hold (and separate) the values.

The issue here is that I wanted to avoid the complication of having a separate set of functions to lookup the AA literal vs. a runtime AA (and trust me, things get *very* hairy if you go that route -- it requires non-trivial compiler hacks to make things work with two distinct AA types), so whatever is generated at compile-time must be the same structure as runtime AA's so that the same AA methods will work on both. If this is unimportant, then I would've done it another way. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Jan 10 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 19:57:29 UTC, Dmitry Olshansky 
wrote:
 Why not try to make an AA literal a universal entity for all 
 kinds of user-defined associative arrays? Then the actual 
 construction of AA is done via constructor taking some type 
 like AALiteral!(Key, Value) which is a sequence of Key, Value 
 pairs. It could be even presorted.

Only problem I would see with that, is trying to give something to a non-template function. auto x = AALiteral!(string, string)([]); void func(string[string] something); func(x); // x is not type string[string], is type xxx!string,string Course that brings up problem(s) with my own idea thrown out there. Seems like the problem is just determining storage type, at CTFE it calls one type of constructor while the non-CTFE calls another; So long as the structure is the same then passing it around wouldn't matter.
Jan 10 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 20:48:12 UTC, Era Scarecrow wrote:

 func(x); // x is not type string[string], is type 
 xxx!string,string

Thinking about it, if the AA is just syntactical sugar for a struct (say defined in core.memory) which handles that then the problem goes away.
Jan 10 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky 
wrote:
 + user defined implicit conversion so that AALiteral(K,V) 
 --*implicitly*!--> AA!(K,V)


 The other use case for user-defined implicit conversion were 
 already outlined before so I hope it will make its way in one 
 day.

I thought I heard talk of possibly moving AA's to a library implementation rather than a built in feature (Still 'built in' technically).
Jan 10 2013
prev sibling parent "Rob T" <alanb ucora.com> writes:
On Thursday, 10 January 2013 at 22:18:08 UTC, Era Scarecrow wrote:
 On Thursday, 10 January 2013 at 22:02:17 UTC, Dmitry Olshansky 
 wrote:
 + user defined implicit conversion so that AALiteral(K,V) 
 --*implicitly*!--> AA!(K,V)


 The other use case for user-defined implicit conversion were 
 already outlined before so I hope it will make its way in one 
 day.

I thought I heard talk of possibly moving AA's to a library implementation rather than a built in feature (Still 'built in' technically).

I was wondering the same thing: Why do AA's have to be built directly into the language rather than implemented within the standard library? AA's may be nice to have, but are they really all that fundamental? For example, everyone uses strings, but I suspect not everyone will use AA's. It could however be that some fundamental constructs in the D language make use of the built in AA's (tuples?), so if that is the case I can understand why they would be built in, but I do not know if this is the case or not. On a side note, I'm wondering if this may be a way that can help decide what should or should not be made a built in component of the language, i.e, If the language itself can make good use of the feature internally, then it's a good candidate for being built in, but if not, then it's a good candidate for being left out and instead implemented in the std lib or elsewhere. --rt
Jan 10 2013