axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Re: SPAD and Aldor again


From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Re: SPAD and Aldor again
Date: 21 Nov 2006 14:50:01 +0100

"Antoine Hersen" <address@hidden> writes:

[...]

| 
| I would like SPAD' to have a more functional flavor to it( personal taste)
| 
| Good news with depend type no need for polymorphisms or GADT !!!

I believe there is place for both.

| Algebraic type will be great !!! but I guess we will also need pattern
| matching to make good use of them.

Algebraic types without pattern matching is close to useless.  Boot
(src/boot) has a primitive support for algebraic types and pattern
matching. Its "case expression" is what you would expect.  I've been trying
to figure out a way to get it work in SPAD without breaking the
current syntax and semantics of SPAD.  It it pity SPAD's case
expression was designed that way.

| Also some type inference( I dont mean auto coercion) will be helpful.

That one is tricky in presence of auto coercion.  I suspect that we
will be stuck with a mixture of type inference and type checking
(bidirectional typechecking a la Turner--Pierce).  I don't think that
is a bad thing.  Type systems based on Hindley-Milner inference have
evolved to a mixture anyway.

| For the monoid problem I guess we need something like chapter 6 of
| Nicolas Doye PhD thesis.
| 
| Also should coercion have a special semantic ?
| 
| What to do about Rep ? I dont like it at all, why cant I have
| arbitrary number of instance variables named like I want.

We must have something to say that "here is the representation of a
domain".  There must be a way to impose a view on an existing object.
And Rep does that does job very well.  It is something I misses in
other languages.  The development of "concepts" for C++ has uncovered
that too. 

| I am personally worried about the current :
| (that is broken in Aldor and required the horrible "pretend" aka cast)
| 
| "if xValue has someSubtype then
|       ADT signature extention"

I too dislike this.  But I don't have (yet) a better solution.

The abstract idea being expressed is an important one.  What we need
is a better and *modular* (I don't mean module system) to express it.

| Can we do that in the SML module system with functors ? I should know this :(
| ( I think I have read that with dependent type we get SML module for free )

I don't see how SML module system solves this problem. 

| Also we have it as control flow in function definition.
| "if xValue has someSubtype then"
| 
| what about :
| 
| "if someType has someSubType then" ?
| 
| What are the valuable lesson from SML module system, Haskell type
| class, and C++ template  we can use ?

People are still working on finding better expressive ways with type
classes (predicate over types).  And there are very interesting
problems there.  My impression is that Scratchpad invented a form of
"type classes" before type classes where invented.  And this dates
back to the 70's-80's.  

Over the years people, people have found creative ways to convincing
the C++ template systems to do things it wasn't designed directly to
do. For example, people now use what is called "enable_if" to select
functions templates based on predicates. "Concepts" for C++ will
subsume that creative use of templates.

I think SPAD has to find its solution by introspection.

[...]

| On a practical point of view.
| For me the highest importance will be good error messages during
| compilation and possibility of debugging after.
| I remember to be quite frighten by SPAD error messages, this being the
| reason I switched to Aldor.

My students describe SPAD diagnostics as "spectacularly obscure"
messages.

[...]

| Also I feel that depend type will ask a lot from the runtime system to
| do some late type checking.

Yes.

[...]

| I guess language design is quite difficult and it is important to know
| what kind of problems we need to solve.

Definitely.  That is why I'm of the opinion of first nailing down what
we want, i.e. look at existing SPAD codes and see how they can be
improved, how they can be expressed better, what kind of things cannot
be expressed adequately in current SPAD.  I'm not convinced by
feature accretion from other languages.

-- Gaby




reply via email to

[Prev in Thread] Current Thread [Next in Thread]