Bruno Medeiros 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.
>>> > What's the difference from C# and Java's 'final'? Is the variable transitively unchangeable, or just the immediate value?
>
I'm not really sure what 'transitively unchangeable' means... >_<
Firstly, isn't 'final' just used for class members? This is used for local variables (or members, if I remember correctly). As for the second sentence, it's immutable storage. So you can't change what's stored in the variable, but if you've stored a reference, then you can mutate what's being referenced.
-- Daniel

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...
> [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

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

Steve Horne escribió:
> On Mon, 27 Nov 2006 15:23:33 -0300, Leandro Lucarella
> <llucarella@integratech.com.ar> wrote:
> >> The center of my thesis would be adding meta-classes[1] to D, and maybe some other meta-programming features D could lack of (maybe some kind of access to the AST like XLR[2]).
> > I can't really offer any useful support, but if I understand what you
> are saying, I can offer encouragement.
Thanks for your support. Any other thing to say about the original topic?
I've noticed a tendency of this list to get rather silly[1]... I mean, off-topic =)
[1] I should posted this to a Python mailing list ;)
--
Leandro Lucarella
Integratech S.A.
4571-5252

Daniel Keep wrote:
> Bruno Medeiros 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.
>>>>>>> What's the difference from C# and Java's 'final'? Is the variable transitively unchangeable, or just the immediate value?
>>> > I'm not really sure what 'transitively unchangeable' means... >_<
> 'transitively unchangeable' or transitively const, means that in the case of references or pointers you can't change what is being referenced (and recursively so on). It's a transitive (recursive) read-only.
> Firstly, isn't 'final' just used for class members? This is used for local variables (or members, if I remember correctly). As for the second sentence, it's immutable storage. So you can't change what's stored in the variable, but if you've stored a reference, then you can mutate what's being referenced.
> > -- Daniel
Then that is just like 'final'. But I've realize now that this 'final' construct is only called 'final' in Java. The C# equivalent is actually called 'readonly' (http://msdn2.microsoft.com/en-us/library/acdd6hb7.aspx), whereas I thought it was 'final' too. Also, indeed the C# 'readonly' can only be used on fields, but the Java 'final' can be used on any variable, such as locals. And like Don said D has that feature too, but hideously hidden behind 'const'. -_-'
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Fri, 01 Dec 2006 00:35:36 +0800, Daniel Keep <daniel.keep+lists@gmail.com> wrote:
>Don Clugston wrote:
>> 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
Not sure I agree entirely.
In my view, the things that define the Lisp language are...
1. The metaprogramming stuff, with a rather sparse core language
being extended using library macros.
2. The list based on pair (cons) objects.
3. The explicit AST-structuring using parentheses.
Well, Nemerle has metaprogramming that is basically what Lisp does with some extra tweaks. Nemerle has pair-object based lists. And Nemerle has explicit AST-structuring using parentheses (it has a pre-parse stage to handle this).
Nemerle is heavily Lisp influenced. It just takes ideas from other places too. Personally, I think it may well have overtaken Lisp - just as powerful (within the limits of the .NET platform), yet more immediately usable.
--
Remove 'wants' and 'nospam' from e-mail.