ATS3: ATS/Xanadu

2026 views
Skip to first unread message

gmhwxi

unread,
Feb 9, 2018, 1:15:22 PM2/9/18
to ats-lang-users
For the moment, I just want to open a thread for ATS3.

I decided to pick ATS/Xanadu for the full project name. I like the name Xanadu
because it is poetic and brings a feel of exoticness.

ATS3 is supposed to be compiled to ATS2. At least at the beginning. I will try to
write more about what I have in mind regarding ATS3.

I know that a lot of people have been complaining about the syntax of ATS2. So
we can start the effort of designing some "nice" syntax for ATS3. Please feel free
to post here if you would like share your opinions and ideas.

I will be happy to take the lead but we definitely need to have some form of community
effort on this project given its size and scope.

Cheers!

--Hongwei

PS: I felt rushed every time up to now when implementing ATS. This time I am hoping
to have the luxury of thinking about implementation a bit before actually doing it :)

gmhwxi

unread,
Feb 9, 2018, 4:44:41 PM2/9/18
to ats-lang-users
Of course, if you feel that it is more appropriate to have a private
discussion, please feel free to send your messages to me directly.

Martin DeMello

unread,
Feb 9, 2018, 4:57:11 PM2/9/18
to ats-lan...@googlegroups.com
I would love to see t@ype and similar keywords with symbols in the middle replaced by something more pronounceable - the lack of quick mental pronunciation is a surprisingly large annoyance when reading and wirting code.

martin

--
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+unsubscribe@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/8d547585-a0ce-494e-8568-a0657274deb0%40googlegroups.com.

Hongwei Xi

unread,
Feb 9, 2018, 5:03:33 PM2/9/18
to ats-lan...@googlegroups.com
This one is already on my mind. Learned my lessons :)

The plan is to use 'abstype' in place of abst@ype.

On Fri, Feb 9, 2018 at 4:57 PM, Martin DeMello <martin...@gmail.com> wrote:
I would love to see t@ype and similar keywords with symbols in the middle replaced by something more pronounceable - the lack of quick mental pronunciation is a surprisingly large annoyance when reading and wirting code.

martin
On Fri, Feb 9, 2018 at 10:15 AM, gmhwxi <gmh...@gmail.com> wrote:
For the moment, I just want to open a thread for ATS3.

I decided to pick ATS/Xanadu for the full project name. I like the name Xanadu
because it is poetic and brings a feel of exoticness.

ATS3 is supposed to be compiled to ATS2. At least at the beginning. I will try to
write more about what I have in mind regarding ATS3.

I know that a lot of people have been complaining about the syntax of ATS2. So
we can start the effort of designing some "nice" syntax for ATS3. Please feel free
to post here if you would like share your opinions and ideas.

I will be happy to take the lead but we definitely need to have some form of community
effort on this project given its size and scope.

Cheers!

--Hongwei

PS: I felt rushed every time up to now when implementing ATS. This time I am hoping
to have the luxury of thinking about implementation a bit before actually doing it :)

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.

--
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+unsubscribe@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.

Julian Fondren

unread,
Feb 9, 2018, 5:08:13 PM2/9/18
to ats-lang-users
Aye, like in https://www.youtube.com/watch?v=zt0OQb1DBko where it's twice emphasized that "there are no typos here--this is what ATS looks like". Those are the most off-putting.

I would also prefer a more OCaml-like "let val x=1 in (expression)" to the existing "let val x=1 in (expression) (expression) ... end". Which would be better in ATS than in OCaml since 'let' isn't otherwise used. Mainly because there's less to indent:

let cube_round (x, y, z) =
  let round r = floor (r +. 0.5) in
  let rx, ry, rz = round x, round y, round z in
  let xd, yd, zd = abs_float (rx -. x), abs_float (ry -. y), abs_float (rz -. z) in
  (* ^-- no indentation changes --v *)
  if xd > yd && xd > zd then
    (-. (ry -. rz), ry, rz)
  else if yd > zd then
    (rx, (-. (ry -. rz)), rz)
  else
    (rx, ry, (-. (rx -. ry)))

OTOH, OCaml is not famously regarded as good-looking. On the contrary Facebook gave it a purely syntatic makeover in ReasonML and people seem to really like that.

Other than those two I don't have many complaints. Maybe it could be emphasized more (in documentation) that there's flexibility to do things different ways. You can use (a; b; ignoreat(c); d) instead of a bunch of val () =. You can write

datatype rps_move = rock | paper | scissors  // without the parens

, etc.

On Friday, February 9, 2018 at 3:57:11 PM UTC-6, Martin DeMello wrote:
I would love to see t@ype and similar keywords with symbols in the middle replaced by something more pronounceable - the lack of quick mental pronunciation is a surprisingly large annoyance when reading and wirting code.

martin
On Fri, Feb 9, 2018 at 10:15 AM, gmhwxi <gmh...@gmail.com> wrote:
For the moment, I just want to open a thread for ATS3.

I decided to pick ATS/Xanadu for the full project name. I like the name Xanadu
because it is poetic and brings a feel of exoticness.

ATS3 is supposed to be compiled to ATS2. At least at the beginning. I will try to
write more about what I have in mind regarding ATS3.

