Well, this opinion is misinformed and hasty to say the least. J uses several parsers. Two most important are the explicit parser, which breaks down the controls structures, see 5!:7 http://www.jsoftware.com/help/dictionary/dx005.htm
and the interpreter, which is a context-sensitive bottom-up table-driven parser/executor: http://www.jsoftware.com/help/dictionary/dicte.htm (which is obviosly not recursive-descent). Speaking of SableCC, evident is not-uncommon confusion between AST and parse-tree: term "AST" used throughout but in fact it means "parse-tree"; looks like it was realized later in the work and even admitted "The default AST constructed by SableCC matches the concrete syntax tree (CST). The parser class can be customized through inheritance to modify the AST as it is constructed." But this customization is another flaw: concrete parser should be dependent on AST and not the other way around. Comparing LALR to LL is a matter of preference. Though it seems that LLs are more popular, being simple they are easy to hand-code and understand, and large grammers are easier to maintain too. Interestingly, LARL own flaws are conceiled from formal comparison, until concrete real example later in the text: "..to build a SIMPLE C..., we had to solve a few LALR(1) con icts by rewriting some parts of the grammar..." (The pause should probably be voices as "con[Hm]icts") The 10-year-old design definitely shows its age. Recently available attributed parsers (Coco/R) and tree transformers (AnTLR) make it even easier and more powerful, e.g. use simple action code to build true AST. For an attractive LALR parser, I would mention GOLD parser, which is nicely equipped with visual grammar builder and tracer, has many target languages. --- "metaperl.j" <[EMAIL PROTECTED]> wrote: > > > Oleg Kobchenko wrote: > > > > > > Like Lisp and APL/J/K, they all have very simple (to parse) > > langauge syntax: no precedence etc; dynamically typed; > > use live objects which can mutate (as opposed to C++). > > > > > > I dont think J syntax is easy to parse. Certainly not as easy as Scheme, for > instance. > > Also, I asked a Ph.D in CS with emphasis on Compiler Design (who is the > author of SableCC, the parser generator that is superior to ANTLR and > JavaCC) about parsing J and here is what he said: > http://lists.sablecc.org/pipermail/sablecc-discussion/msg00146.html > > Basically J is very ambiguous to parse. And the overloading of symbols for > monadic and dyadic cases complicates things even more. > > And also, data representation in J is not parseable. A rank-90 array of > shape 1 in each axis looks just like a simple scalar. > > But I suppose there might be some module designed for representing J data in > a way that allows for easy export/import. > > -- > View this message in context: > http://www.nabble.com/squeak-tf4744740s24193.html#a13692391 > Sent from the J Chat mailing list archive at Nabble.com. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
