Krystian Baclawski wrote:
>
> Here kicks in the motivation for the proposal... To finish my compiler I
> need more type information from SPAD compiler. It's nearly impossible
> (well... highly impractical) to achieve this with current implementation.
> The type checker does not need to know all types to assume that a piece of
> code will get compiled correctly. Moreover somewhere during code lowering
> the type information is simply thrown away. I managed to recover some of
> it, but not all. SPAD compiler is written in obscure and typeless language
> (BOOT - fuuuuuu!) built on top of Common Lisp. Fixing the compiler is too
> risky - the scope of changes is too difficult to predict, code is very
> fragile with many subtle bugs lurking to reappear. So...
>
> I'd like to write new type checker from scratch. Not only would it,
> eventually, enable me to continue my work with code generator, but will
> create opportunity to eliminate well known bugs, formalize the type system,
> produce nicer diagnostic messages (I bet no one here likes reading
> s-expressions from the parser!), make some type annotations unnecessary,
> introduce new language tools (catch up with Aldor?). In fact I've already
> begun the work. I'm still learning SPAD and currently I'm trying to build
> some basic tools that I'll use to implement new type checker.
> https://github.com/cahirwpz/phd/blob/master/stypechk.spad
>
> The plan is to enter GSoC with all necessary tools ready to be used,
> including:
> a) abstract syntax tree representation,
> b) generic AST walkers,
> c) interface to global database of function signatures (daase)
> d) compilation context / environment representation,
> e) interface to call current compiler,
> f) pretty printers,
> g) ... and some simple tree rewriting examples (that will end up being a
> part of new type checker).
> Note that new type checker will be implemented exclusively in SPAD!
>
> Phase no.1: 19th of May till 27th of June. Within 5 weeks I can manage to
> build an unoptimized bottom-up type checker that will support most of
> non-problematic language constructs. Without talking to Waldek I cannot
> tell what's exactly going to be skipped.
It is better to say what will be supported. I see this as
follows. First core of Spad language:
- types with parameters beeing types, starting from
(uninterpreted) named types. Plus mapping types.
- simple assignment, basic flow control (sequence, if),
function application
- '@', '::' and '$' qualification
Next core+functors, that is core constructs plus ability
to define new constructors (only at this level w can handle
some complete piece of Spad code). And import statement.
Note that above I excluded records and unions (and iteration,
lambdas etc).
Next level is conditional types: conditions (boolean expression
build from 'is' and 'has') in declarations and in implementation.
Next is time to get a bit more practical: support Records, Unions
and 'case'. Add lambda ('+->') and nested functions and iteration.
I would say that for phase 1 core+functors is minimal acceptable
result, however it is better to aim at all above.
Looking at your code I have impression that you focus too much
on details in non-core parts of Spad. I am affraid that once
you start working on typechecker proper you will need to
change a lot of support code. And more support code
written before working on core part means more code to
adjust. Also, it seems that you want to do almost all
of supporting functions in your code. If yes you will
be on extremally tight schedule. Going into details:
for typechecking we need lists of operations and conditions.
Old compiler gets lists of operations executing types
(which in turn uses 'mkCategory' and 'Join'). You
can get base list of operations using GETDATABASE. But
this does not work for current type (it is not yet in
database) and you have still problem of substituting parameters.
If you want to do all just using GETDATABASE you will get
substantial piece of code. OTOH to reuse functions from
existing compiler you need to have data in compatible
format, but your data structures are quite different
so you will spent effort on convertions.
So, I suggest to concentacte on core Spad and reuse
of existing compiler functions. Only later expand
language and start replacing old functions by new
ones. That probably would mean different timeline,
possible getting working core before GSOC and
expanding it to workable subset during GSOC.
> That's my idea so far. I'll meet Waldek next week to polish it up before I
> formally apply for GSoC. Any questions / ideas ?
We should keep project discussion on the list.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
