From: tom.rmadilo on 7 Jun 2010 13:04 On Jun 7, 8:46 am, Fredrik Karlsson <dargo...(a)gmail.com> wrote: > Hi all, > > Sorry, I have been away for a while - thank you for the great input > though! > > Some points for me to adress: > > * No, yeti does not work for me, and it seems to happen only in Tcl > 8.6: > > frkkan:demo zak$ tclsh8.5 parse-calc.tcl > Result is 14 > Result is 42 > frkkan:demo zak$ tclsh8.6 parse-calc.tcl > Segmentation fault > frkkan:yeti-0.4.1 zak$ tclsh8.6 yeti.tcl > Segmentation fault > frkkan:yeti-0.4.1 zak$ tclsh8.6 ylex.tcl > Segmentation fault > # Trying to just load the files: > frkkan:yeti-0.4.1 zak$ tclsh8.5 ylex.tcl > frkkan:yeti-0.4.1 zak$ tclsh8.5 yeti.tcl > frkkan:yeti-0.4.1 zak$ My suggestion is to avoid using 8.6, it is still in beta and there have been a few reports of problems with incrTcl in 8.6. > * Sorry, but no - I am not able to influence the language being > parsed, and making commands and just executing them in a safe > interpreter is something I considered, but it is impossible I am > afraid (or at least, I think it is). The structure of it is more like > C-style assignment of variables (X operator Y) rather than "predicate > X Y", so it seems tricky to do. lex/yacc based generators excel when you have multiple lexing contexts. If Yeti supports this, it would be nearly impossible to efficiently replicate this with the Tcl parser. Also the way yacc picks what to execute is also difficult to reproduce in Tcl command dispatching. I just haven't seen interesting examples with Yeti, or the other Tcl based generators to compare how these things are handled. I only assume these tools exist for a good reason, and hopefully you can reuse the existing lex/yacc flex/bison literature as documentation. There is nothing fun in writing or maintaining this type of code (the lex/yacc input files).
From: Helmut Giese on 7 Jun 2010 13:48 Hi Fredrik, >* No, yeti does not work for me, and it seems to happen only in Tcl >8.6: Tcl 8.6 is still beta - do you _have_ to use it? >* Sorry, but no - I am not able to influence the language being >parsed, and making commands and just executing them in a safe >interpreter is something I considered, but it is impossible I am >afraid (or at least, I think it is). The structure of it is more like >C-style assignment of variables (X operator Y) rather than "predicate >X Y", so it seems tricky to do. If you take the code from http://wiki.tcl.tk/3906 you have a Yeti-based parser for all of C (provided you don't use 8.6). How about getting it to run and then throw out everything you don't need from the grammar? >* Page - I was refering to the page package in tcllib, which seemed to >me to be parser-like. Maybe I was wrong... Yeah, a reasonable assumption. I would love to see some documentation / examples for the stuff from grammar::*, but last time I looked I didn't find anything (though it has been a while). HTH Helmut Giese
From: Andreas Kupries on 8 Jun 2010 01:46 Fredrik Karlsson <dargosch(a)gmail.com> writes: > Sorry, I forgot one: > > page in tcllib - sorry, but is this package actually supposed to be > used? The documentation is, I think, mostly readable if you wrote the > package yourself, or already know quite a lot about how to use it. > Sorry if someone thinks I am being unfair, but this is my honest > opinion. Quite true also (I did write this thing). I recently created a replacement, 'pt', also in tcllib. Documentation starts here http://docs.activestate.com/activetcl/8.5/tcllib/pt/pt_introduction.html and http://docs.activestate.com/activetcl/8.5/tcllib/pt/pt.html Hopefully that is better. -- So long, Andreas Kupries <akupries(a)shaw.ca> <http://www.purl.org/NET/akupries/> Developer @ <http://www.activestate.com/> -------------------------------------------------------------------------------
From: Gerald W. Lester on 8 Jun 2010 23:46 Fredrik Karlsson wrote: > Hi all, > > Sorry, I have been away for a while - thank you for the great input > though! > > ... > * Sorry, but no - I am not able to influence the language being > parsed, and making commands and just executing them in a safe > interpreter is something I considered, but it is impossible I am > afraid (or at least, I think it is). The structure of it is more like > C-style assignment of variables (X operator Y) rather than "predicate > X Y", so it seems tricky to do. Have you looked at TclX's File Scanning commands as a way to process your file? -- +------------------------------------------------------------------------+ | Gerald W. Lester, President, KNG Consulting LLC | | Email: Gerald.Lester(a)kng-consulting.net | +------------------------------------------------------------------------+
From: Fredrik Karlsson on 9 Jun 2010 16:05
Hi, This looks very promising indeed, but still at bit opaque (at least for me). Given that I have a grammar in PEG format in the file grammar.peg, how do I get a TclOO that would be a parser for that grammar? What I have is: ---- set peg [read [open grammar.peg r] ] set gram [pt::peg::import $peg] --- , but how to get the parser? /Fredrik On Jun 8, 7:46 am, Andreas Kupries <akupr...(a)shaw.ca> wrote: > I recently created a replacement, 'pt', also in tcllib. > > Documentation starts here > > http://docs.activestate.com/activetcl/8.5/tcllib/pt/pt_introduction.html > and http://docs.activestate.com/activetcl/8.5/tcllib/pt/pt.html > > Hopefully that is better. > |