ATS3: ATS/Xanadu

[gmhwxi]

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]

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]

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]

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.

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.

--
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/CAFrFfuEzh8TOrZjeytTasi9zq2EApaQMr5NPm8u76fRbgZOCpA%40mail.gmail.com.

[Julian Fondren]

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]

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]

(Although this is wrong, and causes a segfault.)

[Hongwei Xi]

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.

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/41f32d30-77a4-42ef-86e3-87da0647fe35%40googlegroups.com.

[vamc...@gmail.com]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/7bf25292-2094-4d32-9d74-6937e298a240%40googlegroups.com.

[August Alm]

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.

Visit this group at https://groups.google.com/group/ats-lang-users.

[gmhwxi]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

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/0609092d-2ea6-481b-bf90-7b7bfb1ca52a%40googlegroups.com.

--

Brandon Barker
brandon...@gmail.com

[Brandon Barker]

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]

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.

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/0609092d-2ea6-481b-bf90-7b7bfb1ca52a%40googlegroups.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/a8e4b46b-41d5-4e19-b7eb-a528e499ea68%40googlegroups.com.

[Brandon Barker]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/0609092d-2ea6-481b-bf90-7b7bfb1ca52a%40googlegroups.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-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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/a8e4b46b-41d5-4e19-b7eb-a528e499ea68%40googlegroups.com.

[Hongwei Xi]

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.

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/a0455949-81d5-4743-9646-69fd4fc2642a%40googlegroups.com.

[Hongwei Xi]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/10a34ca2-59dd-423a-887a-da6e25c05fcf%40googlegroups.com.

[Brandon Barker]

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.

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/10a34ca2-59dd-423a-887a-da6e25c05fcf%40googlegroups.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLr1p2cbHyZ12-GYrohMjXJaQ8v7H2rrfPjd8SbsmoXg4w%40mail.gmail.com.

--

Brandon Barker
brandon...@gmail.com

[M88]

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]

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.

[Hongwei Xi]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/282bc6ea-ebe5-4e86-9b64-1f7db11c7b45%40googlegroups.com.

[Andrew Knapp]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/1b0f9f4f-51c3-46db-94a1-b0c91d1e4f9c%40googlegroups.com.

[vamc...@gmail.com]

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]

>>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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/876a2928-ab2c-4e50-814f-6f85696fb7f5%40googlegroups.com.

[M88]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/07fc31bd-21c0-4d84-bed0-283bd9b40fb8%40googlegroups.com.

[Brandon Barker]

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.

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/876a2928-ab2c-4e50-814f-6f85696fb7f5%40googlegroups.com.

--

Brandon Barker
brandon...@gmail.com

[Brandon Barker]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/876a2928-ab2c-4e50-814f-6f85696fb7f5%40googlegroups.com.

--

Brandon Barker
brandon...@gmail.com

--

Brandon Barker
brandon...@gmail.com

[Steinway Wu]

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]

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]

Yes, I have a similar thought :)

[Yannick Duchêne]

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]

From my experience with SML, I would say too much type inference does not help understanding, and SML is just simple types. That said, type inference does not preclude type annotation.

[Yannick Duchêne]

Le mardi 13 février 2018 15:43:04 UTC+1, August Alm a écrit :

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.

For the “end”, I don’t agree. An end marker matching a begin marker, helps. I learned Isabelle/HOL theorem prover for some time, and had server issues with it, some of it directly due to the lack of a proper mark for end of blocks. Ada puts a strength on the “end” keyword for readability reasons.

For the curly brace, I agree. I believe it should be reserved for the parts of the syntax which requires conciseness. 

[Yannick Duchêne]

In my opinion, it depends on the size of the block. Python’s use of indentation is OK for short block or listing, but not OK for long ones, and splitting into multiple functions is not always fine although it is most of time. Also, the use of indentation required by the language, prevents free formatting style>.

Le mardi 13 février 2018 19:55:32 UTC+1, gmhwxi a écrit :

[…]

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!

 

[Yannick Duchêne]

Le mardi 20 février 2018 06:06:16 UTC+1, M88 a écrit :

