> > On Feb 23, 2018, at 8:56 PM, Matthias Felleisen <matth...@felleisen.org> > wrote: > >> • Racket J experimental package > The docs suggest that this is a truly strange approach, writing programs as > strings and then compiling them into Racket. >
This is a common thing with J implementations. J has the rough idea of syntax trees, but not exactly as a static property of a piece of code. Juxtaposition is very overloaded in J's concrete syntax. The way code parses (whether it's first-order function application, second-order function application, or a function composition form; which terms are arguments to which others, etc.) depends on the values held dynamically by the identifiers appearing in that code. The usual resources on how to write an interpreter by mapping abstract syntax to behavior don't quite get the job done for J because it's nonobvious how to map a whole program's concrete syntax to abstract syntax. Whether a given program has definite a parse tree is undecidable, so J implementations either don't statically construct a parse tree for the whole program or don't implement all of J. In the case of this package, the parser only gets as far as the paren-nesting structure, and then resolving anything within parens is handled at run time by the `sentence' procedure in private/sentence.rkt. --- Justin Slepak PhD student, CCIS -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
