[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: digits in variable names: current state of things.
From: |
Janek Warchoł |
Subject: |
Re: digits in variable names: current state of things. |
Date: |
Thu, 1 Nov 2012 17:04:57 +0100 |
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