On Sat, Mar 8, 2014 at 5:04 PM, Waldek Hebisch <[email protected]>wrote:
>
> 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 we can handle
> some complete piece of Spad code). And import statement.
>
> Note that above I excluded records and unions (and iteration,
> lambdas etc).
>
When you say "iterations" you basically mean all looping constructs
including list comprehensions?
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.
>
Sounds ok. Should we also limit type of arguments passed to functors?
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 far we didn't have a systematic plan to attack the problem - I started
developing the support code focusing on generalized AST representation. If
that is not desired we can amend the plan and move efforts elsewhere.
Nonetheless I've learned quite a lot about SPAD programming techniques and
compiler quirks - that's also valuable.
Going forth and back between my generalized representation and s-expression
shouldn't be a big deal. Of course, unless s-expressions used by the
compiler evolve during compilation phases and I need to know all of the
variants.
> 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.
I completely agree that reuse of current compiler is crucial for rapid
development of (partially) working type checker. I need to learn which
components are reusable and how to interface with them. That is going to be
a part of pre-GSoC period.
We should keep project discussion on the list.
>
Ok.
--
Kind regards
Krystian Bacławski
--
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.
