Re: Allow quoted identifiers like to be used like \"violin1", not just defined. (issue 6778055)

[dak]

On 2012/10/30 04:06:18, Keith wrote:
> Well, David has pointed out some shortcomings, but I am not sure if
they are
> practical problems.

A "practical problem" presumably is one the user can be bothered about.
I never claimed that problem class here.  Users are not interested in
language design or consistency or programmers having to work overtime
fixing problems and choosing bad compromises, or something being complex
to document or explain (one would notice that only when reading
documentation, anyway).

> The strings in
>    "violin1" = c2   { "\violin1" }
> must be literal strings,

You mean \"violin1" here.  Yes, quite so, but if that is a real concern
to you and not just a mock complaint, both are easy to change.  On the
left side of the assignment, rather trivially, on the right side, it
requires implementing \$ in the lexer which is perfectly feasible.

If you feel this is a dealbreaker to you, file the respective issue
request and it can be changed simply enough.

> The valid names for identifiers are no longer a simple lexer pattern,
but
> anything that can be put between quotes, making syntax highlighting
more
> difficult.
>    "\\" = c''1  { \"\\" }

Yes, I pointed out that syntax highlighting will be affected.  This was
discussed in the mailing list when I first mentioned this possibility in
the course of the GLISS discussion, and people were all "so what?" about
it.

Again: I don't consider \"..." a fabulous idea.  But it does not affect
existing syntax.  Making \"..." accept normal string escapes is not
necessary and can be replaced by just admitting an uninterpreted string
if you can give a good reason for it.  I took that choice for symmetry
considerations, but not interpreting string escapes would actually
simplify the code.

> There is apparently a more powerful array implementation in the works,
that will
> allow simply \violin1

Sure.

> And finally, we have the choice discussed above between
code-duplication and
> abuse of the Flex start-condition system.

Uh no.  As you pointed out, one just needs another start condition
(which is not an "abuse") to change the original code which you
considered an abuse, and I was planning to change this, according to
your suggestion, before committing anyway, just got not around to it yet
since I spent too much time on silly discussions.

At any rate, that's about 5 lines of duplication, and if they were so
totally worrisome to you, we also could have wrapped those in a
function.  But the additional start state, as you proposed, seems a
cleaner solution.

> By comparison, a simple change to the scan patterns
> http://codereview.appspot.com/6493072/diff/19001/lily/lexer.ll
> would be much cheaper and better-confined.

Oh, it _is_ cheap in code and the _code_ is well-confined (not that the
code for \"..." would be spread out significantly more).  The price is
to be paid in documentation and semantic inconsistency and complexity.
The latter is not well-confined.

http://codereview.appspot.com/6778055/