Krystian Baclawski wrote:
>
> On Sat, Mar 8, 2014 at 5:04 PM, Waldek Hebisch <[email protected]>wr=
> ote:
> >
> > 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?
Yes, no list comprehensions in this subset. Note that we
can still express recursive 'map'...
> 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?
In core+functors arguments to functors will be limited to types
(and limited as above). In practical subset we should aim
at non-type values as functor arguments and more general types.
> 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.
In my experience data structures and operations on them
are closely connected. You worked on converting Spad
parse tree to your form. But you will need more
operations and that will affect AST structure. You
may decide that you want completely different data
structure -- it is possible that just after building
AST you will want convert it to different form.
That is why I think of working with simple subset: once
you have all operations you will know what you want
from AST.
--
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.
