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
threads.
- 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
https://groups.google.com/d/msgid/ats-lang-users/06909163-6217-437e-b92c-bdaa7c96cf64%40googlegroups.com.