I know that a lot of people have been complaining about the syntax of ATS2. So
we can start the effort of designing some "nice" syntax for ATS3. Please feel free
to post here if you would like share your opinions and ideas.

I will be happy to take the lead but we definitely need to have some form of community
effort on this project given its size and scope.

Cheers!

--Hongwei

PS: I felt rushed every time up to now when implementing ATS. This time I am hoping
to have the luxury of thinking about implementation a bit before actually doing it :)

--
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-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.

Julian Fondren

unread,
Feb 9, 2018, 5:44:40 PM2/9/18
to ats-lang-users
ah. also:

val ex1 = (arrayref)$arrpsz{arrayref(int, 4)}(a, b, c) where {
  val a = (arrayref)$arrpsz{int}(5, 1, 9, 5)
  val b = (arrayref)$arrpsz{int}(7, 5, 3, 0)
  val c = (arrayref)$arrpsz{int}(2, 4, 6, 8)
}

is there a nicer way to include a matrix in an ATS2 program than this?

One might prefer to define the table in the target language, even C:

%{
int ex1[3][4] = {{5, 1, 9, 5},
                 {7, 5, 3, 0},
                 {2, 4, 6, 8}};
%}
val ex1 = $extval(arrayref(arrayref(int, 4), 3), "ex1")


Going as far as having a nice literal syntax for hash tables would fit the expectations of a Ruby/JS/&c hacker.

Julian Fondren

unread,
Feb 9, 2018, 5:59:50 PM2/9/18
to ats-lang-users
(Although this is wrong, and causes a segfault.)

Hongwei Xi

unread,
Feb 9, 2018, 6:29:48 PM2/9/18
to ats-lan...@googlegroups.com
This works:

%{
int
ex1[3][4] =
{
{5, 1, 9, 5}
,
{7, 5, 3, 0}
,
{2, 4, 6, 8}
};
%}
val ex1 =
$extval(matrixref(int, 3, 4), "ex1")


--
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+unsubscribe@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.

vamc...@gmail.com

unread,
Feb 11, 2018, 8:34:48 PM2/11/18
to ats-lang-users
I don't have any concrete suggestions, but I would suggest Idris as an example to follow. Haskell syntax is relatively popular and concise, and Idris' is even more refined.

I will say I'd prefer syntax that eases functional programming, but that might just be me. And I think that replacing -<lincloptr1> with something more concise like -o would be a good decision either way.


On Friday, February 9, 2018 at 12:15:22 PM UTC-6, gmhwxi wrote:

gmhwxi

unread,
Feb 12, 2018, 1:59:54 PM2/12/18
to ats-lang-users
Thanks.

Haskell and Idris are definitely on my radar.

Type inference in ATS is very week (largely due to the support
for dependent types and linear types). To support concise syntax,
type inference in ATS needs to greatly strengthened.

August Alm

unread,
Feb 13, 2018, 9:43:04 AM2/13/18
to ats-lang-users
I second the preference for Haskell-style "let" and "where", which is to say no "end"s and no curly braces.
Of course, this requires indentation to be syntactic and not just a matter of aesthetics/readability. I think this
is a good thing, not just because it is more concise but maybe even more so because it enforces readability
(non-indented code will not compile) and stylistic uniformity in the community.

As a side-note, Haskell allows curly braces and semi-colons as an optional form of writing.
One may write "foo f = let {x=a; y=b; ...} in ...", etc. Useful for one-liners or for people who want their code
to look like more C-ish.

Artyom Shalkhakov

unread,
Feb 13, 2018, 10:56:52 AM2/13/18
to ats-lang-users
If we talk syntax, why not adopt that of C? :-)

13 февр. 2018 г. 8:43 ПП пользователь "August Alm" <augu...@gmail.com> написал:

--
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+unsubscribe@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.

August Alm

unread,
Feb 13, 2018, 12:11:28 PM2/13/18
to ats-lang-users
Fine by me! As long as the syntax encourages a uniform and readable coding style. Also, I think it would help ATS
if it looked more (seemingly) familiar to a more widely known language. For example, at the moment we have the
abbreviated syntax " = {...}" for "= () where {...}", which allows us to write function bodies of void-functions in a style
that looks C-ish, but there is no nice way, I think, to write functions with a non-void return type in the same way.

Maybe Scala offers a good solution? Functions in Scala have the default form:

def functionName ([list of parameters]) : [return type] = {
   function body
   return [expr]
}

A different way is, e.g.,

val add1: Int => Int = (i) => i + 1

My point is that it is always allowed to put curly braces on the body (same goes with
if-statements, etc.) so that it is possible to write consistently in a C-ish style.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.

gmhwxi

unread,
Feb 13, 2018, 1:55:32 PM2/13/18
to ats-lang-users
Let's experiment.

My rough plan for now is to have something largely based
on the current syntax of ATS2 (modulo some minor fixes) as
the "ground" syntax. This syntax is going to be explicit and
verbose. There will be an interface for it (e.g., via JSON).

Then we can embrace a "pan-syntax" design. For instance,
Hakell-like syntax can be supported as long as it can be translated
to the ground syntax.

I think that Python-like syntax is a good idea, too. The seemingly
simple idea of using indentation to structure code can go a long way.
It is brilliant!