[…]

• I think C might be best banished to .cats files.  Or, maybe the inline code blocks could be assigned a language (eg, %C{  ... %})

I guess, not to be really understood by ATS rather used by ATS as a selector when it generates output? 

 

• Odds and ends -- a build / package manager might be useful. 

NPM seems nice, but I may be wrong since I don’t use it so often. At least, that’s the best I’ve encountered. 

[Yannick Duchêne]

A long time ago I mentioned I would like a way to require proof functions to all be implemented, at least as a compilation option.

[Vanessa McHale]

NPM has numerous flaws, and ATS would be well-served by something like cabal-the-tool that has local builds and a real dependency solver, especially since ATS' type system would allow for this. I quite like the Haskell approach of reusing data types downstream!

That being said, a full solution would require some work server-side, so it's definitely not within my abilities.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/026848b9-ff51-476c-97f7-0706499df58b%40googlegroups.com.

[Yannick Duchêne]

So no package manager is good :-P If we try to design one, it would probably be not better.

My hope is the core of ATS won’t drift too much to tooling. I would prefer things like build and package management, IDE and the like, be seen as aside. If ATS provides enough data about the sources and their interpretation, anything can be created on top of that. It already as this with the JSON output. This output is not perfect, it has issues, and it could be fixed without breaking compatibility. About it, it would be nice if ATS2 could produce data about source files dependencies. It could be added to the JSON output or produce as a separate output.

By the way, something I forget to say. The syntax issue is a bit the same. It’s good to have a readable and unambiguous syntax, but it’s hard to please every one (just think about C style vs Pascal style). Syntax is a kind of presentation, the real syntax is the abstract syntax. May be an option would be to define an XML format for an abstract syntax, and the concrete syntax could be read from and written to this abstract syntax. The compiler would come with a default converter.

One important thing is the stability. I feel ATS2 is rather stable now. I agree with Hongwei when he suggested an ATS3 on top of ATS2. I would feel better with that.

[Brandon Barker]

I think nixpkgs is a decent solution, if you can bring yourself to use nixpkgs. Though, I'm not an expert in nixpkgs, if there is any crowd I would recommend it to, it would be the ATS community. That said I'm still learning Haskell and am not familiar with cabal at all.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/c0fde6bb-47dd-46cf-945b-bfd255e4dd85%40googlegroups.com.

--

Brandon Barker
brandon...@gmail.com

[Vanessa McHale]

I actually quite like cabal-the-tool in that it installs packages locally for the purposes of building Haskell libraries. If we try to design one, it may or may not be better, but it will at the least have the benefit of all past build tools.

I also agree that the language/compiler are more important than IDEs, build tools, etc. but they definitely matter. cabal-the-tool is massively convenient, and it lets me write packages that are much more complicated than otherwise. The ATS ecosystem may not yet need that, but I suppose it will be a consideration down the line.

I also think syntax matters quite a bit. It is the UI of your programming language!

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/c0fde6bb-47dd-46cf-945b-bfd255e4dd85%40googlegroups.com.

[Vanessa McHale]

Nix is more of a solution for reproducible builds, rather than a solution for package management. It is a wonderful thing, but it lacks the full flexibility.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRqar8zLP6eGLXpshxoPgOceArKW%3DtKf98YE2w6hGydpSg%40mail.gmail.com.

[Brandon Barker]

Do you think the missing features could be built around nix? My impression is that nix might work pretty well for C-like (makefile-oriented) builds without a lot of extra features, but I likely don't fully appreciate your point.

On Sun, Jun 3, 2018 at 6:34 PM, Vanessa McHale <vanessa...@iohk.io> wrote:

Nix is more of a solution for reproducible builds, rather than a solution for package management. It is a wonderful thing, but it lacks the full flexibility.

On 06/03/2018 04:04 PM, Brandon Barker wrote:

I think nixpkgs is a decent solution, if you can bring yourself to use nixpkgs. Though, I'm not an expert in nixpkgs, if there is any crowd I would recommend it to, it would be the ATS community. That said I'm still learning Haskell and am not familiar with cabal at all.

