From: Ryan Paul <segphault@...>
Date: 2004-06-12T20:18:43+09:00
Subject: Re: Appropriate use of camelCase

>> I'd take it a step further, if I
>> could. We should all have our own personal syntaxes and make parsers that
>> generate from our code to/from a common format - or perhaps have a
>> database that contains the code (I think the original dylan
>> implementation worked that way) and have tools that generate code in our
>> own personal syntaxes from the database, and vice-versa. Seriously, what
>> is wrong with it? Someday, Parrot might facilitate something like
>> that.

> 
> One thing that's wrong with it is that I do not consider myself (or the
> majority of other people) coming up with as nice a syntax as Matz has.
> Seriously -- didn't we all start using Ruby in large part because we
> thought Ruby syntax and visual style were wonderful?
>

I like many aspects of ruby's syntax, but there are MANY aspects that I
would change. I dont like having to use the 'end' keyword to terminate
classes and functions for instance. I do really like ruby's block concept
tho, and like being able to choose between { } and do end. Syntax
aesthetics are somewhat specific to the individual. I like things a
certain way, and I wouldn't want to deny someone else the ability to see
it the way they want to.

Furthermore, there are practical advantages to having completely mutable
syntax: one could easily construct elegant domain specific languages for
any task, and model the syntax in a way that is ideal for that task. In a
way, we already do that in some cases - using YAML for instance, to
describe large lists/hashes is significantly more practical and time
effecient than doing the same thing in pure ruby. That doesnt mean that
ruby has bad array/hash syntax, it just means that for certain types of
tasks it makes more sense to use a different syntax.

Ultimately, I think most seasoned programmers know what they like and dont
like as far as syntax goes, and almost all of us are capable of devising
our own syntaxes - its making the parsers and interpreters that we dont
want to bother with.

I have an interest in language preprocessors, and syntax extension
mechanisms. I'd like to see Right have something along the same lines as
camlp4, a preprocessing engine with a standard mechanism that facilitates
construction of arbitrary syntactic extensions.

 --SegPhault