August Alm

unread,
Feb 13, 2018, 2:24:08 PM2/13/18
to ats-lang-users
I realize it may have sounded as if I like the feature of being able to write the same thing in a multitude of ways. I don't. It's something both Scala and ATS have in common and that I think it's problematic. In both Haskell and C the are many ways of doing things, but not many ways/styles of writing.

Steinway Wu

unread,
Feb 13, 2018, 2:52:29 PM2/13/18
to ats-lang-users
Hi Hongwei, just for the record, let me put down some offline discussions. 

1. Programmers can decide how a literal is parsed, or even write some plugins to parse some custom literals. For instance, 1 can be interpreted as int, nat, and int(1) etc. Programmers should be able to either turn a knob, or annotate the literal, to switch among interpretations. 
2. Some meta-programming supports via templates. E.g. `derive` of Haskell. 
3. Formalization of templates.
4. Module systems. 
5. Session types :)
6. Modular design of the whole tool chain. E.g. parsing, type equality, constraints solving, template dispatch, type erasure, etc. 
7. Maybe database-based compilations? We can store compiled blocks as a (hash, binary IR) pairs in some file-based databases, for easy reuse. Not sure how feasible it is. 
8. Interpreter, REPL, language servers, documentation tools, standard libraries, type inference, etc. 
9. More importantly, a process for open source contribution. 

Exciting!

On Friday, February 9, 2018 at 1:15:22 PM UTC-5, gmhwxi wrote:

gmhwxi

unread,
Feb 13, 2018, 8:39:34 PM2/13/18
to ats-lang-users

It is not that I like pan-syntax. What I really like is syntax-independence,
but we are still very far from it :)

When facing uncertainties, I would say that one's natural reaction is to keep
the options open.

gmhwxi

unread,
Feb 13, 2018, 9:41:14 PM2/13/18
to ats-lang-users

Thanks for writing it down.

Hopefully, this does not end up a merely pipe dream :)

I would also put 'type inference' high up there. Some variant
of Hindley-Milner type inference should be a crucial part of ATS3.

August Alm

unread,
Feb 18, 2018, 3:13:37 PM2/18/18
to ats-lang-users
I have something to add to the wishlist: "better" linear functions.

We had a discussion about this almost a year ago. The issue I raised back then is that
there is no real way to free a linear function without applying it. This is not a concern
motivated by category theory or something such, but a practical concern. Not being
able to free functions without applying them simply makes it unnecessary difficult to
write code. For example, writing code that depends on runtime data of the form

"if data is ... then apply linear function foo and free bar
else apply linear function bar and free foo"
 
becomes a no-no.

Hongwei came up with two alternatives to (lin)cloptr. First:

datavtype
hom(a: vt0p, b:vt0p+) =
  {env: vtype}
  HOM(a, b) of
    (env, env -> void, (env, a) -> b)

Secondly:

datavtype
hom(a: vt0p, b: vt0p+) =
  hom(a, b) of
    {i: bool} option_vt(a, i) -<lincloptr1> option_vt(b, i)

The first solution requires all linear functions to have a
"free method" [env -> void]. The secondly sidesteps the
problem by giving all linear functions a [None_vt()] on
which we can evaluate them in order to free them.

Both alternatives work, but there is no syntactic sugar and no
library support. (Also, wrapping things in datavtype of datavtype
will, I guess, affect performance, but ought to be possible for the
compiler to optimize.)

Best wishes,
August

M88

unread,
Feb 20, 2018, 12:06:16 AM2/20/18
to ats-lang-users
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.


Artyom Shalkhakov

unread,
Feb 20, 2018, 10:19:31 AM2/20/18
to ats-lang-users
On Saturday, February 10, 2018 at 12:15:22 AM UTC+6, gmhwxi wrote:
For the moment, I just want to open a thread for ATS3.

I decided to pick ATS/Xanadu for the full project name. I like the name Xanadu
because it is poetic and brings a feel of exoticness.
 
ATS3 is supposed to be compiled to ATS2. At least at the beginning. I will try to
write more about what I have in mind regarding ATS3.

I know that a lot of people have been complaining about the syntax of ATS2. So
we can start the effort of designing some "nice" syntax for ATS3. Please feel free
to post here if you would like share your opinions and ideas.


I will say what I would like to see:

1. IDE support (especially for the hard parts, i.e. the proofs!)
2. the syntax is very complex (maybe simplify?)
3. better support for flat types (e.g. flat unions, flat unboxed arrays on stack, etc.)
4. compilation to wasm
5. tools (especially for building, but also package management)
6. some kind of help for implementing various intricately-linked data structures (doubly-linked lists, doubly-linked trees, etc.)
7. improvements to templates (e.g. templates for indexed type variables, is that even possible?)
 
To make ATS viable, we have to make its kind of typeful programming friendly.

aditya siram

unread,
Feb 20, 2018, 2:00:48 PM2/20/18
to ats-lang-users
Many here have mentioned syntax as a point of improvement. While I agree, I have no opinions on which variant (ML vs. C vs. Lisp) is more aesthetically appealing. Some things I look for are unambiguous indentation, easy for a machine to format and easy to parse. I think syntax should be designed to be amenable to making an IDE and other source code tooling rather than trying to meet some subjective definition of readability which is only really relevant in the small. As an example, while pretty, the (whitespace significant) version of Haskell syntax is difficult and demoralizing to write tooling for.

