Re: digits in variable names: current state of things.

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> Hi,
>
> from what i see there are two concurrent proposals about introducing
> digits in variable names:
> http://codereview.appspot.com/6778055/ by David
> http://codereview.appspot.com/6493072/ by Keith
>
> i'm a bit confused - i'm not sure wheter these patches are mutually
> exclusive or not.
> Anyway, here's my general opinion (it's more about the UI than actual
> code):
> - having to enclose identifiers in quotation marks feels more natural
> to me than using some special sign between letters and digits (i.e. i
> like \"violin1" better than \violin+1 (or \violin.1)),
> - "parser simplicity" is most important to me. In other words, i vote
> for a solution that fits smoothly with other syntax constructs,
> introduces as few exceptions as possible, doesn't produce
> surprising/confusing results, etc.
>
> Of course it would be great if 
>
> On Tue, Oct 30, 2012 at 7:05 AM, <address@hidden> wrote:
>> [...] \violin1, \violin 1, \violin $(1+1) [would] all work, [...]
>
> however, my impression from previous discussions was that doing so
> would mean creating exceptions in the parser,

What do you mean with "exceptions in the parser"?

> ambiguous syntax

Octave checks contain an equals signs, so if you can have a scheme
function on the left side of an assignment that has a music argument,
the equals sign can be either part of the music argument or of the
assignment.

> and making some other interesting stuff impossible.

Not really.  It's just not possible to do nicely right now since the
type of a music function must be known to the parser in advance, and
once you get "vector of xxx", the number of different types just
explodes.  So having this available usefully more or less means getting
rid of the "must be known in advance" design of the parser, and I am
working on that.  It is just slow progress.

> So, i'm a bit lost...

None of the existing proposals is going forward because the "vector
solution" (branch dev/vector contains a proof of concept for just
vector-of-music) might obliterate the need of either, so there is no
point in establishing something more ugly in advance which one might
then have to support in perpetuity.

-- 
David Kastrup