Re: [GLISS] - alternative viewpoint

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>> What we're discussing is ideas.  No-one has to implement ideas.
>
> Well...
>
>> If there is widespread agreement that the idea is good, then at some
>> point it could be implemented.
>
> ... but as David has correctly mentioned previously, it is not
> fruitful to discuss something for a long time and make everyone agree
> to it, just to find out later on that the idea can't be implemented in
> the current framework.

"Case insensitity" is something that comes up a lot in computing, like
with file systems.  The general trend is that more and more systems that
have started out case insensitive are moving to case sensitivity since
the problems caused by inconsistent usage can't be all salvaged
automatically.  Most programmers with significant exposure to making
case insensitivity work develop a deep dislike against the barrage of
recurring problems.

So before choosing case insensitivity as a solution to some problem, it
might make sense to revisit the problem and see whether, for example,
killing CamelCaps and/or other naming choices and/or replacing them by
different schemes will not make the problem less relevant as it now
appears to users.

> It's a matter of fact that we are bound to what we have.  Everything
> else would be a complete redesign of LilyPond, which is certainly a
> noble goal but far, far away.  I don't think this is the intention of
> GLISS.

Guile itself would not mind case-insensitivity much, but our existing
code base would.  Not on a technical level, but with regard to the
current naming choices and possible conflicts.

>> We could certainly use it as a way to direct development - "hey,
>> David, when you're working on the parser, could you also work towards
>> making it case insensitive?".

Reserved words are lowercase anyway.  For the rest, try

(read-enable 'case-insensitive)

at the top of scm/lily.scm.

Good luck.  I really have no idea how far this will get you.  But I
don't want this in LilyPond myself: as I said, allowing inconsistent
entry does not buy you anything but sloppiness and surprises.

> The case sensitivity is special since it doesn't need syntactical
> changes.  However, other issues we've discussed recently are very
> difficult to implement for reasons that most of us don't understand.

Well, some of the things that _are_ implemented are very difficult to
implement as well (I am working on dialing back the complexity, too).
But if things create _conceptual_ complexity rather than implementation
complexity (due to parser limitations), I like them even less.

-- 
David Kastrup