Waldek Hebisch <[EMAIL PROTECTED]> writes:
| >
| > I think we need to have a basic interpreter, and a basic compiler
| > in the sense that they are almost like the interpreter and compiler,
| > but they "know" only
| >
| > * simple types: Boolean, Integer, Float
| > * constructed types: List(T), Vector(T)
| > * fundamental structure: Category
| >
| > Form that, we must separate and rationalize the database construction.
| >
|
| Current compiler (before algebra bootstrap) does not know about Integer.
I don't think so.
The internal AST that eventually reaches the type analyzer and the
semantic analyzer, starting from compTopLelve, already contain mention
of Integer (and the other basic types).
| And Integer depends on large part of algebra. So I would say that such
| basic compiler while a noble goal would require substantial algebra
| rewrite. Such rewrite in turn need something like Aldor post facto
| extension.
By "simple type", I don't expect the basic type to understand beyond
simple operations defined on their domains.
The glorious version of Integer is not needed wholesale when starting
the boostrap process. The glorification is a set that needs to come
after. Yes, post facto extensions are ways to achieve late
glorification -- and if you look at the practice, this is not fancy;
just think "type classes" (Haskell), which Axiom would have invented
two decades ago if it had post facto extensions.
| As an excercise I tried to make a minimal algebra. I compiled
| about 20 very simple domains and categories and generated corresponding
| databses, but resulting interpreter was non-functional. More effort
| would probably give functional system, but ATM I am not sure if such
| system is useful for bootstrap.
I don't think the interpreter is a good way tp arrive to the
bootstrap. We must be in "type checking" mode, not "type inferencing"
mode where we will be trying to infer and load things. No, that way
lies madness.
| > We must also be able to process a file without first having to split
| > it into several chunks. We have been able to process SPAD files that
| > way; making )abbrev a no-op.
| >
|
| In longer run sure.
Well, Axiom has 25-year horizon; so not sure what you mean by
"longer run" :-)
| ATM I am using quite different method: I dumped
| parse trees of the whole Axiom algebra into a file. So now I can load
| the whole algebra just as a single S-expression.
Well, (almost) everything is an S-expression; so I must ask which
"form" do you save an load? The parse tree? the parse form? The
internal AST? or the generated Lisp code?
What other thing we have been doing, we have found both the parse form
(not the parse tree) and the internal AST useful to save and load later.
A third form, not conveniently present in Axiom at the moment, is one
where either the parse form or the internal AST is completely typed
(just before code generation).
| I am loading this
| S-expression into sbcl running various analyses on it. The idea is to
| write (in Lisp) a simple compiler capable of extracting type declarations
| and generating from them Axiom databases.
Oh, that is simply done in Boot and I do hope you don't go to Lisp for
that. Just catch the parse form from postTranform or parseTransform.
I do sincerely hope, we don't end up multiplying parsers, analyzers,
type checkers, macro expanders, each with its own share of bugs, and
mix all those in form or Axiom!
[...]
| Concerning abbrev declaration: I am not sure how to find out wether
| something is a package or a domain without using information from
| abbrevs.
We should get to a poing where we don't need to distinsguish that!
Now, if you look at a capsule, it tells your whether something "is"
for a domain or not by the presence or absence of 'domain in the
category declaration. Again look at the the internal AST produced by
parseTransform.
I'm sorry the whole documentation is not online yet, but many things
are happening and I need to petition for 48h in a day.
Th algebra interface to the parser is very simple minded. There is
work going on to define different levels of fully typed ASTs.
-- Gaby
-- Written by Gabriel Dos Reis (gdr AT cs DOT tamu DOT edu)
-- Last modified on Jan 15, 2007.
--
-- This file contains a low-level code for parsing
-- a Spad source file into an internal AST. The
-- AST, for the entire file, is presented as a list of
-- toplevel statements (mostly definitions).
-- Since this is low-level code, I don't expect people
-- to get here, and you cannot directly use it. If you think,
-- you need to get to here, then something is already wrong.
-- There is a higher-level interface, written in SPAD, to this
-- code. See gdr-spad-parser.spad.
--
-- To use this file:
-- (1) translate it to Common Lisp, with bootsys:
-- bootsys -batch -eval '(boottran::boottoclc "gdr-reader.boot")'
--
-- (2) compile gdr-spad-parser.spad
--
--
gdrParseSpadFile sourceFile ==
$SPAD : local := true -- we are parsing Spad,
$BOOT : local := false -- not Boot.
OUT_-STREAM := _*STANDARD_-OUTPUT_* -- spit any noise to
-- the standard output
-- we need to tell the post-parsing transformers that we're compiling;
-- few parse forms have slightly different representations
-- depending on whether we are in interpreter mode or compiler mode.
savedInteractiveMode := $InteractiveMode
$InteractiveMode := false
oldParserAutoloadOnceTrigger() -- load parsing functions
oldCompilerAutoloadOnceTrigger()
INIT_-BOOT_/SPAD_-READER()
savedInStream := IN_-STREAM -- we need to restore the
-- global input stream state
-- after we finished messing
-- with it
IN_-STREAM := MAKE_-INSTREAM sourceFile
INITIALIZE_-PREPARSE IN_-STREAM
asts := [] -- accumulates parse trees
-- for all definitions in
-- sourceFile.
while ^(_*EOF_* or FILE_-CLOSED) repeat
BOOT_-LINE_-STACK := PREPARSE IN_-STREAM
LINE := CDAR BOOT_-LINE_-STACK
PARSE_-NewExpr()
pt := POP_-STACK_-1() -- get the parse tree
pf := postTransform pt -- turn it into a parse form
ast := parseTransform pf -- finally into an AST
asts := cons([pf, ast], asts)
IOCLEAR(IN_-STREAM, OUT_-STREAM)
SHUT IN_-STREAM
IN_-STREAM := savedInStream
$InteractiveMode := savedInteractiveMode
-- we accumulated the parse trees in reverse order
-- of declarations.
reverse asts
Pair(T) ==> Record(first: T, second: T)
AST ==> SExpression
)abbrev package SPADPRSR SpadParser
++ This package provides a simple minded interface to the SPAD parser.
++ Over time, we will add belts and whistles.
SpadParser(): Public == Private where
Public == with
parse: String -> List AST ++ parse(f) parses the source file f
++ and returns the result as a list of
++ pair of ASTs. The first component
++ of a pair is a parse form, and
++ the second compoenent is the internal AST.
++ Each pair on the list represents a
++ toplevel definition.
Private == add
spadReaderInitialized : Boolean := false
-- guards against multiple parser
-- definitions.
parse(source: String) : List AST ==
if not spadReaderInitialized then
LOAD("gdr-reader.clisp")$Lisp
spadReaderInitialized := true
ast : List SExpression := gdrParseSpadFile(source)$Lisp
ast
_______________________________________________
Axiom-developer mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/axiom-developer
