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 :)
On Sat, Mar 10, 2018 at 9:11 AM, Brandon Barker <brandon.bar...@gmail.com>
wrote:
> 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
> ;-).
>
> On Saturday, March 10, 2018 at 7:33:04 AM UTC-5, Brandon Barker wrote:
>>
>> 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 ;-).
>>
>> On Sat, Mar 10, 2018 at 7:09 AM, gmhwxi <gmh...@gmail.com> wrote:
>>
>>>
>>> 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.
>>>
>>>
>>> On Friday, March 9, 2018 at 3:29:18 PM UTC-5, Brandon Barker wrote:
>>>>
>>>> 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.or
>>>> g/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
>>>>
>>>> On Wednesday, March 7, 2018 at 12:01:03 PM UTC-5, Brandon Barker wrote:
>>>>>
>>>>> 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 <https://github.com/scalacenter/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
>>>>>
>>>>> On Wednesday, March 7, 2018 at 11:52:49 AM UTC-5, Brandon Barker wrote:
>>>>>>
>>>>>> 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 powe
>>>>>> <http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html>r.
>>>>>> 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
>>>>>> <https://en.wikipedia.org/wiki/Olympus_Mons#/media/File:Olympus_Mons_Side_View.svg>
>>>>>> 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
>>>>>> <https://github.com/lihaoyi/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
>>>>>> <https://github.com/cvogt/cbt> 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:
>>>>>>>
>>>>>>> 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 a topic in the
>>> Google Groups "ats-lang-users" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/ats-lang-users/mjS9NtQz6Pg/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> ats-lang-users+unsubscr...@googlegroups.com.
>>> To post to this group, send email to ats-lang-users@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/ats-lang-users.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/ats-lang-users/0609092d-2ea6-481b-bf90-7b7bfb1ca52a%40go
>>> oglegroups.com
>>> <https://groups.google.com/d/msgid/ats-lang-users/0609092d-2ea6-481b-bf90-7b7bfb1ca52a%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>>
>> --
>> Brandon Barker
>> brandon.bar...@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+unsubscr...@googlegroups.com.
> To post to this group, send email to ats-lang-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/ats-lang-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/ats-lang-users/a8e4b46b-41d5-4e19-b7eb-a528e499ea68%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/ats-lang-users/a8e4b46b-41d5-4e19-b7eb-a528e499ea68%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ats-lang-users+unsubscr...@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLqD4MeAZno95YT0thUb4cxqTunc83hT%3DX1JG8WaEMtM%2BA%40mail.gmail.com.
