--
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.
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.
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.
--
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.
--
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.
def functionName ([list of parameters]) : [return type] = { function body return [expr] }
val add1: Int => Int = (i) => i + 1
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.
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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/0609092d-2ea6-481b-bf90-7b7bfb1ca52a%40googlegroups.com.
name = "Spongebob Squarepants"
print(f"Who lives in a Pineapple under the sea? {name}.")
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}.")
To post to this group, send email to ats-lan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/0609092d-2ea6-481b-bf90-7b7bfb1ca52a%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/a8e4b46b-41d5-4e19-b7eb-a528e499ea68%40googlegroups.com.
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.
--
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.
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.
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.
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.
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... ').
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.
--
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.
--
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.
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
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 ()
// 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
--
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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/876a2928-ab2c-4e50-814f-6f85696fb7f5%40googlegroups.com.
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.
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!
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
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
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.
[…]
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!
[…]
- I think C might be best banished to .cats files. Or, maybe the inline code blocks could be assigned a language (eg, %C{ ... %})
- Odds and ends -- a build / package manager might be useful.
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.
--
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.
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.
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.
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.
--
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.
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.
[…] 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.
--
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.
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.
--
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.
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.
--
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.
--
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.
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.
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.
--
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.
Do you mean to write f for f()?
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.
Sure. I am thinking along the line of a directive. For instance,##static##dynamic
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.
--
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.
--
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.
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.
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 :)
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.
--
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.
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.
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.
Protecting people from their own deliberately obfuscated code is a very steep hillto have to climb, and this isn't plausible as anything else.
[…]
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