Re: Dylan stuff

On Jan 17, 2013, at 4:54 PM, Bruce Hoult wrote:

> I agree.
> 
> My suggestion, if I was to start again, would be for the rule
> 
> http://opendylan.org/books/drm/Phrase_Grammar#XREF-2115
> 
> ( parametersopt ) => variable ;
> 
> to have "variable" changed to "type". The return value for a function
> with a single value seldom needs naming. It's implicit from the name
> of the function. It's pointless having to name it "res" just so you
> can add a type. This is one of the most common errors people new to
> Dylan make[1] as they're used to just specifying a type for the return
> value.
> 
> When you have multiple return values — a feature few other languages
> have — it's much more useful to name the return values.
> 
> Unfortunately, this is incompatible with all existing code.

I can certainly make the s-expression syntax preserve names for return values, as in the sample I offered. I personally like that less, but preserving compatibility with the existing language and practices is more important than my personal taste. Also, it's occurred to me since last night that if the s-expression syntax didn't provide for named return values, that would be a gratuitous differnce from the infix syntax, and I think those are to be avoided.

> Another option would be to make it possible to pass
> required-parameters to functions by name and have the compiler reorder
> them (if necessary). This is useful in general, especially with
> functions with many arguments, but in particular it would provide an
> (optonal) use for return value names.
> 
> [1] the other one of course is local bindings shadowing methods,
> especially accessor methods.

That's a good point. When working with Dylan day-to-day, I appreciated the way it handled slot naming and getters and setters. On the other hand, aliasing accessors is a real problem that crops up often enough to be a pain.

There are other ways to do it. Common Lisp, for example, doesn't create any accessors unless you explicitly tell it to, and then you have to tell it what names to use. That doesn't guarantee that a program won't unintentionally alias accessors, but it create more opportunities to guard against it, and in practice, I've seen the problem crop up less often in CL programs.

That raises another question: to what degree should Dylan hackers regard the language design as malleable? To whom does its definition belong nowadays? Is there a "Dylan Request for Implementation" process? Should there be?
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers