Re: Expression-local variables and 'let'

Quoting Daniel Bonniot <[email protected]>:

> Isaac Gouy wrote:
> >IIRC one of the unsafe aspects of imperative languages is that it isn't
> >clear when we've changed the state - so we've had a whole slew of
> >single assignment languages.
> >
> >What was the objection to making single-assignment default?
> >  
> >
> 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. 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),
  * enums (haven't seen an example yet that shows them to be more useful
    or concise compared to other constructs available in Nice).
  * functions (you got rid of them).

In other cases, my suggestions were intended to generalize proposed features:
  * generalize block call syntax to allow multiple parameter blocks
  * expression-local variables: replace current "let" with "let..in"
    as discussed extensively on this thread.
  
> 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.

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

- Brian




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