I will also say that ATS is currently so little used that now's the time to make pretty big changes, even slashing features ( eg. macros ).

vamc...@gmail.com

unread,
Feb 26, 2018, 9:03:43 AM2/26/18
to ats-lang-users
In reference to the quoted, I will note that I have written a package for dealing with ATS syntax in Haskell. The pretty-printer works marvelously, but getting the parser right is HARD. The package already has around 1400 lines of code for the lexer/parser and it's STILL buggy. I suspect a good part of that is be due to me not understanding things correctly, but in general I think a simpler syntax would serve ATS much better. There are a lot of things I want to be able to do with Haskell/ATS and I suspect the wider community will appreciate it for exactly the reasons mentioned by others :)

Brandon Barker

unread,
Mar 7, 2018, 11:52:49 AM3/7/18
to ats-lang-users
Glad to see this thread is here. I will just share some general thoughts for syntax as my ATS is a bit rusty:

1. I like Scala style syntax - I think it is easy enough to read, unless maybe you are doing stuff at the type level, where ATS seems to have an advantage over Scala. I think Scala is similar to python in a lot of ways (especially with Python 3.6 typing styles), aside from making indentation part of the syntax. My thought is that Python doing this helps to force people to write somewhat readable code (think beginner Python vs beginner Perl), but I think we can assume that if you are coding in ATS, or at least publishing code in ATS, you will be sensible enough to have some kind of good programming style. So I would vote for leaving indentation to a style checker/linter.
2. Concision: I sadly don't know Idris or Haskell, and am very tempted to learn one of them to get a better appreciation of them, but I'd rather focus on ATS again. However, I do appreciate that they are concise, even more so than Scala, which is generally laudable. 
3. Feature hiding: Facilitate the principle of least power. ATS has a lot of advanced features, as does Scala (of course ATS has more). Scala is pretty good at letting you hide them. I swear, I'd been coding in Scala for 3 years and was still amazed at how simple you could make the code if you try - just take a look at http://www.kogics.net/kojo - it is nearly as easy as python I would say, and preferable to me. The lack of types in the coding examples is almost annoying to me, but I understand it is beneficial to young readers. Now, I'm not saying we can do all this in ATS, but Scala is so named because it is a "language that scales with you", and I believe ATS is this too, but it would be good to make that scaling a bit more smooth, like climbing a Olympus Mons rather than K2.


Other goals:
 - Build systems: I think cross builds are very important as already stated. In scala land, there is Scala (JVM), scala.js, and now scala-native. Usually, we can create cross builds by having some source that is platform independent (e.g. APIs/interfaces/types) and other bits that are platform specific and rely on the platform independent bits. This is great. Related to this, I actually think it may be worthwhile looking into an existing build tool with a larger community rather than using make and autotools, which seem to me a bit antiquated and unfriendly to other platforms. I recall Hongwei and I were both a bit jaded by our experience with using gradle, so I'm both excited to say Mill looks like a promising alternative, though I'm also hesitant to make a suggestion after the last failure with Gradle :-) But I believe a lot in Mill's stated goals, especially insofar as they overlap with CBT's and the idea of being designed to support multiple languages. If we can agree that Scala isn't terrible, I say let's not reinvent the wheel, and try to comingle a bit with them. This could be beneficial for both communities. Let's think about using their build tools. At the moment, Mill seems to be creating a lot of excitement, so it might be worth looking into it first.

I'll try to give more concrete feedback in the future.


On Friday, February 9, 2018 at 1:15:22 PM UTC-5, gmhwxi wrote:

Brandon Barker

unread,
Mar 7, 2018, 12:01:03 PM3/7/18
to ats-lang-users
I forgot to mention, I like the idea of adding a level of indirection in the syntax for ATS3. Hopefully this could allow something like scalafix to be developed, which would not only allow code migration from ATS2 to ATS3, but also ease future code migration within ATS3.
to be applied to existing sources

Brandon Barker

unread,
Mar 9, 2018, 3:29:18 PM3/9/18
to ats-lang-users
Another Scala feature worth looking into: implicit parameters, values, and function types. Dotty has added implicit function types, and I'm not very familiar with all their benefits as yet: https://www.scala-lang.org/blog/2016/12/07/implicit-function-types.html 
However, implicit parameters alone have been great for me, and could probably go a long way towards reducing some verbosity in ATS. They can also be used in clever ways to create contradictions at compile time, by bringing into scope two implicit values of the same type. I'm not sure if ATS would benefit from that feature, but Scala's type system doesn't allow for things like type b = not a. You can achieve that with implicits: https://gist.github.com/milessabin/c9f8befa932d98dcc7a4

gmhwxi

unread,
Mar 10, 2018, 7:09:50 AM3/10/18
to ats-lang-users

The way in which Scala evolves reminds me of C++: Powerful features
increase productivity but also make it harder and harder to reason about
code.

Brandon Barker

