On Fri, 10 Apr 1998, Russell F. Pinkston wrote:

[snip]
> Actually, the name conflict issue is an old one which really should be
> resolved in the parsing of the orchestra, IMHO. Is there any reason why an
> opcode name can't be distinguished from a result variable name by context?
> E.g., most unit generator opcodes can never (usefully) appear without a
> result variable to the left of it. If there was ever a confusion, give an
> error. Otherwise, let people name things as they wish. 
> 
> P.S., If anyone ever does get around to rewriting the orch parser, I also
> think mixed upper/lower case variable names should be allowed...

I actually *got* around to rewriting the orch parser. The lex/yacc
skeleton with primitive structures is sitting at:

	ftp://musart.dist.unige.it/CSOUND/csound-parser-v0.0.tar.gz

or

	ftp://musart.dist.unige.it/CSOUND/csound-parser-v0.0.zip

In fact, it handles upper/lower case names automatically (I did not
even *think* it should not). It may allow usage of opcode names as
variables (I have to check) - but I cannot decide whether it is a good
idea or not; the question is - opcode names should be considered keywords
or not? Currently, in the skeleton they are not, so it should be possible
to use them both as variables and opcodes...

If we want to integrate this parser into the regular distribution, more
work is needed - and I would like to know if this is desired by the community
or not.

Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
 
Re graphics: A picture is worth 10K words -- but only those to describe
the picture.  Hardly any sets of 10K words can be adequately described
with pictures.