"Antoine Hersen" <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
