Martin Coxall wrote:
> 
> On 1 Oct 2006, at 11:40, M. Edward (Ed) Borasky wrote:
> 
>> Martin Coxall wrote:
>>> In any case, there's a question about about to what extent you *should*
>>> host DSLs internally. It's my feeling that if you want to inline a DSL
>>> in your code, make sure that language is still syntactically
>>> recognizably a Ruby. Ruby on Rails is a classic example.
>>
>> The problem I have with the two best-known Ruby DSLs, Rails and Rake, is
>> the somewhat non-intuitive mix of words that don't begin with colons,
>> and symbols, which do.
> 
> True, but at least it's recognizably, syntactically, Ruby.  I'm not sure
> there's a way round the colon issue, you just have to live with it.

Yeah ... as does the person who's trying to put a timestamp like '10:30'
into a DSL in the "natural way". That "natural way" would work in Forth,
by the way, and is in fact the historical way to do things in Forth. In
Forth

    from 10:30 to 11:30

the 'from' word would scan and parse the '10:30' word to its right, etc.

>> And Rails requires YAML in some places that are
>> jarring to the reader. Why is the database connection description file
>> in YAML and not in "a Ruby"?
>>>
> 
> I guess, because the feeling is that YAML is more recognizable as
> user-editable config than a Ruby script, which would tend to frighten
> some people off?

I was actually going to post this as a separate question for David
Black, since it arose in my reading of the section in his book
describing how Rails uses the Ruby syntactic freedom to make programming
more like editing a config file. My conjecture was that the database
config file was in YAML rather than Ruby because YAML is a more
user-friendly way to represent a *nested* set of key/value pairs than
the Ruby code.

In fact, maybe YAML is another shortcut in constructing DSLs, since
everything is text in a YAML file without all those nasty single or
double quotes getting in the way.

> Well, C is not a great language for writing parsers in,

K & R and the rest of the UNIX founders apparently thought otherwise. :)