unread,
Mar 10, 2018, 7:33:04 AM3/10/18
to ats-lang-users
Implicit parameters get a bit of a bad reputation, but I don't recall ever being burned by them in any way even though I use them almost all of the time; if you have things like implicit strings or even implicit Map[String, something], that is obviously not good programming style, since it is relatively easy to add a new implicit in scope (but then you'd get a compile error anyway as you can't have more than one implicit of the same type in scope) - they usually need to be rather specific types related to configuration to make sense.  Granted, I have not used them much in the contradictory fashion that I linked above from Miles Sabin - that is a rather unusual Scala style, but he hides a lot of that in his Shapeless library so you can use the features without being directly exposed to (most of) the unpleasantries.

I get the sense that dotty isn't adding too many "bells and whistles" features, and even removing the ones that relate to unsoundness, and making other features less suprising, like making the extension order no longer matter: A extends B with C will be the same as A extends C with B now. And they are adding sensible union types. I believe they are improving dependent typing in dotty as well. They are removing XML literals, which I'm actually somewhat sad about, but adding in XML string interpolation.  I've heard there is 0 chance of getting linear types though. Which is why ATS is really in a good place in terms of features. It has a lot of nice functional things like Scala (even better: ATS has mutual TCO), has better linear types than Rust, and has a proof system, neither of which Rust or Scala has. 

I don't meant to overly sell Scala here; I just think it has some nice things, and I've been using it a lot, so I wanted to list the things I thought were nice. Why I use it: as I and some others like to say, it is a language that gives you types like Java (but better) and concision like python, while basically giving you the same massive and easy-to-use (once you are used to it) JVM ecosystem that Java enjoys. So while it may not have a lot of advanced features compared to some more modern languages, it already seems to be quite an improvement over the most popular languages for many applications. Also I had a lot of JVM-related projects lately ;-).

--
You received this message because you are subscribed to a topic in the Google Groups "ats-lang-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ats-lang-users/mjS9NtQz6Pg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ats-lang-users+unsubscribe@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.

Brandon Barker

unread,
Mar 10, 2018, 9:11:42 AM3/10/18
to ats-lang-users
While jumping back into ATS, a few other minor things (lots of minor things add up) that might be nicer is string interpolation in the form of python 3.6 or Scala (both are very similar). Here's a copy paste example from python 3.6:

1. 
name = "Spongebob Squarepants"
print(f"Who lives in a Pineapple under the sea? {name}.")

Scala would look like:

print(s"Who lives in a Pineapple under the sea? $name.")

or if 'name' was a general scala expression instead of just an identifier:

print(s"Who lives in a Pineapple under the sea? ${name}.")

This could also be useful for supporting things like XML interpolation, etc, later on (not that it is a very high priority for most, I imagine ;-)).

I don't know how this might work in ATS yet, since scala relies on objects' toString methods, and Python objects have something similar (in both languages, everything is effectively extends object, which I believe has the toString method - by default, this is just the object's address, so not too interesting, but Int of course has a sensible override, as do many objects).


2. OK, maybe this isn't so minor generally. I was using extern in front of a fun in a dats file (I thought this was actually required, but eventually realized that my sleep-deprived brain had read about extern last night and forgot this was only for interfaces, not definitions). This was the error message:
 128(line=8, offs=38): error(parsing): [s0tring] is needed 
Lots of confusion here for a beginner. The user might have to figure out what s0tring is (I think it is either a non-dependent or non-linear string, can't recall and didn't check); also it implies something is needed when it is actually the absence of something that is needed in this particular case (the extern keyword).

3. Simplify ways of defining functions. There seem to be many: fn, fun, fnx. I'd prefer a longer but easier to remember 'tailrec' prefix keyword in some cases to make sure the function is tail recursive and tc-eliminated. Just throwing a quick idea out there, haven't thought about this much, and i'm sure that there are good reasons for why things are the way they are in ATS (I just don't recall all of them).


I think if ATS3 is to be done, better error messages should be on about the same priority as improved syntax. On this point, I will say that Scala error messages seem way better generally than Python thanks to typing: you are generally looking at stacktraces in Python, which lack types as well ;-).

Hongwei Xi

unread,
Mar 10, 2018, 10:00:31 AM3/10/18
to ats-lan...@googlegroups.com
Thanks.

These are all very good points.

I said many times here that I see ATS as both a source language and
a target language. ATS3 will make it a lot easier for people to use it as a
target language. I will first use a master design for the syntax of ATS3 largely based
on that of ATS2. And an interesting party can design his or her syntax that translates
into this master design. Stay tuned :)


To post to this group, send email to ats-lan...@googlegroups.com.



--
Brandon Barker
brandon...@gmail.com

--
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+unsubscribe@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.

Brandon Barker

unread,
Mar 10, 2018, 10:53:27 AM3/10/18
to ats-lang-users
I don't know if TASTY might be of help, either in ideas or actual implementation. Some more indepth discussion of TAST: https://github.com/twitter/reasonable-scala/issues/21


To unsubscribe from this group and all its topics, send an email to ats-lang-user...@googlegroups.com.

To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at https://groups.google.com/group/ats-lang-users.



--
Brandon Barker
brandon...@gmail.com

--
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-user...@googlegroups.com.

To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at https://groups.google.com/group/ats-lang-users.

Hongwei Xi

