Re: Expression-local variables and 'let'

>>A question of priorities. Nice has a few strong points to make. One is 
>>that a powerful type system can be used in practice, and that it bring 
>>improtant benefits. There are other interesting type systems around, but 
>>Nice's is unique.
>>
>>A second is that multi-methods is a better approach than class-based OO. 
>>There are other languages with multi-methods, but no mainstream one, so 
>>this point is also an important one to make.
>>
>>Third, that this approach to "OO" fits particularly well with the 
>>functional paradigm.
>>
>>2 and 3 taken together mean that you can basically get the best of both 
>>the OO and the FP world.
>>    
>>
>
>I agree with you. 
>
Glad! :-)

>I think that most of my suggestions (besides immutable by
>default) have been of the form "new feature X works against the goals above, and
>it complicates the language, so consider removing it." Examples:
>  * java-esque method definition/calling syntax
>    (confuses beginners' understanding of multimethods),
>  
>
We have discussed that extensively. Both approaches focus on making 
multi-methods used, they just differ on the evaluation of how to best 
get there.

>  * enums (haven't seen an example yet that shows them to be more useful
>    or concise compared to other constructs available in Nice).
>  
>
I'm keeping my judgement there. Given that they are not presented in the 
tutorial nor in the manual (apart from an example of valud dispatch), 
they should not really bother new users, so we can take the time to this 
this over.

>  * functions (you got rid of them).
>  
>
Yes. There was no concession to make for that one, so tht was easy :-)

>In other cases, my suggestions were intended to generalize proposed features:
>  * generalize block call syntax to allow multiple parameter blocks
>  
>
That's something to consider.

>  * expression-local variables: replace current "let" with "let..in"
>    as discussed extensively on this thread.
>  
>
I don't see how that relate to the goals. Let..in is certainly more 
alien to the general syntax than expression-local vars, which is the 
other side of the compromise.

>>Changing the default mutability status, for instance, seems to me to 
>>fall into this category. It might be a slight improvement, but the 
>>benefits would not be huge, especially as you kep both option (single 
>>assignment languages or pure functional languages are the ones that 
>>really explore a different way here). Anyway, with let and var, there is 
>>no default anymore, so you can just express your intention.
>>    
>>
>
>No, there is still a default for parameters and fields.
>  
>
Right. I'm just saying the 'let' gives you a nicer way to declare 
immutability than Java, so there is some progress, still.

>>general picture in mind. I'd prefer a language that brings novel and 
>>little-known ideas to a larger community (which itself brings the 
>>perspective of more libraries, tools, ...) than a "perfect" language 
>>that will appeal to very few because it's too big of a step for most 
>>people to make. This might be were an alternate syntax comes in, if 
>>really this is an important issue to some.
>>    
>>
>
>This is understandable. I would worry that an alternate syntax would just create
>more confusion. That is why I didn't suggest/implement an alternative one
>already--I even had a name for it: the "adequate" syntax.
>  
>
:-)

I thought you would choose "Nicer" ;-)

I there was a radically different syntax, it might not be so much 
confusing. That would work if basically you can regonize in no time, and 
for any part of the syntax, what style you are using. For instance, use 
juxtaposition for application, let .. in, no return, variable name 
before their type, ... Then they would appeal to mostly disjoint sets of 
people. One syntax would give "a better Java", the other one "a better 
ML" :-)

Daniel



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click