Mark Fredrickson:
> 1. On adding @@: Less is more. As (I believe) David noted, trying the
> syntax to the underlying semantics is a losing proposition. I wouldn't
> worry about every corner case. If a given language has a construct or
> two that doesn't look great in sweet expressions, let's not fret about it.

Agree.  Still, I'd rather try to find solutions, and then see if they're worth 
the trouble.  If nothing else, that helps creativity... trying to solve one 
problem may expose a better approach to a different problem.

> 2. On the procedure(...) form: I'm thinking this should not be a part
> of SE. It saves no characters. It distances SE from regular homoiconic
> syntax. I love the idententation and brackets as macro, but this
> component seems less necessary.

It's not strictly necessary, that's true.  But I think it really helps. One way 
to make a user interface "user-friendly" is to try to make it similar to what 
the user already knows, and this rule really does that.  I note that MANY 
"readable" Lisps add this component at least, so clearly others have come to 
that conclusion too.

It _is_ still homoiconic, it's just an alternative abbreviation for a common 
case. After all, nearly all Lisps allow both 'x and (quote x), and few complain 
about that... and that abbreviation is MUCH stranger.

Oh, just to be pendantic: This DOES save one space per use when there are 1 or 
more parameters (between function name and first parameter). E.G., "(f a b)" 
takes 7 characters, while "f(a b)" takes 6 characters. That one character 
savings is NOT a good argument for this syntax :-).

In any case, you can certainly use SE without using that aspect of it.

> Again, great work all around. These examples have been great!

Thanks!  I view these as kind of "experiments" in the scientific sense. Create 
a hypothesis that "ruleset X is good", and then try it out on lots of cases.  
If they expose a problem, then rejigger the ruleset and redo the experiments.

One challenge is making the rules simple.  A computer can handle complex rules, 
but humans don't handle complex rules well.

--- David A. Wheeler

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Readable-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Reply via email to