unread,
Mar 10, 2018, 11:00:11 AM3/10/18
to ats-lan...@googlegroups.com
Yes, kind of.

But the supposed selling point of compiling into ATS is that one is able
to take advantage of the advanced typechecking supported by ATS. Say,
you implement a DSL for programming cyptocurrencies; you may want to
compile the DSL into ATS so that you can statically verify certain invariants
in, say, smart contracts.

To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-users+unsubscribe@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.
Message has been deleted

Hongwei Xi

unread,
Mar 13, 2018, 4:36:23 PM3/13/18
to ats-lan...@googlegroups.com
This sounds more like an IDE issue to me.

On Tue, Mar 13, 2018 at 3:20 PM, Brandon Barker <brandon...@gmail.com> wrote:
Replying to the concise syntax issue in particular: I like concise syntax up to a point, but when it comes to types, explicit syntax is sometimes nice (though it would be great to allow the user to choose). Both to make compilation proceed quicker (possibly), and to make it more obvious what code is doing when you read it.

One area where working in ATS  actually seems to prevent this is when implementing a function specified elsewhere. Maybe this is just a user error from me, but I tried last night to implement main0(argc, argv): void after looking up the types in the ATS2 sources after grepping for a bit, and was able to do it up to a point: I could do something like implement main0(argc: int, argv): void. But then, I wasn't able to figure out how to get it further refined and add argc: int n in the implementation view. I guess this is code duplication to a certain extent, so I don't necessarily think it is a great style. On the other hand, it seems a bit inconvenient to have to go look in a sats file to see the specification for a function.

--
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+unsubscribe@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.

Brandon Barker

unread,
Mar 13, 2018, 4:54:25 PM3/13/18
to ats-lang-users
True, an IDE could zoom in on the definition, if it were supported by the IDE/plugin. 


To post to this group, send email to ats-lan...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "ats-lang-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ats-lang-users/mjS9NtQz6Pg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ats-lang-users+unsubscribe@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.

M88

unread,
Mar 14, 2018, 7:36:57 AM3/14/18
to ats-lang-users
Not sure if it's feasible or theoretically sound, but it would be nice to see a less stark divide between datatypes and dataviewtypes in ATS3. It would be great to be able to declare a data structure once and use either linear or gc'd versions.

Maybe this could extend to other types that have a dual linear version (eg strptr / string). It seems there are commonly functions that could operate on either, and at the moment this is achieved by casting. Perhaps there could be a type level attribute for all pointer-based types, like "lin string" / "gc string" , which are both also just "string".

This may also allow for specifying "linearity" in variable declarations, eg 'let lin val x=Foo(7), y="A linear string" in... '.

I suppose a similar syntax could make dealing with proof values more concise, too (eg, 'let prf val pa=my_proof_fn(), pb=another_proof_fn(pa) in... ').

gmhwxi

unread,
Mar 14, 2018, 9:33:28 AM3/14/18
to ats-lang-users

I thought about this issue as well. One idea I had is to
use overloading aggressively.

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.
Message has been deleted

Hongwei Xi

unread,
Mar 19, 2018, 9:31:59 AM3/19/18
to ats-lan...@googlegroups.com
Many thanks for your input!

>>perhaps H/M inference alone could go a long way.

That is really my bet :)

>>I suppose I'm about as efficient at ATS2 as I am with C

Yes, one can do C-style coding in ATS. With ATS, my hope is that one
is able to use more functional programming to solve problems that are normally
solved using C.

On Sun, Mar 18, 2018 at 12:16 PM, M88 <abys...@gmail.com> wrote:

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+unsubscribe@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.

Andrew Knapp

unread,
Mar 20, 2018, 5:34:06 PM3/20/18
to ats-lang-users
After writing several thousand lines of ATS, I'd say there isn't terribly much I'd change, honestly. A lot less than when I got started, for sure.

What I would like to see changed:

1. Real module system. MixML might not be a bad source of inspiration, as it would essentially be a better version of the ML "modules" you can fake with includes, e.g. funmap.hats, and there's an implementation available. Doing away with the sigil before module names would be nice.

2. Naming conventions in standard library changed. Less g0ofg1, i2r and so on would be nice. I also find the abbreviations you choose to be very difficult to read. With a real module system, it would be nice to have shorter function names: you could get away with Array.map or A.map instead of array_map. This way the user can choose how verbose to be about module names.

3. Integrating templates with the module system. BTW embeddable templates are my absolute favorite feature of ATS.

4. Accessing flat memory of sum types and some kind of analog of C++ placement new. This would make certain things a lot safer and easier.

5. Real macros or very powerful metaprogramming support. I know metaprogramming can be abused, but there are many things where I wish I had even a customizable version of #codegen2 that I could use. D is probably a good source of inspiration for this subject.

6. General cleanup of cruft and making sure features work together.

7. Pretty-printed error messages.

8. REPL, perhaps via atscc2scm and an embedded R7RS-small interpreter?

Anyways, I've found ATS to be a real pleasure to use overall, and I trust my code is correct a lot more than in C++.

Hongwei Xi

unread,
Mar 21, 2018, 9:39:04 AM3/21/18
to ats-lan...@googlegroups.com
These are all great points. Thanks!