On Sun, Jun 3, 2018 at 4:42 PM, 'Yannick Duchêne' via ats-lang-users <ats-lang-users@googlegroups.com> wrote:

So no package manager is good :-P If we try to design one, it would probably be not better.

My hope is the core of ATS won’t drift too much to tooling. I would prefer things like build and package management, IDE and the like, be seen as aside. If ATS provides enough data about the sources and their interpretation, anything can be created on top of that. It already as this with the JSON output. This output is not perfect, it has issues, and it could be fixed without breaking compatibility. About it, it would be nice if ATS2 could produce data about source files dependencies. It could be added to the JSON output or produce as a separate output.

By the way, something I forget to say. The syntax issue is a bit the same. It’s good to have a readable and unambiguous syntax, but it’s hard to please every one (just think about C style vs Pascal style). Syntax is a kind of presentation, the real syntax is the abstract syntax. May be an option would be to define an XML format for an abstract syntax, and the concrete syntax could be read from and written to this abstract syntax. The compiler would come with a default converter.

One important thing is the stability. I feel ATS2 is rather stable now. I agree with Hongwei when he suggested an ATS3 on top of ATS2. I would feel better with that.

Le dimanche 3 juin 2018 05:23:22 UTC+2, Vanessa McHale a écrit :

NPM has numerous flaws, and ATS would be well-served by something like cabal-the-tool that has local builds and a real dependency solver, especially since ATS' type system would allow for this. I quite like the Haskell approach of reusing data types downstream!

That being said, a full solution would require some work server-side, so it's definitely not within my abilities. 

--
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.
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/c0fde6bb-47dd-46cf-945b-bfd255e4dd85%40googlegroups.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRqar8zLP6eGLXpshxoPgOceArKW%3DtKf98YE2w6hGydpSg%40mail.gmail.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/829d2229-4d02-467e-04dd-5bba50350e24%40iohk.io.

--

Brandon Barker
brandon...@gmail.com

[Vanessa McHale]

I am not familiar enough with Nix to know if that is the case. What is missing in Nix is versioning. You can set a specific commit, but there's no good way to know if you can upgrade to a later version of the library, as the API might have changed. Semantic versioning is one approach, and it has its flaws, but it does allow libraries to update safely and with minimal effort on the part of the maintainer, which is immensely important for reasons of security.

In C-land, libraries change pretty rarely. I think that in ATS-land they will probably change faster, if for no other reason than the fact that the compiler and the language change faster.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRquaiDb1%3DGEdftxTOtp1n9-nPYLaN%2BAtv4R2hwA9%3D1Ojw%40mail.gmail.com.

[Yannick Duchêne]

Le dimanche 3 juin 2018 22:42:38 UTC+2, Yannick Duchêne a écrit :

[…] About it, it would be nice if ATS2 could produce data about source files dependencies. It could be added to the JSON output or produce as a separate output.

`patsopt`  has a `--depgen` option, but it does not work on sats files.

[Hongwei Xi]

SATS and DATS files are really the same internally.

The option `--depgen` should work on both SATS files and DATS files:

patsopt --depgen --static foo.sats

patsopt --depgen --dynamic foo.dats

If you see something wrong, please let me know.

--

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/95a514d5-5daf-4b2c-a8e3-8cb4ff08bb55%40googlegroups.com.

[Yannick Duchêne]

My apologizes, you’re right. That’s just that it is not recursive.

If `foo.dats` staloads `dep1.stats` which staloads `dep2.stats`, then `patsopt --depgen -d foo.dats` says `foo_dats.o : dep1.sats` and `patsopt --depgen -s dep1.sats` says `dep1_sats.o : dep2.sats`.

[Yannick Duchêne]

A useful syntactic feature which requires compiler support (cannot be worked around with concrete <-> abstract syntax) is named parameters. By the way, an abstract syntax would be better with named parameters anyway.

[gmhwxi]

Thanks for the clarification.

Would it make sense to generate nixpkgs scripts based on ATS source files
(plus possible annotations)?

