I have accrued a bit of a wishlist while working with ATS.   Maybe some of 
it is useful or feasible.

Things I would keep the same:

   - I think dependent type / proof syntax is well done, and it feels a bit 
   more natural than Idris.  I'd keep this the same
   - The '~' to free an unfolded view type is a good choice. 
   - I'm also fond of '@' for unboxed types.
   - I like the degree to which it resembles SML. 
   - I like the various language backends.  The JS backend is especially 
   important, I think
I really like Idris and Haskell, though maybe SML-like syntax offers more 
flexibility (eg, defining different types of functions).  For 
resource-awareness, distinguishing between C-like lambdas and closures is 
excellent.  Then again, I don't miss the "fun" while working with Haskell 
or Idris. 

One good thing about Idris is that it's somewhat easy to target native / 
JS, and unofficially, the JVM.  A bit odd that the JS backend can be faster 
than the native at times.

Haskell is horrendous to cross-compile, and GHCJS program sizes are 
massive.  I love it for basic native compilation, though.

I think ATS could have a slight edge in the sense of portability -- the JS 
it outputs is tiny and it's dead-simple to cross-compile.   That said, I 
can't integrate the JS very easily into a standard JS toolchain, since it 
doesn't output modules.

Here are syntactic things I think ATS would benefit from:

   - Active whitespace would be a great alternative to "end", and might add 
   some elegance
   - Templates need to be better distinguished from dependent types.
   - As mentioned already, I dislike the '@' signs in types (eg, t@ype).  
   Aliasing also becomes very confusing (it took me a while to figure out what 
   t0p meant, or t0ype for that matter)
   - I found numeric suffixes similarly problematic -- clo1, for instance.  
   The number gives no indication about what the name may mean. 
   - List literals would be awesome in some capacity (eg, ["this", "is", 
   "a", "list"]).  I guess it may be hard to distinguish between types of 
   lists, but I do think $list / $list_v is a bit too verbose.
   - $FOO reads like a shell variable.  Nixing the dollar sign next to 
   modules may be a good choice.
   - I think C might be best banished to .cats files.  Or, maybe the inline 
   code blocks could be assigned a language (eg, %C{  ... %})
   - Multiline strings are useful in any language.
Technical things I think ATS could use:

   - Some lightweight concurrency primitives would be great -- nothing that 
   would require a runtime, but maybe something to schedule things like green 
   - Clearer error messages, ideally aware of the C compilation phase.  C 
   errors can be confusing when....I'm not working in C.
   - Odds and ends -- a build / package manager might be useful. 
   - Lazy "val" might be nice -- like Haskell's "let". 
   - The JS backend is great, but it would help to output modules. ES6 
   would be a fine choice for this, I think.  Node will catch up eventually, 
   and in the meantime, there are tools like Rollup, etc.
   - Possibly, row types?

One thing I liked about ATS is that I could port the same library to 
multiple language targets simply by swapping out .hats and .cats files. I 
had attempted to build a web framework / HTML DSL on this principle (though 
time isn't on my side).  I felt that some of my Makefile trickery could be 
better managed by a smart build tool, that knows the library and the 
language targets (C for the server and JS for the client), for example.  I 
don't think it needs to be particularly complex, but there would need to be 
some conventions for directory structure and organization of .cats files in 
different languages.

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 

Reply via email to