My hope is that the community can and is willing to take a big part in
designing and implementing upper level programming features once the
core of ATS3 is ready.

Cheers!

--Hongwei

--
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+unsubscribe@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.

vamc...@gmail.com

unread,
Apr 9, 2018, 7:52:09 PM4/9/18
to ats-lang-users
I'm actually not a huge fan of Scala syntax, simply because I find it verbose and I believe that it is not suited to functional programming in general. If there are reasons to support methods and whatnot, then I would be more amenable to it.

As for build systems, I think that shake is probably good to have. I've learned a lot of lessons from language-ats, and I believe I could write a language-xanadu package that worked and stayed up-to-date with the actual compiler. This would (among other things) make builds much, much simpler. I am against any use Scala on technical grounds, and shake is much better established, having led to several published papers. I actually kind of like the versatility and portability of make/configure, but I should be able to maintain a shake-xanadu package as well to provide an alternate/simpler solution.

I'm also not really sure how string interpolation works in Scala. I know Rust does something at the macro level, so that may be an option - it would allow errors to be generated at compile-time.

On the ATS front: I am curious as to how ATS optimizes tail recursion. I know Scala doesn't actually optimize tail recursion (unless the values are of the same type) which is immensely limiting in practice. A lot of interesting stuff (e.g. monadic recursion) relies on such optimizations in practice.

Cheers
Vanessa M.

Hongwei Xi

unread,
Apr 10, 2018, 1:13:52 AM4/10/18
to ats-lan...@googlegroups.com
>>As for build systems, I think that shake is probably good to have ...

That would be great! I plan to export the syntax tree of an ATS program into JSON.

>>On the ATS front: I am curious as to how ATS optimizes tail recursion. I know Scala doesn't actually optimize tail recursion (unless the values are of the same type) which is immensely limiting in practice. A lot of interesting stuff (e.g. monadic recursion) relies on such optimizations in practice.

It is pretty straightforward. After typechecking, proofs are erased. Then the compiler marks each recursive call that happens to be a tail-call; each marked call is converted into a local jump.

--
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+unsubscribe@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.

M88

unread,
Apr 10, 2018, 8:46:02 PM4/10/18
to ats-lang-users
I suppose there has been a fair bit of talk about syntax already.   I had been thinking a whitespace-significant  label-block structure (a-la Nim) might suit the language well, and some recent code sample inspired me to demonstrate.

Original:
datasort tlist = tnil
| tcons of (t0ype, tlist)

extern fun {t:tlist} foo(): void
extern fun {a:t0ype} foo$fopr(): void

implement foo
<tnil>() = ()
implement
(a,ts) foo<tcons(a,ts)>() = {
  val
() = foo$fopr<a>()
  val
() = foo<ts>()
  val
() = ignoret (1)
}

implement main0
() = let
  implement foo$fopr
<int>() = println!("int")
  implement foo$fopr
<string>() = println!("string")
  implement foo$fopr
<bool>() = println!("bool")
  val
() = println!("test 1: should print int, string")
  val
() = foo<tcons(int, tcons(string, tnil))>()
  val
() = println!("test 2: should print bool, int")
  val
() = foo<tcons(bool, tcons(int, tnil))>()
in


Example:


datasort tlist
= tnil
| tcons of (type, tlist)

extern
   fun
{t:tlist} foo(): void
   fun
{a:type} foo$fopr(): void

impl
    foo
<tnil>() = ()

   
(a,ts) foo<tcons(a,ts)>() = {
       val
         
() = foo$fopr<a>()
         
() = foo<ts>()
         
     
}

    main0
() =
      let
         impl
            foo$fopr
<int>() = println!("int")
            foo$fopr
<string>() = println!("string")
            foo$fopr
<bool>() = println!("bool")
         val
           
() = println!("test 1: should print int, string")
           
() = foo<tcons(int, tcons(string, tnil))>()
           
() = println!("test 2: should print bool, int")
           
() = foo<tcons(bool, tcons(int, tnil))>()
         
in ()

I guess the good thing here is that it's 99% ATS2.  Of course, there are likely plenty of issues, including whitespace-significance (I was hesitant to post something this concrete).

Steinway Wu

unread,
Apr 11, 2018, 3:55:14 PM4/11/18
to ats-lang-users
Did anyone mention operators definition/overloading? I think currently in ATS2, one can only overload a symbol with a function. But I actually prefer how OCaml and Haskell handles operators: they are just functions whose names happen to be symbols instead of alphabets. One use parenthesis around the symbols to define it, and use the symbol without parenthesis to invoke it. I hope ATS3 can have better support for first-class user-defined operators without relying on overloading.

// something like this for any infix operators would be nice
fun
(?op) (arg1:type1, arg2:type2): type3 = ...

val x
= y ?op z     // use it as infix op by default
val x
= (?op)(y, z) // temporarily use it as prefix op


Hongwei Xi

unread,
Apr 11, 2018, 4:08:07 PM4/11/18
to ats-lan...@googlegroups.com
I think that ATS can already support this:

#include
"share/atspre_staload.hats"

fun ???(x: int, y: int): int = x + y

val x = op???(1, 2)

val y = 1 \op??? 2

val () = println! ("x = ", x)
val () = println! ("y = ", y)