On Sunday, June 3, 2018 at 6:34:24 PM UTC-4, Vanessa McHale wrote:

Nix is more of a solution for reproducible builds, rather than a solution for package management. It is a wonderful thing, but it lacks the full flexibility.

On 06/03/2018 04:04 PM, Brandon Barker wrote:

I think nixpkgs is a decent solution, if you can bring yourself to use nixpkgs. Though, I'm not an expert in nixpkgs, if there is any crowd I would recommend it to, it would be the ATS community. That said I'm still learning Haskell and am not familiar with cabal at all.

On Sun, Jun 3, 2018 at 4:42 PM, 'Yannick Duchêne' via ats-lang-users <ats-lang-users@googlegroups.com> wrote:

So no package manager is good :-P If we try to design one, it would probably be not better.

My hope is the core of ATS won’t drift too much to tooling. I would prefer things like build and package management, IDE and the like, be seen as aside. If ATS provides enough data about the sources and their interpretation, anything can be created on top of that. It already as this with the JSON output. This output is not perfect, it has issues, and it could be fixed without breaking compatibility. About it, it would be nice if ATS2 could produce data about source files dependencies. It could be added to the JSON output or produce as a separate output.

By the way, something I forget to say. The syntax issue is a bit the same. It’s good to have a readable and unambiguous syntax, but it’s hard to please every one (just think about C style vs Pascal style). Syntax is a kind of presentation, the real syntax is the abstract syntax. May be an option would be to define an XML format for an abstract syntax, and the concrete syntax could be read from and written to this abstract syntax. The compiler would come with a default converter.

One important thing is the stability. I feel ATS2 is rather stable now. I agree with Hongwei when he suggested an ATS3 on top of ATS2. I would feel better with that.

Le dimanche 3 juin 2018 05:23:22 UTC+2, Vanessa McHale a écrit :

NPM has numerous flaws, and ATS would be well-served by something like cabal-the-tool that has local builds and a real dependency solver, especially since ATS' type system would allow for this. I quite like the Haskell approach of reusing data types downstream!

That being said, a full solution would require some work server-side, so it's definitely not within my abilities. 

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/c0fde6bb-47dd-46cf-945b-bfd255e4dd85%40googlegroups.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRqar8zLP6eGLXpshxoPgOceArKW%3DtKf98YE2w6hGydpSg%40mail.gmail.com.

[Brandon Barker]

Very good points; version strings are supported in a standard field of a nix expression, so something written on top of this that handles package management and upgrades in a way similar to yarn or npm could potentially be the way to go. It seems like this is a more general problem than what ATS alone faces, and it isn't clear to me that we would need an ATS specific solution, so maybe dealing with semantic versioning is something that should be broached within the nix community - I'll try to look into this soon, after any further comments are made here on the topic. But I don't think there's anything stopping people from using nixpkgs already for most small projects. Entire OS environments and associated user environments are being built for nix, and I will hazard a guess that most ATS packages will have few added dependencies beyond examples that can already be found in the rather massive nixpkgs collection. One likely has to learn to specify versions in nix, at some point (there seems to be more than one way to do this). From time to time though, someone will publish a package that requires a specific version of ATS, so this will need to be specified, and each such version of ATS will need to be added to the nixpkgs collection (this is just one example). But in general, nix will assume that the latest version of ATS in nixpkgs can be used, which should be a safe bet as long as we are vigilant in updating nixpkgs.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRqar8zLP6eGLXpshxoPgOceArKW%3DtKf98YE2w6hGydpSg%40mail.gmail.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-lan...@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/829d2229-4d02-467e-04dd-5bba50350e24%40iohk.io.

--

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-lan...@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/CAORbNRquaiDb1%3DGEdftxTOtp1n9-nPYLaN%2BAtv4R2hwA9%3D1Ojw%40mail.gmail.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-lan...@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/6b7604ff-39bf-5c01-61ea-878f74880bda%40iohk.io.

--

Brandon Barker
brandon...@gmail.com

[Yannick Duchêne]

About the syntax: I believe using `<` and `>` for template arguments could help. It would distinguish it from universal quantification and would easily reminds the same used in C++.

