Hi John, The parser you started is pretty much the same as what I have been implementing the past couple of months. The problem that exists in what I am working on existed in what I started with. I think you may have misread my first email in that this is not a language issue but is an implementation issue. I'll try to be clearer here to explain in terms of the problem I'm trying to solve in the new parser. First, underlying in csound, there is no explicit definition of what is a function. Functions and opcodes are all just opcodes with OENTRY's in the master OENTRY list. The only thing I found were certain conventions as to definitions of opcodes meant to be used as functions (see other email), but then they are not even hard rules by the old parser (as using cpsmidib as a function call works). Because of the implicit and ambiguous defintion of what opcodes are meant to be used as functions, this following section of the YACC grammar is problematic: function : T_FUNCTION { $$ = make_leaf(T_FUNCTION, NULL); } ; The LEX lexer must pass the parser a token of T_FUNCTION. The only way I did that in the new parser when I started months ago was to hard-code T_FUNCTION tokens in the lexer (in the HEAD branch, at the top of Jsnd/symbtab.c, you can see where I hard-coded it). I had done that only temporarily to test out the grammar, but now must really implement it. The problem above does not exist in the old parser because the lookup it does is directly looking for an opcode and a token of type function. It's being done in a context-dependent manner. Now, it may very well serve us to make the lexer work in a context dependent fashion with certain states being defined by the parser, and there is already one example of this in the UDO part of the parser to allow a single zero to be used as an inarg or outarg definition. This might need to be implemented if the definition of what is a function is broadened to allow calling other opcodes. So, for myself, to keep going with the new parser today, I am going work of the specification I loosely intuited from yesterday that functions are opcode entries that are defined polymorphically but without 0xffff entries and will set up the symbol table to define those that way. But I think we still need to define exactly what determines an opcode to be used as function by the parser. Thanks, steven On 10/12/06, jpff wrote: > I would much prefer there to be a clear distinction between opcodes and > functions, as indeed there was in my "new parser". I guess I just > think it would be clearer and easier to explain. > Alternative view is to go entirely functional.... > ==John ffitch > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net