0005 - Literal syntax for collections

[Ducasse]

No description provided.

[jecisc]

We (Christophe, Pablo and me) find that the naming #withAllForBrace: not so good.

In the future we will have to explain this selector in books and it would be nice to have an explicit name easy to explain. Maybe #fromBracedSyntax:? Since we do not create only collection (we want to be able to create points or rectangles). This seems easier to explain to students

[Ducasse]

It is ok for me.
Now withAll: is the default to fill up a dictionary so it is least surprise.
So we could have withAllForBraceSyntax: (but I'm not a big fan of Syntax).
#fromBracedSyntax: looks a bit strange to me. After we can change this

[Rinzwind]

Suggestion: the ‘motivation’ section in the proposal should perhaps better clarify the need for a syntax extension. At the moment it’s not so clear, at least to me, why it would not be sufficient to implement some binary selector, say #*, on Collection’s class as an alias for #newFromArray:, allowing one to write:

Set*{1 . Set*{2 . 2} . 1}.
  "=> a Set(a Set(2) 1)"

Bag*{1 . Bag*{2 . 2} . 1}.
  "=> a Bag(1 1 a Bag(2 2))"

Dictionary*{ #a -> 33 . #b -> 44 }.
  "=> a Dictionary(#a->33 #b->44 )"

[svenvc]

Suggestion: the ‘motivation’ section in the proposal should perhaps better clarify the need for a syntax extension. At the moment it’s not so clear, at least to me, why it would not be sufficient to implement some binary selector, say #*, on Collection’s class as an alias for #newFromArray:, allowing one to write:

Set*{1 . Set*{2 . 2} . 1}.
  "=> a Set(a Set(2) 1)"

Bag*{1 . Bag*{2 . 2} . 1}.
  "=> a Bag(1 1 a Bag(2 2))"

Dictionary*{ #a -> 33 . #b -> 44 }.
  "=> a Dictionary(#a->33 #b->44 )"

Wow, that is a great idea ! I love it. Not sure about which binary selector would be best, but that is a secondary discussion.

[estebanlm]

Suggestion: the ‘motivation’ section in the proposal should perhaps better clarify the need for a syntax extension. At the moment it’s not so clear, at least to me, why it would not be sufficient to implement some binary selector, say #*, on Collection’s class as an alias for #newFromArray:, allowing one to write:

Set*{1 . Set*{2 . 2} . 1}.
  "=> a Set(a Set(2) 1)"

Bag*{1 . Bag*{2 . 2} . 1}.
  "=> a Bag(1 1 a Bag(2 2))"

Dictionary*{ #a -> 33 . #b -> 44 }.
  "=> a Dictionary(#a->33 #b->44 )"

I like it (as Sven, I would probably not use * but another selector, but that's another discussion :) ).
@Ducasse what do you think about this?

[Ducasse]

if *{ is a message then what are . and }.
I do not see how this can work with *{ as a message.
I think that {Set is more stable. It follows the same syntax as { } and it is a super minimal extension of curly braces. It brings generality.

[Ducasse]

So to me a message does not work. In particular because we do not have macros in Pharo. because in that case *{ should not be a message but a kind of macro. and in lisp they have a way to know the end of an expression.

[svenvc]

Well, * would be the message, { and } are a brace array, with . in between elements.

And no, it is not a macro, I think we all agree on that.

In any case, it is a thought experiment. I think we all want no more syntax than strictly necessary.

[Rinzwind]

Just to avoid any confusion, here’s the implementation of #* on Collection’s class, as an alias for #newFromArray:, I had in mind (in Tonel format):

Collection class >> * anArray [

	^ self newFromArray: anArray
]

[Ducasse]

Ah ok I see.
Then indeed no need to change the parser and I would not overload * but for example use %>
We were checking with others here the characters that we can use for selector.

Set %> { 1 . 3+3 }

[Ducasse]

So can you propose a PR? and we will close my proposal.

[noha]

Wasn't one reason for changing the parser to avoid intermediate collections?

[Ducasse]

I would have like but this is the way {} is implemented.
In fact the array is created anyway internally by the bytecode and the implementation of { } was basically sending a message with the internally created array. But let us see what others are saying. At least it forced us to clean some aspects of the {} implementation

[Rinzwind]

So can you propose a PR? and we will close my proposal.

I created the following pull request for it: pharo-project/pharo#15316