[Grace-core] How many method application brackets does one language need?

[Andrew P Black]

I wrote this last week.  Apparently it was never sent.

====================

I really don’t want to open this up again.  I want to get experience with what we decided in September, and then reconsider if that formulation gives us problems.  If we keep on revisiting stuff endlessly, we will get nowhere.

In addition to the “built in lineup notation” solution that we agreed upon, I can see three other possible solutions.  One is some variant of Michael’s variable signature methods defined with regular expressions, which would let us define the arity 0, 1, 2, 3, … n versions of list in one go.  The second is some variant of the Python tuple notation, where all argument lists are of length1, and we simulate multiple arguments and lineup arguments using some form of tuple.   The third is to use :: on bindings to mean cons — this would give us a way of writing lineups as 1::2::3::4::5 — something like ML lists. This looks OK with literals, but isn’t so good when the elements are expressions.  Maybe Michael has something better in mind — I couldn’t find that in his email.

All these ideas have lots of details that need to be worked out.  If Michael feels passionate about this, then I suggest that he sits down and writes a short and clear document, suitable for inclusion in the spec, that explains how his proposal would work, and some accompanying notes, perhaps in the form of a blog post, that explains why it is superior.

Once gain, lets not re-open this issue until we have a proposal for seething better.

	Andrew


On 7 Mar 2016, at 19:31, James Noble <kjx at ecs.vuw.ac.nz> wrote:

> 
>> On 8/03/2016, at 14:41pm, Michael Homer <Michael.Homer at ecs.vuw.ac.nz> wrote:
>> 
>> For clarity, an example of both styles of call is:
>>   list ( 1, 2, 3 )
>>   list [ 1, 2, 3 ]
> 
> this is not a setup - but I can see Michael's point.
> 
> thinking about this (again) - it is a bit odd that (given overriding with arity) all of 
> 
> list
> list (1)
> list (1, 2)
> list (1, 2, 3)
> list (1, 2, 3, 4)
> list (1, 2, 3, 4, 5)
> 
> are legal, and at least able to be defined as easily as 
> 
> if (_) then (_) 
> if (_) then (_) else ()
> if (_) then (_) elseif () then () else ()
> if (_) then (_) elseif () then () elseif () then () else ()
> 
> if we get rid of [] brackets in BOTH indexing AND "iterables" then we could use [ ] for generics with *no* parsing issues whatsoever.
> 
> for the time being, minigrace could just special case the parser so writing list() or seq() does what [] does now.
> 
> Yes, people passing sequences would have to write:
> 
> myWindow.addWidgets (seq(
>   title "Launch",
>   text "Good Morning Mrs President", 
>   button "OK" action { missiles.launch },
>   button "Cancel" action { missiles.abort }
> )) 
> 
> rather than 
> 
> myWindow.addWidgets [
>   title "Launch",
>   text "Good Morning Mrs President", 
>   button "OK" action { missiles.launch },
>   button "Cancel" action { missiles.abort }
> ]
> 
> but getting rid of BOTH indexing and "lineups" would really simplify this part of the language.
> I have been sceptical of taking on overriding on arity but this would help convince me.
> 
> But going one step further: how much is it worse than writing e.g. 
> 
> list
> list (1) 
> list (1) and (2)
> list (1) and (2) and (3) 
> list (1) and (2) and (3) and (4)
> list (1) and (2) and (3) and (5) and (5) 
> 
> or 
> 
> myWindow.addWidgets 
>  (list (title "Launch") 
>   and (text "Good Morning Mrs President") 
>   and (button "OK" action { missiles.launch}) 
>   and (button "Cancel" action { missiles.abort }) )
> 
> 
> HMM: I can see the first one being clumsy, but the second looks... surprisingly fine.
> 
> 
> 
> Andrew might ask - what happens to "list.empty" - answer  - we just write "list".
> what happens to "list.withAll"  - we just write listWithAll  or listFromAll or something.asList
> 
> 
> unfortunately I think we should think about this again too
> 
> James
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20160311/c09d2f7c/attachment.html>