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

[Janek Warchoł]

On Thu, Nov 1, 2012 at 11:43 AM, David Kastrup <address@hidden> wrote:
> Janek Warchoł <address@hidden> writes:
>> 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"?

I'm sorry, these discussions happened some time ago and i don't
remember what exactly was the problem.  I remember that my impression
was "implementing digits in identifiers would make things complicated
and less consistent - we don't want this".

>> 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.

Ah.  I understand that either octave checks' syntax would have to be
changed, or something nice would be impossible/problematic/ambiguous
to implement - i vote for changing octave checks syntax.

>> 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.

ah, ok.  This reminds me to send my donations!  Expect them to come in
a few days.

> 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.

definitely.  Good luck with vectors then!
Janek