Re: Why no numbers allowed in variables?

[David Kastrup]

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Thomas Morley <address@hidden> writes:
>>
>>> It was an observation, not a proposal.
>>> Speaking only for myself, I can perfectly life without the
>>> comma-syntax in definitions and their calls.
>>
>> It feels weird in definitions.  Don't remember whether there was some
>> original rationale for it (like consistency, possibly connected with
>> convenience in reusing parser rules).
>
> Ah, the way "property_path" is defined via "symbol_list_rev" and symbol
> lists also in function arguments are defined as being able to contain
> either '.' or ',' means that even if one forces the first separator to
> be a '.', the following separators are hard to avoid being also
> permissable as ','.
>
> So navigating around that inconsistency is pretty ugly: it will
> sometimes work and sometimes not.  But maybe definition and call of
> those kind of separated variables should at least be identical and
> consequently require a first dot even if for technical reasons the
> following separators may happen to admit commata.

I've taken a look, and the original admission of ',' to assignments was
as part of

commit 2a9bcb103d9fbe58c998c8c81761985da8bded2a
Author: David Kastrup <address@hidden>
Date:   Tue Mar 8 11:47:28 2016 +0100

    Issue 4790: Let ',' separate symbol lists like '.' does
    
    While the dotted list syntax is natural for hierarchical paths like for
    \override and \revert, it is less natural in cases that may now be written 
as
    
        \keepWithTag violin,flute,oboe { c''' }

so it's been a "consistency" thing as of the first commit.  The bug
tracker does not contain any discussion about that bit, so it's likely
that any chosen tradeoffs were the result of "internal dialog" rather
than a discussion with more than one participant.  I sort of lean
towards not allowing mixed lists at all but that would lead to a lot of
duplicated code in the grammar (once for '.' and once for ',') with the
end result that the parser pretends not to be able to guess what it is
supposed to do.  And if we add an error path where it does the right
thing after all, things get even more complex.

Also,

parts.1,1 = ...

will do something imaginably useful while

parts.1.1 = ...

will bomb out horribly since 1.1 is a floating point number.  And

parts.1. 1 = ...

does not look quite the same.  Still, it's not possible to write

1,1 = ...

and the incentive for allowing

parts,1,1 = ...

is not all that high.  So I somewhat lean towards at least enforcing the
first dot in assignments/recalls.

-- 
David Kastrup