Hey! Just for some "food for thought", you may want to read the parts under heading "Literal Smalltalk arrays" and the section following - "Sidestory: Adding literal Dictionaries to Smalltalk?" ...at: http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ regards, Göran

2014-08-29 13:16 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:

On 29 Aug 2014, at 12:53, Göran Krampe <goran@krampe.se> wrote:

...

Hey!

Just for some "food for thought", you may want to read the parts under heading "Literal Smalltalk arrays" and the section following - "Sidestory: Adding literal Dictionaries to Smalltalk?"

...at:

http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/

...

regards, Göran

Yes, that is a good write up, touching on all kinds of aspects, balanced too. Pretty complicated subject, right ? ;-) As you mention it is quite hard to reach an agreement. Objectives/goals are different for everybody.

Yes, a good read as well.

Since we had those discussions long ago, I've actually grown quite used to writing

{ #foo->1. #bar->2 } asDictionary

I know it is not super efficient, or super compact, but I can certainly live with it.

I know. But I was a bit sad, when porting SmaCC from Dolphin to Pharo, to have to remove all the literals optimisations John Brant has added in the code generation, such as: ^ [ Dictionary new at: #foo put: #a; at: #bar put: #b; yourself ] once [1] and: ##(Character value: 16rXXXX) [2] (I have a framework of thought where it would be possible, for the pharo compiler, to track and optimise such methods as [1] without requiring the "once" above, but I have no idea if the gain would be worth the pain) Thierry

...

Hey!

Just for some "food for thought", you may want to read the parts under heading "Literal Smalltalk arrays" and the section following - "Sidestory: Adding literal Dictionaries to Smalltalk?"

...at:

http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/

regards, Göran Yes, that is a good write up, touching on all kinds of aspects, balanced too. Pretty complicated subject, right ? ;-)

:)

As you mention it is quite hard to reach an agreement. Objectives/goals are different for everybody.

Since we had those discussions long ago, I've actually grown quite used to writing

{ #foo->1. #bar->2 } asDictionary #{ #foo->1. #bar->2 } could do it for literal ones :)

I know it is not super efficient, or super compact, but I can certainly live with it.

do you know if amber has { } because ideally I would love to have something like #() literl array ##() dynamic array why not :) #{} literal dictionary ##{} dynamic literal dictionary On 29/8/14 12:53, Göran Krampe wrote:

Hey!

Just for some "food for thought", you may want to read the parts under heading "Literal Smalltalk arrays" and the section following - "Sidestory: Adding literal Dictionaries to Smalltalk?"

...at:

http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/

regards, Göran

On 29/8/14 11:56, Sven Van Caekenberghe wrote:

Hi,

I had a quick look at the ObjectLiterals project - I must admit that I forgot most about it ;-)

me too :) Christophe was patching STON to make it less verbose when I remembered that igor sent some ideas around.

Now that I see it again, one of the things that strikes me is that there is no such thing as a general object fallback, as far as I can see - that is a choice of course.

Note that I did answer your earlier mail about STON

http://forum.world.st/About-STON-td4772934.html

Sven

On 29 Aug 2014, at 11:35, stepharo <stepharo@free.fr> wrote:

...

Hi guys

we are looking at STON and ObjectLiterals with Christophe and for handling metadata.

And I was brainstorming.... I was wondering if it would be possible to have a bit more use of self evaluating

for example 1@3 #k -> 2 instead of (Association #k 123)

my brainstorming is how could we minimize new syntactic constructs and still support a literal object format. So object literal cover that so may be this is good.

1@3 as (Point 1 3) and #k -> 123 as (Association #k 123)

So I'm not clear but this is interesting to think about it. I would like to have also a dictionary literal syntax.... but this another story.

Stef

PS: Sven I added support for Association into the ObjectLiteral project to see how it works.

I took Igor's initial code and created a new project:

http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/

and I added ObjectLiteralParser to convert any Character Stream or String into a Smalltalk Literal Array and eventually into an Object.

This proof of concept moves the ObjectLiteral format/notation away from the Smalltalk compiler and will help us discuss more concretely the actual details of the specification (which is still not 100% finished).

I also added 12 unit tests and cleaned up the code and comments.

Please have a look at the code.

This is one of the tests:

ObjectLiteralParserTests>>#testMixed1 | input output | input := ' #(Array 1 foo #''foo-#bar'' true false nil 3.14159 -100 ''string'' (#OrderedCollection 7 8 9) #(Set 10) (Dictionary x 1 y 2) ) '. output := { 1. #foo. #'foo-#bar'. true. false. nil. 3.14159. -100. 'string'. OrderedCollection withAll: #(7 8 9). Set with: 10. Dictionary newFromPairs: #(x 1 y 2 ). }. self assert: (self parserOn: input) nextObjectLiteral equals: output

I like this format, its simplicity and elegance is appealing, it offers distinctive advantages in the Smalltalk context while its slight readability disadvantage is acceptable. Like any format it is a compromise and a tradeoff, but a rather good one.

Regards,

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

For now parsetime as #()

Are you considering a form of compile-time expression or quasi-quotes?

On 29 August 2014 11:35, stepharo <stepharo@free.fr> wrote:

...

Hi guys

we are looking at STON and ObjectLiterals with Christophe and for handling metadata.

And I was brainstorming.... I was wondering if it would be possible to have a bit more use of self evaluating

for example 1@3 #k -> 2 instead of (Association #k 123)

my brainstorming is how could we minimize new syntactic constructs and still support a literal object format. So object literal cover that so may be this is good.

1@3 as (Point 1 3) and #k -> 123 as (Association #k 123)

So I'm not clear but this is interesting to think about it. I would like to have also a dictionary literal syntax.... but this another story.

Stef

PS: Sven I added support for Association into the ObjectLiteral project to see how it works.

I took Igor's initial code and created a new project:

http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/

and I added ObjectLiteralParser to convert any Character Stream or String into a Smalltalk Literal Array and eventually into an Object.

This proof of concept moves the ObjectLiteral format/notation away from the Smalltalk compiler and will help us discuss more concretely the actual details of the specification (which is still not 100% finished).

I also added 12 unit tests and cleaned up the code and comments.

Please have a look at the code.

This is one of the tests:

ObjectLiteralParserTests>>#testMixed1 | input output | input := ' #(Array 1 foo #''foo-#bar'' true false nil 3.14159 -100 ''string'' (#OrderedCollection 7 8 9) #(Set 10) (Dictionary x 1 y 2) ) '. output := { 1. #foo. #'foo-#bar'. true. false. nil. 3.14159. -100. 'string'. OrderedCollection withAll: #(7 8 9). Set with: 10. Dictionary newFromPairs: #(x 1 y 2 ). }. self assert: (self parserOn: input) nextObjectLiteral equals: output

I like this format, its simplicity and elegance is appealing, it offers distinctive advantages in the Smalltalk context while its slight readability disadvantage is acceptable. Like any format it is a compromise and a tradeoff, but a rather good one.

Regards,

Sven

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill