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
[email protected]
http://vpri.org/mailman/listinfo/fonc