Ex. this:

        fn <…> f {…} (…): […] t

Instead of this:

        fn {…} f {…} (…): […] t

[Yannick Duchêne]

Additionally, requiring to separate static variables declarations and the expressions of it, may be good. That is, requiring this convention:

Requiring this:

    [a: int; b: int | p(a); q(b)]

Instead of this:

    [a: int; p(a); b: int; q(b)]

[Hongwei Xi]

Thanks. I had it in my mind, too :)

--

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/49c48318-4568-47c7-a724-a1af2ec90b87%40googlegroups.com.

[Yannick Duchêne]

With syntax, there is also the case of the nullary functions. It’s convenient to be able to evaluate it without the parentheses, since it allow to replace it by a variable, or the other way, to replace a variable by a nullary function, without the need to rewrite it at every use places. On the other hand, it is required in functional languages, to be able to refer to a function itself. If both expectation are fulfilled together, this may produce ambiguities. Or may be it is possible to rely on the expected type at the place the reference occurs, to solve the ambiguity between f for its evaluation and f for itself.

[Hongwei Xi]

Do you mean to write f for f()?

On Wed, Jun 6, 2018 at 8:05 PM, 'Yannick Duchêne' via ats-lang-users <ats-lan...@googlegroups.com> wrote:

With syntax, there is also the case of the nullary functions. It’s convenient to be able to evaluate it without the parentheses, since it allow to replace it by a variable, or the other way, to replace a variable by a nullary function, without the need to rewrite it at every use places. On the other hand, it is required in functional languages, to be able to refer to a function itself. If both expectation are fulfilled together, this may produce ambiguities. Or may be it is possible to rely on the expected type at the place the reference occurs, to solve the ambiguity between f for its evaluation and f for itself.

--

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/8b5e3153-9d1c-495a-bea2-af7625904441%40googlegroups.com.

[Brandon Barker]

Hi Vanessa,

I'm not super familiar with all this either, but I just saw what appears to be a way to use the package version on Hackage as a source override in a nix expression:

https://github.com/NixOS/nixpkgs/pull/41600/files

I assume this is Haskell specific at the moment, but maybe something could be adapted for use in ATS down the road.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRqar8zLP6eGLXpshxoPgOceArKW%3DtKf98YE2w6hGydpSg%40mail.gmail.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-lan...@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/829d2229-4d02-467e-04dd-5bba50350e24%40iohk.io.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRquaiDb1%3DGEdftxTOtp1n9-nPYLaN%2BAtv4R2hwA9%3D1Ojw%40mail.gmail.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/6b7604ff-39bf-5c01-61ea-878f74880bda%40iohk.io.

--

Brandon Barker
brandon...@gmail.com

[Yannick Duchêne]

Le jeudi 7 juin 2018 02:21:05 UTC+2, gmhwxi a écrit :

Do you mean to write f for f()?

Yes, writing f for f() when f is nullary, like Pascal (the language) did and others. But this may be ambiguous, since in a functional language, there  may be reference to f for itself. 

[Vanessa McHale]

Oh that's quite nice! Do you know if there's a way to implement a version solver in Nix?

That's not 100% Haskell-specific, but it *is* likely dependent on one feature of Hackage, namely unique (and immutable) hashes for each package. I'm not sure what NPM does but if packages there are immutable it would work quite well.

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRp-ZKrk4GqwOipggw75iLkm9Ypy3dN2_CyK9P_3aiDdGg%40mail.gmail.com.

[Yannick Duchêne]

With ATS2, statics and dynamics files are distinguished by a compiler flag or the file extension. For ATS3, what about a distinction based on a syntactic construct? Ex. something like `static begin … end` and `dynamic begin … end` or anything else.

This could then call another question, but I leave this one alone.

[gmhwxi]

Sure. I am thinking along the line of a directive. For instance,

##static

##dynamic

[Yannick Duchêne]

Le samedi 9 juin 2018 14:56:23 UTC+2, gmhwxi a écrit :

Sure. I am thinking along the line of a directive. For instance,

