> I thought about this issue as well. One idea I had is to > use overloading aggressively. >
A thought I had recently -- I'm almost wondering if certain proofs (eg, linear proofs) could behave more like value constraints. That is, they could be invoked optionally, and would only be checked when specified. For example, if a variable invoked with type "b" is linear, it could be passed to either function "fun foo ( linear(l) | b l )" or "fn foo ( b )" without error. I suppose it would also be interesting if general proofs could be specified in type declarations -- again, analogously to value constraints. I suppose this suggestion would almost imply a "dataprop table" associated with every val / var invoked, which may or may not be feasible.... Speaking of constraints, one thing ATS2 doesn't have are "implementation constraints" -- that is, something like typeclasses or traits. I see how specific templates capture 85-90% of the functionality, and honestly I don't often miss the former. Still, such constructs are useful for documenting certain dependencies within code (they tell a developer "Hey, for this to work for your type, go implement that template" ). This type of thing introduces a structured overloading that might reduce the number of tokens in the code a fair bit, too. Right now the biggest issue with ATS2, as I see is, is that a non-expert > user gets tripped everywhere. For such a user, programming in ATS can > hardly > be an enjoyable experience. ATS3 tries to put joy back into learning > functional > programming via ATS. > I found the conceptual core of ATS2 pretty easy to grasp, given the examples and the *Introduction to ATS. *The difficult part was finding the meaning of certain tokens in source code, or even discovering that a certain feature exists in the first place. Also, I suppose I'm about as efficient at ATS2 as I am with C -- it can be difficult to justify using ATS instead of C (especially when I have to write FFI to C anyway, though c2ats has proven quite useful). I think ATS2 with relatively minor usability enhancements would tip my preference more strongly in its favor -- better error messages, some information hiding (I guess, syntactic sugar) and perhaps H/M inference alone could go a long way. -- You received this message because you are subscribed to the Google Groups "ats-lang-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-users+unsubscr...@googlegroups.com. To post to this group, send email to ats-lang-users@googlegroups.com. Visit this group at https://groups.google.com/group/ats-lang-users. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/282bc6ea-ebe5-4e86-9b64-1f7db11c7b45%40googlegroups.com.