implement main0() = ()


--
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+unsubscribe@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.

Brandon Barker

unread,
Apr 12, 2018, 10:47:57 AM4/12/18
to ats-lang-users
Ya, I really wish I had more experience with Haskell to give it a fair comparison to Scala, but I get what you are saying. Compared to the alternative 1 (Java) it is quite a bit less verbose, and compared to alternative 2 (JavaScript), I'd say it is similar, but probably still less verbose aside from type annotations. However, as we're talking about JavaScript, I think it a fair trade!

I wasn't suggesting ATS inherit the deficiencies of Scala, such as its limited means of TCO (largely if not wholly due to limitations of the JVM; I know ScalaNative plans to expand TCO functionality) or any unnecessary syntax. I was just using it as an example that worked well for me; it generally does a good job of allowing you to get work done with what you know, without having to get entangled in more advanced features until you are ready (or think you are ready, anyway). 

I am curious what the technical grounds you have for being against any use of Scala whatsoever; sounds like it would be useful to know about. 

As for shake, looks like the site (hackage) is down when I tried just now, but looking at https://shakebuild.com, I'll say it looks interesting, and sounds as though it may be good for complex builds (involving multiple languages). I'd love to give it a try - looks like it hasn't been used much for the JVM, so not sure when I'll get time to try.

Scala string interpolation works by providing an implicit value class for Strings, which then can have additional methods, like the 's' method: s"hello $name", so s is called on the following string. It isn't quite that simple, here's the full details: https://docs.scala-lang.org/overviews/core/string-interpolation.html


On Mon, Apr 9, 2018 at 7:52 PM, <vamc...@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "ats-lang-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ats-lang-users/mjS9NtQz6Pg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ats-lang-users+unsubscribe@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.

Brandon Barker

unread,
Apr 12, 2018, 12:49:54 PM4/12/18
to ats-lang-users
Apparently there is at least one example of Shake being used for the JVM: https://github.com/typelead/eta-benchmarks
--
Brandon Barker
brandon...@gmail.com

aditya siram

unread,
Apr 15, 2018, 4:07:52 PM4/15/18
to ats-lang-users

Some interesting syntax ideas here: https://rise4fun.com/Dafny/nbNTl. This is probably pretty readable to ATS programmers.
To unsubscribe from this group and all its topics, send an email to ats-lang-user...@googlegroups.com.

To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at https://groups.google.com/group/ats-lang-users.



--
Brandon Barker
brandon...@gmail.com



--
Brandon Barker
brandon...@gmail.com

Steinway Wu

unread,
Apr 28, 2018, 4:03:50 PM4/28/18
to ats-lang-users
Speaking of formalization of templates, I came upon this essay http://okmij.org/ftp/Computation/typeclass.html. Personally this is such a good read, and I finally understand how type classes are done. I feel like our templates is almost "local type class" in Oleg's words, except that ATS uses late-binding.  

On Tuesday, February 13, 2018 at 2:52:29 PM UTC-5, Steinway Wu wrote:
Hi Hongwei, just for the record, let me put down some offline discussions. 

1. Programmers can decide how a literal is parsed, or even write some plugins to parse some custom literals. For instance, 1 can be interpreted as int, nat, and int(1) etc. Programmers should be able to either turn a knob, or annotate the literal, to switch among interpretations. 
2. Some meta-programming supports via templates. E.g. `derive` of Haskell. 
3. Formalization of templates.
4. Module systems. 
5. Session types :)
6. Modular design of the whole tool chain. E.g. parsing, type equality, constraints solving, template dispatch, type erasure, etc. 
7. Maybe database-based compilations? We can store compiled blocks as a (hash, binary IR) pairs in some file-based databases, for easy reuse. Not sure how feasible it is. 
8. Interpreter, REPL, language servers, documentation tools, standard libraries, type inference, etc. 
9. More importantly, a process for open source contribution. 

Exciting!

Andrew Knapp

unread,
May 10, 2018, 8:35:57 PM5/10/18
to ats-lang-users
Another idea/request: replace the use of ATS_MEMALLOC_USER/ATS_MEMALLOC_LIBC and friends with embeddable templates.

In this example

let
  implement allocate
<message>() = pool_allocate<message>(the_message_pool)
  implement free
<message>(p) = pool_free<message>(the_message_pool, p)
in
  latency_critical_loop
<>()
end

templatizing the memory management functions would allow latency_critical_loop to be written like ordinary ATS code, but it would benefit from fast message allocation at runtime.

gmhwxi

unread,
May 11, 2018, 12:52:33 PM5/11/18
to ats-lang-users
Yes, I have a similar thought :)

Yannick Duchêne

unread,
Jun 2, 2018, 9:08:34 PM6/2/18
to ats-lang-users
And the names starting with a $, too. When I used it, I liked Ada because it prefers words over symbols as much as possible.

Le vendredi 9 février 2018 22:57:11 UTC+1, Martin DeMello a écrit :
I would love to see t@ype and similar keywords with symbols in the middle replaced by something more pronounceable - the lack of quick mental pronunciation is a surprisingly large annoyance when reading and wirting code.

martin

Yannick Duchêne

unread,
Jun 2, 2018, 9:10:43 PM6/2/18