##static

##dynamic

That’s fine. So if ATS3 has modules, it seems this will be file based modules.

[Yannick Duchêne]

May be it’s already part of the plan, still in case I feel construct like `val-~Some_vt (…)` where the “-” and the “~” can be visually concatenated together, prevents readability. Some characters could require to be blank separated when they are not part of the same symbol.

[Brandon Barker]

To my knowledge, there isn't a version solver. It might be an interesting topic to broach with the hnix project (if for no other reason than we here all probably prefer Haskell to C++ or other languages used in the nix community). I think you'd have to be careful about the version solving order to guarantee it remains reproducible in the nix fashion, which I think would be fine as long as (as you pointed out) there are hashes being produced at all steps along the way; if only the nixpkgs repo is being used directly, then it isn't a problem. Will have to look into this more - if nothing else, I suspect finding a syntactic sugar for specifying version overrides for package attributes in a list of nix expressions would increase the UX of this feature greatly.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRquaiDb1%3DGEdftxTOtp1n9-nPYLaN%2BAtv4R2hwA9%3D1Ojw%40mail.gmail.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-lan...@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/6b7604ff-39bf-5c01-61ea-878f74880bda%40iohk.io.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAORbNRp-ZKrk4GqwOipggw75iLkm9Ypy3dN2_CyK9P_3aiDdGg%40mail.gmail.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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/50b3782a-0b99-860b-5729-98498c88e605%40iohk.io.

--

Brandon Barker
brandon...@gmail.com

[Andrew Knapp]

Something to look at in terms of metaprogramming is Terra, which is a simple low-level language metaprogrammable in Lua at compile time.

http://terralang.org/

Especially take a look at the approach to "templates," which are in reality more way more powerful than C++ templates (and higher order OCaml functors too.)

http://terralang.org/#templating

You can also implement object-oriented class systems as a library.

http://terralang.org/#class-systems

[Hongwei Xi]

We seem to have quite a few similar ideas :)

Cheers!

--

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/aafdb4b8-11e0-482b-8594-857dac1ef2f3%40googlegroups.com.

[Yannick Duchêne]

May be I overlooked something, but what is exactly expected from a custom meta‑programming language for ATS? Can’t we just do meta‑programming with any language? Or is this because the meta‑programming language must know how to type‑check ATS constructs and this would be too difficult to encode it in any one’s favorite scripting language?

[Hongwei Xi]

Meta-programming is a very generic term. For instance, I see type classes in Haskell

as a form of meta-programming, which requires the crucial support of the underlying type

system. Actually, I also seem OOP as a form of meta-programming :)

Datatypes in ML clearly reminds me of Horn clauses in logic programming (e.g., Prolog).

I believe that we can do a lot code synthesis based on datatypes. Actually, dictionaries

associated with type classes are thus synthesized.

On Mon, Jun 18, 2018 at 6:01 PM, 'Yannick Duchêne' via ats-lang-users <ats-lan...@googlegroups.com> wrote:

May be I overlooked something, but what is exactly expected from a custom meta‑programming language for ATS? Can’t we just do meta‑programming with any language? Or is this because the meta‑programming language must know how to type‑check ATS constructs and this would be too difficult to encode it in any one’s favorite scripting language?

--

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/cb824d4c-00ab-47a4-b92a-e6652eb18b59%40googlegroups.com.

[Vanessa McHale]

Metaprogramming (i.e. a macro) that is guaranteed to generate type-safe code is a nontrivial problem, though I think users would much appreciate it if it were available :)

On 06/18/2018 05:01 PM, 'Yannick Duchêne' via ats-lang-users wrote:

May be I overlooked something, but what is exactly expected from a custom meta‑programming language for ATS? Can’t we just do meta‑programming with any language? Or is this because the meta‑programming language must know how to type‑check ATS constructs and this would be too difficult to encode it in any one’s favorite scripting language?

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/cb824d4c-00ab-47a4-b92a-e6652eb18b59%40googlegroups.com.

[Yannick Duchêne]

