Re: newbie impression of Dylan syntax
Alexey Muranov <[email protected]>
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <[email protected]> |
Ok, i see that my first impression was wrong, removing semicolons at the end of line would break the existing code, and concatenating two lines without a semicolon could change the meaning of the code without braking it. However, i have also noticed that Dylan is not truly whitespace insensitive: it uses "// ..." comments as opposed to "/* ... */" ! (I am smart!) So i have another proposal of improving, in my subjective opinion, the visual appeal of Dylan. Make semicolons at the end of line optional, and use backslash "\" at the end of line to tell the compiler that the line continues. If a line is clearly incomplete, the backslash is optional. This would break the existing code. However, all the code can be converted to the new format with a simple script. Maybe some compiler directive at the beginning of the file can tell the compiler which syntax to use. Benefits: * In my opinion, it would be easier to read, as a line break serves already as a clear separator, and having a hint that an expression continues to the following line seems more reasonable than having a hint that an expression is complete. * It is more common to end an expression at the end of line than to continue, so there would be less typing. * I am used to Ruby :). Best, Alexey. > Date: Wed, 27 Feb 2013 16:51:27 -0800 > From: Dustin Voss <[email protected]> > Semicolons are necessary to separate statements, but the parser can determine the extent of a ?<something>?end <something>? block without semicolons. > > Dylan?s syntax is too extensible to avoid the need for semicolons. Plus, the recursivity of the syntax means the developer will often need to break statements across different lines to make them readable, or combine things on a single line to make them more compact. For example, > > method (x) => (y) format-out(?Yo, I?m squaring %d into a vector\n?, x); vector(x * x) end (15).size > > is, I think, a legal replacement for code like > > square-into-vector(15).size > On Feb 27, 2013, at 4:08 PM, Alexey Muranov <[email protected]> wrote: > >> Hello, >> >> i have already posted to this list asking about Snow Leopard support, sorry for not staying in touch, i am afraid i may not have enough time to dedicate (programming is only my hobby, and i already work on a small Ruby web application). >> >> I just wanted to share my first impression of Dylan, for whatever it is worth. I liked Ruby, but i am getting tired with its small inconsistencies. It looked to me like Lisps are really beautiful languages, but i am not a fan of parentheses (if only they used curly braces! :)). >> >> Dylan syntax looks readable to me, but i am wondering about one thing: are all the semicolons at the end of each line necessary for parsing? My first impression would be "no", but maybe i am missing something. If only it was possible to make semicolons at the end of line optional, i think it would have significantly increased the visual appeal of Dylan and saved some typing. >> >> In my opinion, if accidentally concatenating two lines can break the code at compile time but cannot change the meaning of the code, the language can still be considered white-space insensitive in a weaker sense. >> >> Best regards, >> >> Alexey. _______________________________________________ hackers mailing list [email protected] https://lists.opendylan.org/mailman/listinfo/hackers