Dear Shawn, > My current understanding: > - .l is a proper subset of the .k maru s-expression language / syntax
You are being over-generous with your inference of intelligence in the design and implementation of the language and supporting infrastructure. The existence of the two suffixes is just sloppiness on my part; there is no difference at all in the interpretation of the content of files ending in '.l' and '.k'. If anything, the original confusion arouse because of an ultimately imaginary distinction between a minimal kernel language of ASTs stored in .k files and a more end user-like language in .l files. You can use any extension you like on your source files: the use of .k or .l is merely a naming convention I used for mine. > - there are things in the .k environment that are available by default e.g. > `define-class` that aren't in the default .l environment but that's just a > mater of including those form definitions in .l sources. Correct -- and the extensions are not significant. The default environment is set up by the executable 'eval' and then (unless you suppress it with '-b') extended by 'boot.l' before things mentioned on the command line are loaded and evaluated. To use 'define-class' you need to do something like '(require "define-class.l")' in any source file, whether it ends in .l or .k or anything else you choose to use. There is nothing made implicitly available in the environment based on the extension. > - The only meaningful difference is the { } form that hooks into the reader > and accepts a grammar after which, the rest of the reader input may or may > not be the continued subject of the peg parser (i.e. on the fly language > change within a single source). The curly-brace syntax-extending mechanism is set up in 'repl.l', which also takes over processing the remaining command-line arguments (hence its name). To use the mechanism you just include 'repl.l' on the command line before the source files that depend on it. So in ./eval foo.l ./eval repl.l bar.l the code in bar.l can use the curly brace syntax to create/extend grammars, but the code in foo.l cannot. The s-expression code in foo.l will be parsed by the built-in parser in 'eval' and that in bar.l by a parser generated from peg.l. (Beyond the curly braces, there are likely small differences between the s-expression syntax accepted by the hand-written parser in 'eval' and the one generated from peg.l.) > Is there a place where this is summarized? Not explicitly. Maybe the 'README' file should be liberally extended with comments explaining some of this? Regards, Ian _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc