Re: Understanding symbol-list? variable names

[Aaron Hill]

On 2018-06-08 04:35, Urs Liska wrote:
> Am 08.06.2018 um 12:43 schrieb David Kastrup:
> > Urs Liska <address@hidden> writes:
> > > But I can do
> > >
> > >      {
> > >        #(#{ \my.function #})
> > >      }
> > Or $#{ \my.function #} but ugh.

Could $ be extended to support something like `$\my.function` as an 
abbreviation of the above?  Granted, it would not be nearly as 
convenient as having `\my.function` work as intended.

> > > I would like to find a smoother syntax to invoking functions like 
> > > this
> > > because I'd like to explore the possibility to create a namespace of
> > > functions like \mylib.function-one, \mylib.function-two etc. But it
> > > would only make sense if there's a really easy end-user syntax, and 
> > > to
> > > get there I'd have to first understand what is actually happening (in
> > > the parser?) when \my.function is encountered.

From just the perspective of naming things, it would seem the easiest 
option is to just stick with hyphens.  Underscores appear to be valid 
for naming as well, though the potential of adding snake case to 
LilyPond's mixed world of kebab and camel might be too much for folks.

That said, the bigger idea of namespaces would be very interesting.  If 
we had some form of aliasing or prefixing of names, we could abbreviate 
the longer names needed by libraries to avoid collisions:

%%%%
  \version "future"
  reallylonglibraryname-thing-one = ...
  reallylonglibraryname-thing-two = ...

  {
    \namespace reallylonglibraryname {
      \thing-one ...
      \thing-two ...
    }
  }
%%%%

Of note, the usage above omits the hyphen as part of the prefix.  So, 
LilyPond would have to potentially insert a hyphen (or underscore) when 
resolving identifier names.  That would mean, within the scope of 
`\namespace foo`, `\xyz` would resolve as either `\fooxyz`, `\foo-xyz`, 
or `\foo_xyz`, falling back to `\xyz` should none of the alternatives be 
defined.  This could be simplified such that only hyphens are supported 
but would force a particular naming convention.

By the by, I noticed a little inconsistency with the support for commas 
within symbol lists.

%%%%
  \version "2.19.81"
  foo,bar = { c'4 }
  {
    \foo.bar % works
    \foo,bar % error: syntax error, unexpected ','
  }
%%%%

I would have expected the original assignment to fail, but the parser at 
that point seems fine with the comma as an alternative to a period for 
defining a symbol list.  However, then, at the point of referencing the 
variable, the parser is not able to form a symbol list in the same 
manner.

-- Aaron Hill