So after you, it’s about ensuring the source generated from a language to a target language will type‑check (like I wondered) and after Professor Xi, it’s about implicitly generated things from constructs of the language.

So could we say in one case, meta‑programming is based on a meta‑language (with the type safety you mentioned) and in another case, meta‑programming is based on an additional meaning of the constructs of the language? In one case, there is a distinct meta‑language, in the other, the language is its own meta‑language.

After what was said so far, I was feeling to guess Professor Xi wanted the later, but since he acknowledged the Lua example, I started to wonder.

[Guannan Wei]

Another form of meta-programming is multi-stage programming. Like F# and MetaOCaml provides a easier way to generate type-safe code; in some sense, Lightweight Modular Staging (LMS) in Scala is also able to do that, but since you can generate code in other language like C, things can be complicated.

Personally I also appreciate the way of how BER MetaOCaml implements (http://okmij.org/ftp/ML/MetaOCaml.html#implementing-staging) which only needs a preprocessing to source code. I guess this can be supported by a flexible language extension mechanism like Haskell's pragma.

If the language provides some facilities (like virtualization) that enable users to implement meta-programming (e.g staging) at the library level (like LMS in Scala), and meanwhile keeping the syntax small and clean, I think that would be great.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/325b223f-10c1-4776-bb59-631a84ab5810%40googlegroups.com.

[Yannick Duchêne]

For `extvar`, `:=` could be used instead of `=`, since it is an assignment. Ex. `extvar "foo" := 1` instead of `extvar "foo" = 1`

[Hongwei Xi]

I thought about it, too.

var x := 1

should replace

var x = 1

in ATS3.

On Fri, Jun 22, 2018 at 6:07 PM, 'Yannick Duchêne' via ats-lang-users <ats-lan...@googlegroups.com> wrote:

For `extvar`, `:=` could be used instead of `=`, since it is an assignment. Ex. `extvar "foo" := 1` instead of `extvar "foo" = 1`

--

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/ee5ade43-3009-4738-9b6c-e028a5f7f9c5%40googlegroups.com.

[Yannick Duchêne]

May be it’s a detail since it seems rarely used (although I guess it’s useful): the `withtype` annotation would better come before the function body rather than after; it would be more readable.

[Hongwei Xi]

This issue has been raised before.

We could definitely do something like that in ATS3.

On Sat, Jun 23, 2018 at 9:21 AM, 'Yannick Duchêne' via ats-lang-users <ats-lan...@googlegroups.com> wrote:

May be it’s a detail since it seems rarely used (although I guess it’s useful): the `withtype` annotation would better come before the function body rather than after; it would be more readable.

--

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/874ca28a-a624-408b-afb3-646aca950aae%40googlegroups.com.

[Yannick Duchêne]

If faisable, making some name reserved (i.e. cannot be redefined) could be nice.

Actually one can do this without a complaint; it would be nice if it could be disallowed:

        stadef false_bool:bool = true_bool

        stadef false:bool = true_bool

[Julian Fondren]

Protecting people from their own deliberately obfuscated code is a very steep hill

to have to climb, and this isn't plausible as anything else.

Reserving those names would probably annoy someone writing experimental

code with alternate Boolean values, and have no other affect on users of ATS.

[Yannick Duchêne]

Le samedi 30 juin 2018 00:36:16 UTC+2, Julian Fondren a écrit :

Protecting people from their own deliberately obfuscated code is a very steep hill

to have to climb, and this isn't plausible as anything else.

[…]

That’s more about Pollack inconsistency than about obfuscated code :-p 

[Yannick Duchêne]

On the other hand, it’s a good thing to have a symbol for distinguishing reserved names when these names are numerous.

Le dimanche 3 juin 2018 03:08:34 UTC+2, Yannick Duchêne a écrit :

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]

May a proper aliasing construct would be an idea.

Ex. this from Postiats source (among many-many others):

        macdef NEG = $SYM.symbol_NEG

But a `macdef` may be more complex (the same with `val`) and it would be beneficial to have a safe and easy to follow aliasing construct. Aliasing is a very common idiom.

Ex.

        alias NEG = $SYM.symbol_NEG