Thesis on metaprogramming in D

[Brad Anderson]

Daniel Keep wrote:
> Don Clugston wrote:
>> Daniel Keep wrote:
>>>  > def sr = System.IO.StreamReader ("SomeFile.txt");
>>>
>>> Immutable run-time variables.  You can assign anything to them, and
>>> then it can't change.  AFAIK, D's const doesn't let you do that.
>>
>>
>> It does, but only for class member variables. There are two 'const's
>> in D, one for literal constants, and the other which is once-only
>> assign, and should probably be called 'final' instead.
>>
>> class SomeClass {
>>     const StreamReader sr;
>>     this(char [] filename) { sr = System.IO.StreamReader(filename);}
>> };
>>
> 
> The thing that *really* struck me was that when I wrote some stuff in
> Nemerle, it was amazing how often I didn't actually need mutable
> variables.  I wonder what affect having immutables in D would have
> optimisation-wise...

Not sure, but it would also help get closer to the Erlang model of concurrent
programming via message passing.  Erlang is all immutables, iirc.  CL-MUPROC,
a Lisp attempt at this Erlang model, treats immutability as a 'guideline' and
let's the developer be grown-up.  But it uses OS threads instead of Erlang's
lightweight processes. :(

> 
>> [snip]
>>
>>>  > macro while_macro (cond, body)
>>>  > syntax ("while", "(", cond, ")", body) {
>>>  >   <[
>>>  >     def loop () {
>>>  >       when ($cond) {
>>>  >         $body;
>>>  >         loop ()
>>>  >       }
>>>  >     }
>>>  >     loop ()
>>>  >   ]>
>>>  > }
>>>
>>> Do THAT with templates :3
>>
>>
>> void While(lazy bool cond, void delegate() body) {
>>    for (; cond; ) body();
>> }
>>
>> <g>
>> Or if I can't have for() as a primitive:
>>
>> void While(lazy bool cond, void delegate() body) {
>> loopstart: if(cond) goto done;
>>     body();
>>     goto loopstart;
>> done:
>> }
> 
> True, but it's not quite the same.  The D version has that outlying
> closing paren which is, frankly, really ugly.  Also, the D version is
> doing a function call, whereas the Nemerle version is actually expanding
> an AST.
> 
> Of course, these things could probably be solved with a little more work
> from the compiler: allowing trailing delegate literals, and inlining
> delegate literals.  *drool*
> 
>>> It would be foolish to think that Nemerle isn't an amazingly powerful
>>> language.  D is good, and its' templates are very powerful, but
>>> they're not THAT powerful.
>>>
>>> There is always more to learn :)
>>
>>
>> Very true.
>> It does seem, though, that Nemerle and D are exploring a quite similar
>> 'paradigm space' (so there's probably quite a bit each can learn from
>> the other). Yet neither has really caught up with Lisp. Yet.
> 
> No language will ever catch up to LISP: the only way to do that would be
> to become LISP, and then you have to deal with all those bloody
> parentheses :3

;)

> 
>     -- Daniel