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!

On Tuesday, February 13, 2018 at 12:11:28 PM UTC-5, August Alm wrote:
>
> 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.
>
>
> Den tisdag 13 februari 2018 kl. 16:56:52 UTC+1 skrev Artyom Shalkhakov:
>
> If we talk syntax, why not adopt that of C? :-)
>>
>> 13 февр. 2018 г. 8:43 ПП пользователь "August Alm" <augu...@gmail.com> 
>> написал:
>>
>> 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.
>>
>>
>> Den måndag 12 februari 2018 kl. 19:59:54 UTC+1 skrev 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.
>>>
>>> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:
>>>>
>>>> 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:
>>>>>
>>>>> 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.
>> 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
>>  
>> <https://groups.google.com/d/msgid/ats-lang-users/7bf25292-2094-4d32-9d74-6937e298a240%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/e819f6de-0b9a-4360-abcd-afb3fbfdb243%40googlegroups.com.

Reply via email to