[Pharo-project] Yet another Notation format: Object literals
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that). The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example: (1@3) asObjectLiteral --> #(#Point 1 3) { 1@2. 3@4. true. false . nil } asObjectLiteral -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') Next thing, you can 'pretty-print' it (kinda): #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' and sure thing, you can do reverse conversion: '#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral a Dictionary('foo'->'bar' 1->#(1 2 3) ) Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course. The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there. Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project.. So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project. -- Best regards, Igor Stasenko.
On 19 October 2012 12:09, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that).
The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example:
(1@3) asObjectLiteral --> #(#Point 1 3)
{ 1@2. 3@4. true. false . nil } asObjectLiteral
This is basically Scala's unapply function: it permits objects to expose their internal structure (in any way they choose, of course). It looks like you've written a fairly generic one that would cover most use cases. This kind of destructuring lends itself to pattern matching [1] and unification [2][3]. [1] http://www.lshift.net/blog/2011/05/15/algebraic-data-types-and-ometa2 (look for "Node>>unapply") [2] http://www.lshift.net/blog/2011/05/31/unification-pattern-matching-but-twice... [3] http://www.lshift.net/blog/2012/01/16/unifying-parts-of-structures frank
On 19 October 2012 13:40, Frank Shearar <frank.shearar@gmail.com> wrote:
On 19 October 2012 12:09, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that).
The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example:
(1@3) asObjectLiteral --> #(#Point 1 3)
{ 1@2. 3@4. true. false . nil } asObjectLiteral
This is basically Scala's unapply function: it permits objects to expose their internal structure (in any way they choose, of course). It looks like you've written a fairly generic one that would cover most use cases.
This kind of destructuring lends itself to pattern matching [1] and unification [2][3].
well, my intent was to demonstrate a simple and straightforward way how you can store virtually object as literal (in string) and read it back. and keep it fairly human readable, and without need to use JSON ;) i don't mind, if it lends to extra stuff, that's even better :)
[1] http://www.lshift.net/blog/2011/05/15/algebraic-data-types-and-ometa2 (look for "Node>>unapply") [2] http://www.lshift.net/blog/2011/05/31/unification-pattern-matching-but-twice... [3] http://www.lshift.net/blog/2012/01/16/unifying-parts-of-structures
frank
-- Best regards, Igor Stasenko.
On 19 October 2012 13:56, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 October 2012 13:40, Frank Shearar <frank.shearar@gmail.com> wrote:
On 19 October 2012 12:09, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that).
The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example:
(1@3) asObjectLiteral --> #(#Point 1 3)
{ 1@2. 3@4. true. false . nil } asObjectLiteral
This is basically Scala's unapply function: it permits objects to expose their internal structure (in any way they choose, of course). It looks like you've written a fairly generic one that would cover most use cases.
This kind of destructuring lends itself to pattern matching [1] and unification [2][3].
well, my intent was to demonstrate a simple and straightforward way how you can store virtually object as literal (in string)
ahem .. virtually *any* object.
and read it back. and keep it fairly human readable, and without need to use JSON ;)
i don't mind, if it lends to extra stuff, that's even better :)
[1] http://www.lshift.net/blog/2011/05/15/algebraic-data-types-and-ometa2 (look for "Node>>unapply") [2] http://www.lshift.net/blog/2011/05/31/unification-pattern-matching-but-twice... [3] http://www.lshift.net/blog/2012/01/16/unifying-parts-of-structures
frank
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Hi Igor, I like this very much. When you say:
Object>>#asObjectLiteral to be a subclass responsibility.
I am not convinced this has to be the case. In my opinion, #asObjectLiteral should be a replacement of #storeString. And #storeString is defined on Object and it is not abstract. According to the object you are converting into a string, #storeString may produce code that exceed the amount of literal you can have in a method. Maybe #asObjectLiteral could split the result into chunk that can be individually embedded in a single method. I agree with you that #asObjectLiteral should be overridden. It would be cool to have Class>> asObjectLiteral How large your parser is? Alexandre On Oct 19, 2012, at 8:09 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that).
The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example:
(1@3) asObjectLiteral --> #(#Point 1 3)
{ 1@2. 3@4. true. false . nil } asObjectLiteral
-> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil)
(Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar')
Next thing, you can 'pretty-print' it (kinda):
#(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')'
and sure thing, you can do reverse conversion:
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral
a Dictionary('foo'->'bar' 1->#(1 2 3) )
Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave
Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course.
The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there.
Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project..
So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.
-- Best regards, Igor Stasenko. <ObjectLiterals-IgorStasenko.1.mcz>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 19 October 2012 14:11, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Igor,
I like this very much.
When you say:
Object>>#asObjectLiteral to be a subclass responsibility.
I am not convinced this has to be the case. In my opinion, #asObjectLiteral should be a replacement of #storeString. And #storeString is defined on Object and it is not abstract.
well, it is easy to implement generic one (iterate over all inst vars, and then over all indexable vars, and put them into array.. ) but main point for not providing default one is to make conversion explicit i.e.: - not all objects can be represented as literals - only those, which do, should implement conversion methods. but i agree , this is arguable. As long as you using objects which provide own converters, (so a generic one never takes place), you don't have to worry about it.
According to the object you are converting into a string, #storeString may produce code that exceed the amount of literal you can have in a method. Maybe #asObjectLiteral could split the result into chunk that can be individually embedded in a single method.
not the case. #( whatever (no matter how deeply nested) ) is a _single_ literal.
I agree with you that #asObjectLiteral should be overridden. It would be cool to have Class>> asObjectLiteral
How large your parser is?
if you asking this quesiton, you miss the point totally. there is no parser except smalltalk parser. :) What parser you need to parse: #( Array 1 2 3) ? then i converting it to #(1 2 3) but that is has nothing to do with parsing: Array>>fromObjectLiteral "Convert receiver back from object literal representation. Arrays is always holding a class name as first element, dispatch to the class to perform a conversion " ^ (Smalltalk globals at: self first) fromObjectLiteral: self Collection class>>fromObjectLiteral: objLiteralArray ^ self withAll: (objLiteralArray allButFirst collect: [:each | each fromObjectLiteral ] ) So, if that answering your question, those two methods is 'how large' my parser is :)
Alexandre
On Oct 19, 2012, at 8:09 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that).
The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example:
(1@3) asObjectLiteral --> #(#Point 1 3)
{ 1@2. 3@4. true. false . nil } asObjectLiteral
-> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil)
(Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar')
Next thing, you can 'pretty-print' it (kinda):
#(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')'
and sure thing, you can do reverse conversion:
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral
a Dictionary('foo'->'bar' 1->#(1 2 3) )
Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave
Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course.
The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there.
Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project..
So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.
-- Best regards, Igor Stasenko. <ObjectLiterals-IgorStasenko.1.mcz>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
but i agree , this is arguable. As long as you using objects which provide own converters, (so a generic one never takes place), you don't have to worry about it.
I think this would be interesting
According to the object you are converting into a string, #storeString may produce code that exceed the amount of literal you can have in a method. Maybe #asObjectLiteral could split the result into chunk that can be individually embedded in a single method.
not the case. #( whatever (no matter how deeply nested) ) is a _single_ literal.
he he, that's cool!
How large your parser is?
if you asking this quesiton, you miss the point totally. there is no parser except smalltalk parser. :)
Ya ya.. I was referring to the amount of code to implement this. What about the method #parseAsObjectLiteral? If I understood correctly, the JSON format is rooted in the need to define classes no? Alexandre
What parser you need to parse: #( Array 1 2 3)
? then i converting it to #(1 2 3) but that is has nothing to do with parsing:
Array>>fromObjectLiteral "Convert receiver back from object literal representation. Arrays is always holding a class name as first element, dispatch to the class to perform a conversion "
^ (Smalltalk globals at: self first) fromObjectLiteral: self
Collection class>>fromObjectLiteral: objLiteralArray
^ self withAll: (objLiteralArray allButFirst collect: [:each | each fromObjectLiteral ] )
So, if that answering your question, those two methods is 'how large' my parser is :)
Alexandre
On Oct 19, 2012, at 8:09 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that).
The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example:
(1@3) asObjectLiteral --> #(#Point 1 3)
{ 1@2. 3@4. true. false . nil } asObjectLiteral
-> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil)
(Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar')
Next thing, you can 'pretty-print' it (kinda):
#(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')'
and sure thing, you can do reverse conversion:
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral
a Dictionary('foo'->'bar' 1->#(1 2 3) )
Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave
Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course.
The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there.
Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project..
So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.
-- Best regards, Igor Stasenko. <ObjectLiterals-IgorStasenko.1.mcz>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 19 October 2012 18:36, Alexandre Bergel <alexandre.bergel@me.com> wrote:
but i agree , this is arguable. As long as you using objects which provide own converters, (so a generic one never takes place), you don't have to worry about it.
I think this would be interesting
According to the object you are converting into a string, #storeString may produce code that exceed the amount of literal you can have in a method. Maybe #asObjectLiteral could split the result into chunk that can be individually embedded in a single method.
not the case. #( whatever (no matter how deeply nested) ) is a _single_ literal.
he he, that's cool!
How large your parser is?
if you asking this quesiton, you miss the point totally. there is no parser except smalltalk parser. :)
Ya ya.. I was referring to the amount of code to implement this.
What about the method #parseAsObjectLiteral?
this one just for using smalltalk parser to parse the input string. nothing complicated (except that our existing parser don't have a good API to do that, that's why this code is a bit messy). But still, that code is just parsing (not evaluating anything)..
If I understood correctly, the JSON format is rooted in the need to define classes no?
well, i meant that i don't even need to create any new classes in system to implement that, just couple extension methods here and there. so, it is very lightweight comparing to anything which needs own parser + own classes for that etc. you cannot use dictionaries for representing JS objects because the order of property declaration in them sometimes important, while for smalltalk dictionaries apparently not .
Alexandre
-- Best regards, Igor Stasenko.
Hi Igor, This is a very nice and elegant expression (of a variation) of the Array literal idea. Thanks a lot for taking the effort to implement and share it. I think that a formal specification and a standalone parser that does not depend on the builtin compiler is also needed. That would mean that we have to define all primitive types. Minimally I can see these: - nil - Boolean - Integer - Symbol - Float - String What with escaping unprintable characters ? What with complex symbols ? What with fractions ? What with human readable/writeable representations for Date, Time, DateAndTime ? The classnames currently match one-to-one to classes, in the light of cross dialect compatibility and namespaces a mapping might be needed. Sven PS: provided we can agree and formally define the above, I might be interested in trying to write a parser ;-)
Hi, as i promised before, here the simple smalltalk-based literal format. It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to have separate parser (a normal smalltalk parser used for that).
The idea is quite simple: you can tell any object to represent itself as an 'object literal' , for example:
(1@3) asObjectLiteral --> #(#Point 1 3)
{ 1@2. 3@4. true. false . nil } asObjectLiteral
-> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil)
(Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral -> #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar')
Next thing, you can 'pretty-print' it (kinda):
#(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')'
and sure thing, you can do reverse conversion:
'#(#Dictionary 1 (#Array 1 2 3) ''foo'' ''bar'')' parseAsObjectLiteral
a Dictionary('foo'->'bar' 1->#(1 2 3) )
Initially, i thought that it could be generic (by implementing default Object>>#asObjectLiteral), but then after discussing it with others, we decided to leave
Object>>#asObjectLiteral to be a subclass responsibility. So, potentially the format allows to represent any object(s) as literals, except from circular referencing objects, of course.
The implementation is fairly simple, as you may guess and contains no new classes, but just extension methods here and there.
Take it with grain and salt, since it is just a small proof of concept. (And if doing it for real it may need some changes etc). Since i am far from areas right now, where it can be used, i don't want to pursue it further or advocate if this is the right way to do things. Neither i having a public repository for this project..
So, if there anyone who willing to pick it up and pursue the idea further, please feel free to do so and make a public repository for project.
-- Best regards, Igor Stasenko. <ObjectLiterals-IgorStasenko.1.mcz>
On 19 October 2012 16:31, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Igor,
This is a very nice and elegant expression (of a variation) of the Array literal idea. Thanks a lot for taking the effort to implement and share it.
I think that a formal specification and a standalone parser that does not depend on the builtin compiler is also needed. That would mean that we have to define all primitive types. Minimally I can see these:
- nil - Boolean - Integer - Symbol - Float - String
What with escaping unprintable characters ?
well, this is easy: implement String>>asObjectLiteral to answer 'escaped representation of string' and String>>fromObjectLiteral to unescape it back. so, you probably won't need to bother with escaping in parser (parser will parse human-readable chars)
What with complex symbols ?
like what?
What with fractions ?
just implement conversion methods for it and that's it
What with human readable/writeable representations for Date, Time, DateAndTime ?
same story :)
The classnames currently match one-to-one to classes, in the light of cross dialect compatibility and namespaces a mapping might be needed.
yeah.. but that's not a big deal , right? you can always replace "Smalltalk at: symbol " with something like "Smalltalk at: (ObjectLiteralMapping of: symbol)" or whatever :) and, of course if no class found, you can still play nicely, i.e.: (Smalltalk at: classname ifAbsent: [ ^ ObjectLiteralNoMapping for: literal ] ) (see the implementation of Array>>fromObjectLiteral)
Sven
PS: provided we can agree and formally define the above, I might be interested in trying to write a parser ;-)
:) -- Best regards, Igor Stasenko.
Igor, I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly... The appeal of JSON (and STON) is that the output is readable by mere mortals: (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW... Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |
Dale, We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it ! Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics. Also, we could agree on #(#Time '15:24:01Z') #(#Date '2012-10-19') #(#DateAndTime '2012-10-19T15:24:01Z') with dashed and colons being optional. Sven BTW: Is the # in front of Symbols needed ? On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
The appeal of JSON (and STON) is that the output is readable by mere mortals:
(JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |
On 19 October 2012 17:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Dale,
We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
Also, we could agree on
#(#Time '15:24:01Z') #(#Date '2012-10-19') #(#DateAndTime '2012-10-19T15:24:01Z')
with dashed and colons being optional.
Sven
BTW: Is the # in front of Symbols needed ?
good question.. strict syntax, probably yes.. but array literals allow you to omit it i.e.: #( ( foo ) ) == #( #( #foo) ) -- Best regards, Igor Stasenko.
On 19 October 2012 16:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Dale,
We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
Also, we could agree on
#(#Time '15:24:01Z') #(#Date '2012-10-19') #(#DateAndTime '2012-10-19T15:24:01Z')
with dashed and colons being optional.
Sven
BTW: Is the # in front of Symbols needed ?
No: #(#foo #bar) = #(foo bar) (but it might be a bit of a hack that they are). frank
On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
The appeal of JSON (and STON) is that the output is readable by mere mortals:
(JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |
Sven, Everybody needs a help from a parser to get formated input right ... I rely on sytax highlighting when I write Smalltalk code:), but I'd say the lack of key/value syntax is more than "a bit worse" for readability. I don't spend a lot of time reading/writing STON files but when I do...I read more often than write and with syntactic key/value demarcation I can read a dictionary with reasonable certainty and make minor edits with confidence (with or without formatting help)... with an undifferentiated list of key value pairs ... forget it:), especially when there are much more readable alternatives available. Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven@stfx.eu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 8:29:07 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | Dale, | | We have a web app where users sometimes have to enter some short | pieces of JSON - because we were lazy and did not provide a proper | interface ;-) You wouldn't believe in how many ways they make | syntax errors and don't understand it ! | | Alternating key value elements is not that worse than key:value or | key->value IMO, but it is a bit worse, agreed. The advantage is that | you don't need extra syntax/semantics. | | Also, we could agree on | | #(#Time '15:24:01Z') | #(#Date '2012-10-19') | #(#DateAndTime '2012-10-19T15:24:01Z') | | with dashed and colons being optional. | | Sven | | BTW: Is the # in front of Symbols needed ? | | On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich@vmware.com> wrote: | | > Igor, | > | > I'm afraid that your notation is not very friendly to humans ... a | > computer can keep track of the key value pairs in the literal | > dictionary, but a human will fail very quickly... | > | > The appeal of JSON (and STON) is that the output is readable by | > mere mortals: | > | > (JavaScript Object Notation) is a lightweight | > data-interchange format. It is easy for humans to | > read and write. | > | > What we're missing from Smalltalk is a literal dictionary or | > literal map syntax ... without that I'm afraid that for human | > friendly, lightweight notations we have to step away from the | > Smalltalk syntax - STON does this very nicely BTW... | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | > | Sent: Friday, October 19, 2012 4:09:22 AM | > | Subject: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | Hi, | > | as i promised before, here the simple smalltalk-based literal | > | format. | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | > | needs | > | to | > | have separate parser (a normal smalltalk parser used for that). | > | | > | The idea is quite simple: | > | you can tell any object to represent itself as an 'object | > | literal' , | > | for example: | > | | > | (1@3) asObjectLiteral | > | --> #(#Point 1 3) | > | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | > | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | > | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | > | asObjectLiteral | > | -> | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | | > | Next thing, you can 'pretty-print' it (kinda): | > | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' | > | | > | | > | and sure thing, you can do reverse conversion: | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' parseAsObjectLiteral | > | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | > | | > | Initially, i thought that it could be generic (by implementing | > | default | > | Object>>#asObjectLiteral), | > | but then after discussing it with others, we decided to leave | > | | > | Object>>#asObjectLiteral to be a subclass responsibility. | > | So, potentially the format allows to represent any object(s) as | > | literals, except from circular referencing objects, of course. | > | | > | The implementation is fairly simple, as you may guess and | > | contains no | > | new classes, but just extension methods here and there. | > | | > | Take it with grain and salt, since it is just a small proof of | > | concept. (And if doing it for real it may need some changes etc). | > | Since i am far from areas right now, where it can be used, i | > | don't | > | want to pursue it further or advocate if this is the right way to | > | do | > | things. | > | Neither i having a public repository for this project.. | > | | > | So, if there anyone who willing to pick it up and pursue the idea | > | further, please feel free to do so and make a public repository | > | for | > | project. | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | |
If you guys are all fired up to write parsers:) writing a YAML parser for Smalltalk would be very cool. There are yaml parsers for a bunch of languages, but a Smalltalk parser is conspicuously absent ... YAML is very readable (all the extraneous gibberish has been removed from the syntax)... YAML appears to be the format of choice when humans and computers need to share the data file and would be not only work across dialects... Dale [1] http://www.yaml.org/ ----- Original Message ----- | From: "Dale Henrichs" <dhenrich@vmware.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 8:56:43 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | Sven, | | Everybody needs a help from a parser to get formated input right ... | I rely on sytax highlighting when I write Smalltalk code:), but I'd | say the lack of key/value syntax is more than "a bit worse" for | readability. | | I don't spend a lot of time reading/writing STON files but when I | do...I read more often than write and with syntactic key/value | demarcation I can read a dictionary with reasonable certainty and | make minor edits with confidence (with or without formatting | help)... with an undifferentiated list of key value pairs ... forget | it:), especially when there are much more readable alternatives | available. | | Dale | ----- Original Message ----- | | From: "Sven Van Caekenberghe" <sven@stfx.eu> | | To: Pharo-project@lists.gforge.inria.fr | | Sent: Friday, October 19, 2012 8:29:07 AM | | Subject: Re: [Pharo-project] Yet another Notation format: Object | | literals | | | | Dale, | | | | We have a web app where users sometimes have to enter some short | | pieces of JSON - because we were lazy and did not provide a proper | | interface ;-) You wouldn't believe in how many ways they make | | syntax errors and don't understand it ! | | | | Alternating key value elements is not that worse than key:value or | | key->value IMO, but it is a bit worse, agreed. The advantage is | | that | | you don't need extra syntax/semantics. | | | | Also, we could agree on | | | | #(#Time '15:24:01Z') | | #(#Date '2012-10-19') | | #(#DateAndTime '2012-10-19T15:24:01Z') | | | | with dashed and colons being optional. | | | | Sven | | | | BTW: Is the # in front of Symbols needed ? | | | | On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich@vmware.com> | | wrote: | | | | > Igor, | | > | | > I'm afraid that your notation is not very friendly to humans ... | | > a | | > computer can keep track of the key value pairs in the literal | | > dictionary, but a human will fail very quickly... | | > | | > The appeal of JSON (and STON) is that the output is readable by | | > mere mortals: | | > | | > (JavaScript Object Notation) is a lightweight | | > data-interchange format. It is easy for humans to | | > read and write. | | > | | > What we're missing from Smalltalk is a literal dictionary or | | > literal map syntax ... without that I'm afraid that for human | | > friendly, lightweight notations we have to step away from the | | > Smalltalk syntax - STON does this very nicely BTW... | | > | | > Dale | | > | | > ----- Original Message ----- | | > | From: "Igor Stasenko" <siguctua@gmail.com> | | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | | > | Sent: Friday, October 19, 2012 4:09:22 AM | | > | Subject: [Pharo-project] Yet another Notation format: Object | | > | literals | | > | | | > | Hi, | | > | as i promised before, here the simple smalltalk-based literal | | > | format. | | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | | > | needs | | > | to | | > | have separate parser (a normal smalltalk parser used for that). | | > | | | > | The idea is quite simple: | | > | you can tell any object to represent itself as an 'object | | > | literal' , | | > | for example: | | > | | | > | (1@3) asObjectLiteral | | > | --> #(#Point 1 3) | | > | | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | | > | | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | > | | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | | > | asObjectLiteral | | > | -> | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | > | | | > | Next thing, you can 'pretty-print' it (kinda): | | > | | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' | | > | | | > | | | > | and sure thing, you can do reverse conversion: | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' parseAsObjectLiteral | | > | | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | > | | | > | Initially, i thought that it could be generic (by implementing | | > | default | | > | Object>>#asObjectLiteral), | | > | but then after discussing it with others, we decided to leave | | > | | | > | Object>>#asObjectLiteral to be a subclass responsibility. | | > | So, potentially the format allows to represent any object(s) as | | > | literals, except from circular referencing objects, of course. | | > | | | > | The implementation is fairly simple, as you may guess and | | > | contains no | | > | new classes, but just extension methods here and there. | | > | | | > | Take it with grain and salt, since it is just a small proof of | | > | concept. (And if doing it for real it may need some changes | | > | etc). | | > | Since i am far from areas right now, where it can be used, i | | > | don't | | > | want to pursue it further or advocate if this is the right way | | > | to | | > | do | | > | things. | | > | Neither i having a public repository for this project.. | | > | | | > | So, if there anyone who willing to pick it up and pursue the | | > | idea | | > | further, please feel free to do so and make a public repository | | > | for | | > | project. | | > | | | > | | | > | -- | | > | Best regards, | | > | Igor Stasenko. | | > | | | > | | | | | | |
On 19 October 2012 18:18, Dale Henrichs <dhenrich@vmware.com> wrote:
If you guys are all fired up to write parsers:) writing a YAML parser for Smalltalk would be very cool. There are yaml parsers for a bunch of languages, but a Smalltalk parser is conspicuously absent ...
YAML is very readable (all the extraneous gibberish has been removed from the syntax)... YAML appears to be the format of choice when humans and computers need to share the data file and would be not only work across dialects...
Well, you miss the point then. My point was how we can represent a arbitrary object using smalltalk syntax. That way, users don't need to learn different syntax to express data in different way.. And this notation is not limited only for exchanging data via files.. it has own uses in a language itself! myColors ^ #( Dictionary yellow (Color 1 1 0) blue (Color 0 0 1) red (Color 1 0 0) ) fromObjectLiteral. please note, that it can be even optimized by Compiler! You can easily detect that #fromObjectLiteral is sent to an array literal, so you can perform such conversion at compile time.. which means that given method, when compiled will already contain such literal (like dictionary with colors in the above example) ready for use and no run-time overhead.
Dale
----- Original Message ----- | From: "Dale Henrichs" <dhenrich@vmware.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 8:56:43 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | Sven, | | Everybody needs a help from a parser to get formated input right ... | I rely on sytax highlighting when I write Smalltalk code:), but I'd | say the lack of key/value syntax is more than "a bit worse" for | readability. | | I don't spend a lot of time reading/writing STON files but when I | do...I read more often than write and with syntactic key/value | demarcation I can read a dictionary with reasonable certainty and | make minor edits with confidence (with or without formatting | help)... with an undifferentiated list of key value pairs ... forget | it:), especially when there are much more readable alternatives | available. | | Dale | ----- Original Message ----- | | From: "Sven Van Caekenberghe" <sven@stfx.eu> | | To: Pharo-project@lists.gforge.inria.fr | | Sent: Friday, October 19, 2012 8:29:07 AM | | Subject: Re: [Pharo-project] Yet another Notation format: Object | | literals | | | | Dale, | | | | We have a web app where users sometimes have to enter some short | | pieces of JSON - because we were lazy and did not provide a proper | | interface ;-) You wouldn't believe in how many ways they make | | syntax errors and don't understand it ! | | | | Alternating key value elements is not that worse than key:value or | | key->value IMO, but it is a bit worse, agreed. The advantage is | | that | | you don't need extra syntax/semantics. | | | | Also, we could agree on | | | | #(#Time '15:24:01Z') | | #(#Date '2012-10-19') | | #(#DateAndTime '2012-10-19T15:24:01Z') | | | | with dashed and colons being optional. | | | | Sven | | | | BTW: Is the # in front of Symbols needed ? | | | | On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich@vmware.com> | | wrote: | | | | > Igor, | | > | | > I'm afraid that your notation is not very friendly to humans ... | | > a | | > computer can keep track of the key value pairs in the literal | | > dictionary, but a human will fail very quickly... | | > | | > The appeal of JSON (and STON) is that the output is readable by | | > mere mortals: | | > | | > (JavaScript Object Notation) is a lightweight | | > data-interchange format. It is easy for humans to | | > read and write. | | > | | > What we're missing from Smalltalk is a literal dictionary or | | > literal map syntax ... without that I'm afraid that for human | | > friendly, lightweight notations we have to step away from the | | > Smalltalk syntax - STON does this very nicely BTW... | | > | | > Dale | | > | | > ----- Original Message ----- | | > | From: "Igor Stasenko" <siguctua@gmail.com> | | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | | > | Sent: Friday, October 19, 2012 4:09:22 AM | | > | Subject: [Pharo-project] Yet another Notation format: Object | | > | literals | | > | | | > | Hi, | | > | as i promised before, here the simple smalltalk-based literal | | > | format. | | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | | > | needs | | > | to | | > | have separate parser (a normal smalltalk parser used for that). | | > | | | > | The idea is quite simple: | | > | you can tell any object to represent itself as an 'object | | > | literal' , | | > | for example: | | > | | | > | (1@3) asObjectLiteral | | > | --> #(#Point 1 3) | | > | | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | | > | | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | > | | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | | > | asObjectLiteral | | > | -> | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | > | | | > | Next thing, you can 'pretty-print' it (kinda): | | > | | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' | | > | | | > | | | > | and sure thing, you can do reverse conversion: | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' parseAsObjectLiteral | | > | | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | > | | | > | Initially, i thought that it could be generic (by implementing | | > | default | | > | Object>>#asObjectLiteral), | | > | but then after discussing it with others, we decided to leave | | > | | | > | Object>>#asObjectLiteral to be a subclass responsibility. | | > | So, potentially the format allows to represent any object(s) as | | > | literals, except from circular referencing objects, of course. | | > | | | > | The implementation is fairly simple, as you may guess and | | > | contains no | | > | new classes, but just extension methods here and there. | | > | | | > | Take it with grain and salt, since it is just a small proof of | | > | concept. (And if doing it for real it may need some changes | | > | etc). | | > | Since i am far from areas right now, where it can be used, i | | > | don't | | > | want to pursue it further or advocate if this is the right way | | > | to | | > | do | | > | things. | | > | Neither i having a public repository for this project.. | | > | | | > | So, if there anyone who willing to pick it up and pursue the | | > | idea | | > | further, please feel free to do so and make a public repository | | > | for | | > | project. | | > | | | > | | | > | -- | | > | Best regards, | | > | Igor Stasenko. | | > | | | > | | | | | | |
-- Best regards, Igor Stasenko.
Dale Henrichs wrote
If you guys are all fired up to write parsers:) writing a YAML parser for Smalltalk would be very cool. There are yaml parsers for a bunch of languages, but a Smalltalk parser is conspicuously absent ...
YAML is very readable (all the extraneous gibberish has been removed from the syntax)... YAML appears to be the format of choice when humans and computers need to share the data file and would be not only work across dialects...
Dale
Oh yes, YAML parser/writer is dearly really missing. Text format should be readable, if not, give me serialized byte stream please. And by readable, I think readable by any user of software written in Smalltalk, not the Smalltalk programmer himself. As for executing file format without parsing it and interpreting it - funny how this bad idea finds its way to reappear so many times in spite of how many people got burned with it. ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/Yet-another-Notation-format-Object-literals-tp4651943p... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 19 October 2012 17:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Dale,
We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
Also, we could agree on
#(#Time '15:24:01Z')
and if you care about human-friendly stuff, who needs quotes? #(Time 15:24:01 GMT) is valid smalltalk syntax: #(#Time 15 #':' 24 #':' 1 #GMT) you only need to provide a conversion which is clever enough to convert this literal into proper instance of Time :)
#(#Date '2012-10-19') #(#DateAndTime '2012-10-19T15:24:01Z')
with dashed and colons being optional.
Sven
BTW: Is the # in front of Symbols needed ?
On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
The appeal of JSON (and STON) is that the output is readable by mere mortals:
(JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |
-- Best regards, Igor Stasenko.
On Oct 19, 2012, at 5:29 PM, Sven Van Caekenberghe wrote:
Dale,
We have a web app where users sometimes have to enter some short pieces of JSON - because we were lazy and did not provide a proper interface ;-) You wouldn't believe in how many ways they make syntax errors and don't understand it !
Alternating key value elements is not that worse than key:value or key->value IMO, but it is a bit worse, agreed. The advantage is that you don't need extra syntax/semantics.
yes :)
Also, we could agree on
#(#Time '15:24:01Z') #(#Date '2012-10-19') #(#DateAndTime '2012-10-19T15:24:01Z')
with dashed and colons being optional.
Sven
BTW: Is the # in front of Symbols needed ?
no
On 19 Oct 2012, at 16:55, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
The appeal of JSON (and STON) is that the output is readable by mere mortals:
(JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |
On 19 October 2012 16:55, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
The appeal of JSON (and STON) is that the output is readable by mere mortals:
(JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
no problem, Dale. What symbol you want to have to separate keys from values? is '->' ok? Dictionary>>asObjectLiteral "convert a receiver into an object literal " ^ Array streamContents: [:stream | stream nextPut: self class name. self keysAndValuesDo: [:key :value | stream nextPut: key asObjectLiteral; nextPut: #->; nextPut: value asObjectLiteral ] ] (Dictionary newFromPairs: #( a b c d)) asObjectLiteral #(#Dictionary #a #'->' #b #c #'->' #d) which if you pretty-print will look like: #( Dictionary a -> b c -> d ) is it better? or you prefer this one: #( Dictionary (a -> b) (c -> d) ) you can do anything you like, by implementing the conversion methods in a way you like :)
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |
-- Best regards, Igor Stasenko.
On 19 October 2012 18:10, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 October 2012 16:55, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I'm afraid that your notation is not very friendly to humans ... a computer can keep track of the key value pairs in the literal dictionary, but a human will fail very quickly...
The appeal of JSON (and STON) is that the output is readable by mere mortals:
(JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
What we're missing from Smalltalk is a literal dictionary or literal map syntax ... without that I'm afraid that for human friendly, lightweight notations we have to step away from the Smalltalk syntax - STON does this very nicely BTW...
no problem, Dale. What symbol you want to have to separate keys from values? is '->' ok?
Dictionary>>asObjectLiteral
"convert a receiver into an object literal "
^ Array streamContents: [:stream | stream nextPut: self class name. self keysAndValuesDo: [:key :value | stream nextPut: key asObjectLiteral; nextPut: #->; nextPut: value asObjectLiteral ] ]
(Dictionary newFromPairs: #( a b c d)) asObjectLiteral
#(#Dictionary #a #'->' #b #c #'->' #d)
which if you pretty-print will look like:
#( Dictionary a -> b c -> d )
is it better?
and, of course you can even put a delimiter(s): #( Dictionary a -> b. c -> d. ) or #( Dictionary a -> b; c -> d; ) or: #( Dictionary { a -> b }; { c -> d }; ) ->> #(#Dictionary #'{' #a #'->' #b #'}' #';' #'{' #c #'->' #d #'}' #';') this is completely arbitrary... because smalltalk literal syntax is highly permissive :) it only a little more work to extract keys and values from already parsed literal array.
or you prefer this one:
#( Dictionary (a -> b) (c -> d) )
you can do anything you like, by implementing the conversion methods in a way you like :)
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 4:09:22 AM | Subject: [Pharo-project] Yet another Notation format: Object literals | | Hi, | as i promised before, here the simple smalltalk-based literal format. | It based on smalltalk syntax, and so, unlike JSON, it doesn't needs | to | have separate parser (a normal smalltalk parser used for that). | | The idea is quite simple: | you can tell any object to represent itself as an 'object literal' , | for example: | | (1@3) asObjectLiteral | --> #(#Point 1 3) | | { 1@2. 3@4. true. false . nil } asObjectLiteral | | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | asObjectLiteral | -> | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | Next thing, you can 'pretty-print' it (kinda): | | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' | | | and sure thing, you can do reverse conversion: | | '#(#Dictionary | 1 | (#Array 1 2 3) | ''foo'' ''bar'')' parseAsObjectLiteral | | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | Initially, i thought that it could be generic (by implementing | default | Object>>#asObjectLiteral), | but then after discussing it with others, we decided to leave | | Object>>#asObjectLiteral to be a subclass responsibility. | So, potentially the format allows to represent any object(s) as | literals, except from circular referencing objects, of course. | | The implementation is fairly simple, as you may guess and contains no | new classes, but just extension methods here and there. | | Take it with grain and salt, since it is just a small proof of | concept. (And if doing it for real it may need some changes etc). | Since i am far from areas right now, where it can be used, i don't | want to pursue it further or advocate if this is the right way to do | things. | Neither i having a public repository for this project.. | | So, if there anyone who willing to pick it up and pursue the idea | further, please feel free to do so and make a public repository for | project. | | | -- | Best regards, | Igor Stasenko. |
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Igor, "you can do anything you like" ... you mean like choosing to use STON and not invent my own notation format? STON is a perfectly good notation format for Smalltalk... Methinks that with your recent suggestions are no longer using literal Smalltalk syntax which is fine, if we are not restricted to literal Smalltalk syntax, then the following should be a valid format: { "category" : "Topez-Client-Core", "classinstvars" : [ ], "classvars" : [ ], "commentStamp" : "", "instvars" : [ "project", "package", "currentClass", "classOrInstance", "category", "selector", "history", "currentWindowId", "windows", "namedWindows" ], "name" : "TZTopezStatus", "pools" : [ ], "super" : "Object", "type" : "normal" } which brings us back to were we started. Smalltalk does not have a literal syntax for dictionaries. While fabricating dictionaries from literal arrays is possible, the results are not very readable ... unless you start taking liberties with Smalltalk syntax... If you are no longer restricting yourself to Smalltalk syntax, then what's wrong with the STON notation above? Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 9:10:26 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 16:55, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > I'm afraid that your notation is not very friendly to humans ... a | > computer can keep track of the key value pairs in the literal | > dictionary, but a human will fail very quickly... | > | > The appeal of JSON (and STON) is that the output is readable by | > mere mortals: | > | > (JavaScript Object Notation) is a lightweight | > data-interchange format. It is easy for humans to | > read and write. | > | > What we're missing from Smalltalk is a literal dictionary or | > literal map syntax ... without that I'm afraid that for human | > friendly, lightweight notations we have to step away from the | > Smalltalk syntax - STON does this very nicely BTW... | | no problem, Dale. | What symbol you want to have to separate keys from values? | is '->' ok? | | Dictionary>>asObjectLiteral | | "convert a receiver into an object literal " | | ^ Array streamContents: [:stream | | stream nextPut: self class name. | self keysAndValuesDo: [:key :value | | stream | nextPut: key asObjectLiteral; | nextPut: #->; | nextPut: value asObjectLiteral ] ] | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | | #(#Dictionary | #a #'->' #b | #c #'->' #d) | | which if you pretty-print will look like: | | #( | Dictionary | a -> b | c -> d | ) | | is it better? | or you prefer this one: | | #( | Dictionary | (a -> b) | (c -> d) | ) | | you can do anything you like, by implementing the conversion methods | in a way you like :) | | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | > | Sent: Friday, October 19, 2012 4:09:22 AM | > | Subject: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | Hi, | > | as i promised before, here the simple smalltalk-based literal | > | format. | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | > | needs | > | to | > | have separate parser (a normal smalltalk parser used for that). | > | | > | The idea is quite simple: | > | you can tell any object to represent itself as an 'object | > | literal' , | > | for example: | > | | > | (1@3) asObjectLiteral | > | --> #(#Point 1 3) | > | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | > | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | > | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | > | asObjectLiteral | > | -> | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | | > | Next thing, you can 'pretty-print' it (kinda): | > | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' | > | | > | | > | and sure thing, you can do reverse conversion: | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' parseAsObjectLiteral | > | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | > | | > | Initially, i thought that it could be generic (by implementing | > | default | > | Object>>#asObjectLiteral), | > | but then after discussing it with others, we decided to leave | > | | > | Object>>#asObjectLiteral to be a subclass responsibility. | > | So, potentially the format allows to represent any object(s) as | > | literals, except from circular referencing objects, of course. | > | | > | The implementation is fairly simple, as you may guess and | > | contains no | > | new classes, but just extension methods here and there. | > | | > | Take it with grain and salt, since it is just a small proof of | > | concept. (And if doing it for real it may need some changes etc). | > | Since i am far from areas right now, where it can be used, i | > | don't | > | want to pursue it further or advocate if this is the right way to | > | do | > | things. | > | Neither i having a public repository for this project.. | > | | > | So, if there anyone who willing to pick it up and pursue the idea | > | further, please feel free to do so and make a public repository | > | for | > | project. | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | | | -- | Best regards, | Igor Stasenko. | |
On 19 October 2012 18:33, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
"you can do anything you like" ... you mean like choosing to use STON and not invent my own notation format?
STON is a perfectly good notation format for Smalltalk...
Methinks that with your recent suggestions are no longer using literal Smalltalk syntax which is fine, if we are not restricted to literal Smalltalk syntax, then the following should be a valid format:
{ "category" : "Topez-Client-Core", "classinstvars" : [ ], "classvars" : [ ], "commentStamp" : "", "instvars" : [ "project", "package", "currentClass", "classOrInstance", "category", "selector", "history", "currentWindowId", "windows", "namedWindows" ], "name" : "TZTopezStatus", "pools" : [ ], "super" : "Object", "type" : "normal" }
which brings us back to were we started.
Smalltalk does not have a literal syntax for dictionaries. While fabricating dictionaries from literal arrays is possible, the results are not very readable ... unless you start taking liberties with Smalltalk syntax...
why liberties? if smalltalk parser can chew such expression without syntax errors, then what is difference? please note, that STON above cannot be parsed by smalltalk parser , because anything is double quotes "" treated as comment.. it is mainly about reusing what we already have.. If it just about 'create a best human-friendly notation format, no matter what' then neither STON nor JSON is not nearly closer to that. But my aims is slightly different.
If you are no longer restricting yourself to Smalltalk syntax, then what's wrong with the STON notation above?
Dale
-- Best regards, Igor Stasenko.
Igor, "But my aims is slightly different." and so are mine ... I think that we can agree on this point and move on... Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 9:40:40 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 18:33, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > "you can do anything you like" ... you mean like choosing to use | > STON and not invent my own notation format? | > | > STON is a perfectly good notation format for Smalltalk... | > | > Methinks that with your recent suggestions are no longer using | > literal Smalltalk syntax which is fine, if we are not restricted | > to literal Smalltalk syntax, then the following should be a valid | > format: | > | > { | > "category" : "Topez-Client-Core", | > "classinstvars" : [ | > ], | > "classvars" : [ | > ], | > "commentStamp" : "", | > "instvars" : [ | > "project", | > "package", | > "currentClass", | > "classOrInstance", | > "category", | > "selector", | > "history", | > "currentWindowId", | > "windows", | > "namedWindows" ], | > "name" : "TZTopezStatus", | > "pools" : [ | > ], | > "super" : "Object", | > "type" : "normal" } | > | > which brings us back to were we started. | > | > Smalltalk does not have a literal syntax for dictionaries. While | > fabricating dictionaries from literal arrays is possible, the | > results are not very readable ... unless you start taking | > liberties with Smalltalk syntax... | > | | why liberties? | if smalltalk parser can chew such expression without syntax errors, | then what is difference? | please note, that STON above cannot be parsed by smalltalk parser , | because anything is double quotes "" | treated as comment.. | | it is mainly about reusing what we already have.. | If it just about 'create a best human-friendly notation format, no | matter what' then neither STON nor JSON | is not nearly closer to that. | But my aims is slightly different. | | > If you are no longer restricting yourself to Smalltalk syntax, then | > what's wrong with the STON notation above? | > | > Dale | > | -- | Best regards, | Igor Stasenko. | |
On 19 October 2012 18:47, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
"But my aims is slightly different." and so are mine ...
I think that we can agree on this point and move on...
:) i cannot agree on one point: JSON is harder to read to me, comparing to smalltalk literal syntax. This is a reason for dismissing 'human friendliness' comparison, because it is very subjective :) But what i want to repeat: uniformity has the value. When users, to read code, need to know single language, it is better than need to know 2 , 3 or more. So, unless there is no way to express meta (and other) information using same language, only then i won't argue why we need to use different language for information we store. A good example where you cannot do that is C projects, which contain makefiles, config files , and other. Out of curiosity, can you read this (exert from configure script): as_fn_mkdir_p () { case $as_dir in #( -*) as_dir=./$as_dir;; esac test -d "$as_dir" || eval $as_mkdir_p || { as_dirs= while :; do case $as_dir in #( *\'*) as_qdir=`$as_echo "$as_dir" | sed "s/'/'\\\\\\\\''/g"`;; #'( *) as_qdir=$as_dir;; esac as_dirs="'$as_qdir' $as_dirs" as_dir=`$as_dirname -- "$as_dir" || $as_expr X"$as_dir" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \ X"$as_dir" : 'X\(//\)[^/]' \| \ X"$as_dir" : 'X\(//\)$' \| \ X"$as_dir" : 'X\(/\)' \| . 2>/dev/null || $as_echo X"$as_dir" | sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/ q } /^X\(\/\/\)[^/].*/{ s//\1/ q } /^X\(\/\/\)$/{ s//\1/ q } /^X\(\/\).*/{ s//\1/ q } ..... as to me if we take negative infinity , and then raise it to power of positive infinity, then it will be close to "human readability" of this code. But C guys have no choice: they cannot express metainformation in C.. (or just too lazy).. But with smalltalk, we can. So why we need to use weird syntax, and weird DSLs, if we can just keep using smalltalk, and benefit (greatly) from uniformity and simplicity it has? Remember the turtles? They have to go all the way down :) -- Best regards, Igor Stasenko.
Igor, I think we can agree that readability is subjective, beyond that I'm afraid that we aren't going to see eye to eye. Put us in the same room with a whiteboard and we might be able to understand each other's perspective if not come to see eye to eye. Separated by thousands of miles...the best we can hope for is to agree to disagree. Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 12:43:33 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 18:47, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > "But my aims is slightly different." and so are mine ... | > | > I think that we can agree on this point and move on... | > | :) | | i cannot agree on one point: JSON is harder to read to me, comparing | to smalltalk literal syntax. | This is a reason for dismissing 'human friendliness' comparison, | because it is very subjective :) | | But what i want to repeat: uniformity has the value. | When users, to read code, need to know single language, it is better | than need to know 2 , 3 or more. | So, unless there is no way to express meta (and other) information | using same language, only then i won't argue why we need to use | different language for information we store. | A good example where you cannot do that is C projects, which contain | makefiles, config files , and other. | | Out of curiosity, can you read this (exert from configure script): | | as_fn_mkdir_p () | { | | case $as_dir in #( | -*) as_dir=./$as_dir;; | esac | test -d "$as_dir" || eval $as_mkdir_p || { | as_dirs= | while :; do | case $as_dir in #( | *\'*) as_qdir=`$as_echo "$as_dir" | sed "s/'/'\\\\\\\\''/g"`;; | #'( | *) as_qdir=$as_dir;; | esac | as_dirs="'$as_qdir' $as_dirs" | as_dir=`$as_dirname -- "$as_dir" || | $as_expr X"$as_dir" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \ | X"$as_dir" : 'X\(//\)[^/]' \| \ | X"$as_dir" : 'X\(//\)$' \| \ | X"$as_dir" : 'X\(/\)' \| . 2>/dev/null || | $as_echo X"$as_dir" | | sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ | s//\1/ | q | } | /^X\(\/\/\)[^/].*/{ | s//\1/ | q | } | /^X\(\/\/\)$/{ | s//\1/ | q | } | /^X\(\/\).*/{ | s//\1/ | q | } | | ..... | | as to me if we take negative infinity , and then raise it to power of | positive infinity, | then it will be close to "human readability" of this code. | | But C guys have no choice: they cannot express metainformation in C.. | (or just too lazy).. | But with smalltalk, we can. So why we need to use weird syntax, and | weird DSLs, if we can just keep using smalltalk, and benefit | (greatly) | from uniformity and simplicity it has? | Remember the turtles? They have to go all the way down :) | | -- | Best regards, | Igor Stasenko. | |
On 19 October 2012 22:15, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
I think we can agree that readability is subjective, beyond that I'm afraid that we aren't going to see eye to eye.
Put us in the same room with a whiteboard and we might be able to understand each other's perspective if not come to see eye to eye.
Separated by thousands of miles...the best we can hope for is to agree to disagree.
For me it is important for discussion to have decision point, a way to go. If discussion ends with just "we disagree" this is useless discussion then, and we just losing time here. One of the decisions, we got is that Sven will take an effort implementing that. So, we have a practical outcome. Which is best one i ever expected. :) This is matters. And whether we agree or disagree it doesn't :) We can disagree on zillions of things (and this is good btw), but when people joining forces to develop something together, they should come to some agreement otherwise they will be unable to even start doing anything :)
Dale
-- Best regards, Igor Stasenko.
Igor, It's not clear that I need to be part of this discussion. If you want to invent a new serialization format, then go for it. I did chime in with my opinion that your suggested format was not very readable. You happen to disagree with me. That's fine. I also mentioned that YAML is a standard format that is designed to be very readable by humans while still being parsable by a machine. You told me that I was missing the point. That's fine. You told me that the point is that you can encode arbitrary objects in literal arrays and that this representation is optimizable by the compiler. That's nice, but it is still not readable by humans (in my opinion) and I don't want to involve the compiler ... I don't want to execute code directly from the repository - I want to insert a parser, so that we have control over the code that gets executed. Obviously the goals that you have for this notation do not match up with the requirements that I have. That's fine. I am not in dire need of "yet another Notation format". STON adequately fills the bill for what I need at the moment. I have responded to Eliot with more detail about why I consider JSON to be more readable than your original suggestion. I haven't commented on the readability of your other suggestions because I am assuming that you don't have code written to actually parse the different variations that you proposed. Sooo, it's not clear that I can contribute much more. Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 2:11:37 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 22:15, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > I think we can agree that readability is subjective, beyond that | > I'm afraid that we aren't going to see eye to eye. | > | > Put us in the same room with a whiteboard and we might be able to | > understand each other's perspective if not come to see eye to eye. | > | > Separated by thousands of miles...the best we can hope for is to | > agree to disagree. | > | | For me it is important for discussion to have decision point, a way | to go. | If discussion ends with just "we disagree" this is useless discussion | then, and we just losing time here. | | One of the decisions, we got is that Sven will take an effort | implementing that. | So, we have a practical outcome. Which is best one i ever expected. | :) | This is matters. And whether we agree or disagree it doesn't :) | | We can disagree on zillions of things (and this is good btw), but | when | people joining forces to develop something together, | they should come to some agreement otherwise they will be unable to | even start doing anything :) | | > Dale | | | -- | Best regards, | Igor Stasenko. | |
On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
It's not clear that I need to be part of this discussion.
If you want to invent a new serialization format, then go for it.
I did chime in with my opinion that your suggested format was not very readable. You happen to disagree with me.
Yes, i disagree. Tell me what is not readable in this: #( Dictionary yellow (Color 1 1 0) blue (Color 0 0 1) red (Color 1 0 0) ) fromObjectLiteral. this is human-written object literal. It took me very little effort to express correctly the data structure i need to get out of it, with little chance of doing some syntax mistake. For smalltalker, like me, i find this expression is natural and straightforward to read. And do not discount the environment where people working in: it is smalltalk. So, even if i not understand what is inside, i can always select that piece of code and press Cmd-I to inspect it (or explore it) and then i will see everything very clear :) As well, as you can do reverse: you can craft a complex thingy, and then send #asObjectLiteral and after some prettyfying, you can make it clearly readable. (not mentioning that you can of course pretty-print it automatically). While with JSON, if you evaluate json code in JS, you will get same JSON as response.. which is cool, because of invariant, but won't make it easier to understand by any bit.
That's fine.
I also mentioned that YAML is a standard format that is designed to be very readable by humans while still being parsable by a machine. You told me that I was missing the point.
yes, because my intent was to use smalltalk syntax (so that we reusing existing codebase, and keep uniformity, which is also important).
That's fine.
You told me that the point is that you can encode arbitrary objects in literal arrays and that this representation is optimizable by the compiler.
right, but that's a side effect (which i discovered discussing here btw). I didn't had that in mind nor putting that as a requirement of design. Still, admit, that this side effect is quite nice :)
That's nice, but it is still not readable by humans (in my opinion) and I don't want to involve the compiler ... I don't want to execute code directly from the repository - I want to insert a parser, so that we have control over the code that gets executed.
i know. But my implementation does not evaluating any new code: it just parses the input and transforms it into objects. It doesn't installs new behavior to system. If you don't trust me, you're free to debug the code to see what it does.
Obviously the goals that you have for this notation do not match up with the requirements that I have.
my goal is just one: use smalltalk syntax to express data. If you take smalltalker who knows smalltalk and nothing else, i think he will learn to read that notation much faster comparing to learning JSON/STON/YAML first. Because it is already smalltalk and needs just a slight shift in POV to see through braces. That's the main point.
That's fine.
I am not in dire need of "yet another Notation format". STON adequately fills the bill for what I need at the moment.
I have responded to Eliot with more detail about why I consider JSON to be more readable than your original suggestion. I haven't commented on the readability of your other suggestions because I am assuming that you don't have code written to actually parse the different variations that you proposed.
Sooo, it's not clear that I can contribute much more.
Dale i value your contribution. You know we can criticize and fight to death. But when i demonstrated that you can use #( Dictionary a -> b) instead of #( Dictionary a b) notation, i actually wanted your input from different perspective: if we going to introduce a smalltalk-based notation (one that using smalltalk syntax), is proposed variant good enough, or there can be alternative(s), which may be better than proposed. As i said, i didn't wanted to contrast it with JSON, and derail the whole thing into fight between camps with zero value for community.
Dale
-- Best regards, Igor Stasenko.
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:46:47 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > It's not clear that I need to be part of this discussion. | > | > If you want to invent a new serialization format, then go for it. | > | > I did chime in with my opinion that your suggested format was not | > very readable. You happen to disagree with me. | > | | Yes, i disagree. Tell me what is not readable in this: | | #( Dictionary | | yellow (Color 1 1 0) | blue (Color 0 0 1) | red (Color 1 0 0) | | ) fromObjectLiteral. Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format... | | this is human-written object literal. It took me very little effort | to | express correctly the data structure i need to get out of it, with | little chance of doing some syntax mistake. | For smalltalker, like me, i find this expression is natural and | straightforward to read. I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though. It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so: (Color 1 1 0) tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ... | | And do not discount the environment where people working in: it is | smalltalk. | So, even if i not understand what is inside, i can always select that | piece of code and press Cmd-I | to inspect it (or explore it) and then i will see everything very | clear :) except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ... | | As well, as you can do reverse: you can craft a complex thingy, and | then send #asObjectLiteral | and after some prettyfying, you can make it clearly readable. (not | mentioning that you can of course | pretty-print it automatically). | | While with JSON, if you evaluate json code in JS, you will get same | JSON as response.. | which is cool, because of invariant, but won't make it easier to | understand by any bit. | | > That's fine. | > | > I also mentioned that YAML is a standard format that is designed to | > be very readable by humans while still being parsable by a | > machine. You told me that I was missing the point. | > | yes, because my intent was to use smalltalk syntax (so that we | reusing | existing codebase, and keep uniformity, which is also important). | | > That's fine. | > | > You told me that the point is that you can encode arbitrary objects | > in literal arrays and that this representation is optimizable by | > the compiler. | > | | right, but that's a side effect (which i discovered discussing here | btw). I didn't had that in mind nor putting that as a requirement of | design. Still, admit, that this side effect is quite nice :) | | > That's nice, but it is still not readable by humans (in my opinion) | > and I don't want to involve the compiler ... I don't want to | > execute code directly from the repository - I want to insert a | > parser, so that we have control over the code that gets executed. | | i know. But my implementation does not evaluating any new code: it | just parses the input and transforms it into objects. It doesn't | installs new behavior to system. If you don't trust me, you're free | to | debug the code to see what it does. | | | > | > Obviously the goals that you have for this notation do not match up | > with the requirements that I have. | > | | my goal is just one: use smalltalk syntax to express data. | If you take smalltalker who knows smalltalk and nothing else, i think | he will learn to read that notation much faster comparing to learning | JSON/STON/YAML first. | Because it is already smalltalk and needs just a slight shift in POV | to see through braces. | That's the main point. Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve. The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ... You create a literal dictionary/object syntax for Smalltalk and you might have a convert. | | > That's fine. | > | > I am not in dire need of "yet another Notation format". STON | > adequately fills the bill for what I need at the moment. | > | > I have responded to Eliot with more detail about why I consider | > JSON to be more readable than your original suggestion. I haven't | > commented on the readability of your other suggestions because I | > am assuming that you don't have code written to actually parse the | > different variations that you proposed. | > | > Sooo, it's not clear that I can contribute much more. | > | | Dale i value your contribution. You know we can criticize and fight | to death. | But when i demonstrated that you can use | #( Dictionary a -> b) | instead of | #( Dictionary a b) | notation, i actually wanted your input from different perspective: | if we going to introduce a smalltalk-based notation (one that using | smalltalk syntax), | is proposed variant good enough, or there can be alternative(s), | which | may be better than proposed. | As i said, i didn't wanted to contrast it with JSON, and derail the | whole thing into fight between camps | with zero value for community. Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here. I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured... Dale
On 20 October 2012 03:48, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:46:47 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > It's not clear that I need to be part of this discussion. | > | > If you want to invent a new serialization format, then go for it. | > | > I did chime in with my opinion that your suggested format was not | > very readable. You happen to disagree with me. | > | | Yes, i disagree. Tell me what is not readable in this: | | #( Dictionary | | yellow (Color 1 1 0) | blue (Color 0 0 1) | red (Color 1 0 0) | | ) fromObjectLiteral.
Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format...
yes, because i do not regarding them as significant.
| | this is human-written object literal. It took me very little effort | to | express correctly the data structure i need to get out of it, with | little chance of doing some syntax mistake. | For smalltalker, like me, i find this expression is natural and | straightforward to read.
I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though.
It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so:
(Color 1 1 0)
tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ...
But this is what conventions for (and conversions written to conform with conventions). I do not see a big problem here. Second, (and that's one of the reasons for not implementing generic Object>>asObjectLiteral), you can allow conversion only for certain set of classes, Point, Number, Collection(s) etc, i.e. the ones which has ~0 chance of changing shape/representation. Like in case of dictionary, we do not reflecting the shape of this class directly i.e. (tally and array ivars), but rather reflecting its data-structure, so internal representation is not very important there and hence ca be made highly portable across dialects. Third, if you are not familiar with Color , as long as you won't start using it in some of your project(s), i cannot see what should happen to make (Color 1 0 0) appear in the data what you dealing with in your projects.
From other side, for other person(s) it could be very important for them to be able to serialize colors. So they will be using it , but in their own project(s). Now since you never cross roads, i do not see how you can have any issues with that: it is not your data, therefore not your headache.
Fourth, take CSS , for example. they having three ways defining color: #rrggbb #rgb or rgb(r,g,b) and same thing, as you may guess #75927 notation means nothing for somebody who not familiar with CSS. (he may also make a wild guess, maybe it is cyn? who knows.. ;) ) So, if you don't like (Color 1 0 0) nothing prevents you from denoting colors in more explicit way, like: (RGBColor 1 0 0) or (RGB 1 0 0) or (Color r 1 g 0 b 0 alpha 0) or whatever you see fit. In this notation use of class names is just a cheap and fast way to for denoting the stored object. With some little code, you can use arbitrary "type name" for denoting that, it is just your responsibility to recognize it and represent it with proper object at the end. But notation form don't needs to be altered, is will still stay (<data type name> <values>) and still smalltalk syntax.
| | And do not discount the environment where people working in: it is | smalltalk. | So, even if i not understand what is inside, i can always select that | piece of code and press Cmd-I | to inspect it (or explore it) and then i will see everything very | clear :)
except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ...
in addition to my above comment: if your goal to make data dialect neutral, you making sure it is dialect neutral (no magic ;) , either by avoiding using non-compatible data structures, or represent them in a dialect-neutral way. Look what we actually doing with JSON: since in smalltalk we can't have native representation of JS object, we representing it with surrogate (either dictionary or instance of JSONObject class etc).
| | As well, as you can do reverse: you can craft a complex thingy, and | then send #asObjectLiteral | and after some prettyfying, you can make it clearly readable. (not | mentioning that you can of course | pretty-print it automatically). | | While with JSON, if you evaluate json code in JS, you will get same | JSON as response.. | which is cool, because of invariant, but won't make it easier to | understand by any bit. | | > That's fine. | > | > I also mentioned that YAML is a standard format that is designed to | > be very readable by humans while still being parsable by a | > machine. You told me that I was missing the point. | > | yes, because my intent was to use smalltalk syntax (so that we | reusing | existing codebase, and keep uniformity, which is also important). | | > That's fine. | > | > You told me that the point is that you can encode arbitrary objects | > in literal arrays and that this representation is optimizable by | > the compiler. | > | | right, but that's a side effect (which i discovered discussing here | btw). I didn't had that in mind nor putting that as a requirement of | design. Still, admit, that this side effect is quite nice :) | | > That's nice, but it is still not readable by humans (in my opinion) | > and I don't want to involve the compiler ... I don't want to | > execute code directly from the repository - I want to insert a | > parser, so that we have control over the code that gets executed. | | i know. But my implementation does not evaluating any new code: it | just parses the input and transforms it into objects. It doesn't | installs new behavior to system. If you don't trust me, you're free | to | debug the code to see what it does. | | | > | > Obviously the goals that you have for this notation do not match up | > with the requirements that I have. | > | | my goal is just one: use smalltalk syntax to express data. | If you take smalltalker who knows smalltalk and nothing else, i think | he will learn to read that notation much faster comparing to learning | JSON/STON/YAML first. | Because it is already smalltalk and needs just a slight shift in POV | to see through braces. | That's the main point.
Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve.
The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ...
You create a literal dictionary/object syntax for Smalltalk and you might have a convert.
In that case, i think , better would be to stay with STON then. Dictionaries is quite complex data structure, comparing to lists (arrays) and basic values (numbers, strings and symbols). How many other languages, apart from JS, has syntax to denote dictionary-like structures? I do not see a need in having separate syntax for dictionary. Because this goes to nowhere in form of never-ending story: - tomorrow i want syntactic sugar for Sets - then for Colors - then for Points, Rectangles and Circles ... - and Pink Elephants one of the reasons, why i like smalltalk syntax, is small grammar, minimal syntactic constructs, yet high expressive power. Smalltalk (and LISP) is a good demonstration that massive set of different syntax sugars/rules and expressive power are not correlating values. If you think otherwise, i think you better start using Perl instead, where you can find sugars everywhere and will find that you can write same expression using infinite number of ways, up to the point that it is no longer possible to understand the code which you didn't wrote yourself.
| | > That's fine. | > | > I am not in dire need of "yet another Notation format". STON | > adequately fills the bill for what I need at the moment. | > | > I have responded to Eliot with more detail about why I consider | > JSON to be more readable than your original suggestion. I haven't | > commented on the readability of your other suggestions because I | > am assuming that you don't have code written to actually parse the | > different variations that you proposed. | > | > Sooo, it's not clear that I can contribute much more. | > | | Dale i value your contribution. You know we can criticize and fight | to death. | But when i demonstrated that you can use | #( Dictionary a -> b) | instead of | #( Dictionary a b) | notation, i actually wanted your input from different perspective: | if we going to introduce a smalltalk-based notation (one that using | smalltalk syntax), | is proposed variant good enough, or there can be alternative(s), | which | may be better than proposed. | As i said, i didn't wanted to contrast it with JSON, and derail the | whole thing into fight between camps | with zero value for community.
Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here.
I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured...
I think this don't needs additional comment(s) from me, since i answered to them above.
Dale
-- Best regards, Igor Stasenko.
On 20 October 2012 04:13, Igor Stasenko <siguctua@gmail.com> wrote:
On 20 October 2012 03:48, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:46:47 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > It's not clear that I need to be part of this discussion. | > | > If you want to invent a new serialization format, then go for it. | > | > I did chime in with my opinion that your suggested format was not | > very readable. You happen to disagree with me. | > | | Yes, i disagree. Tell me what is not readable in this: | | #( Dictionary | | yellow (Color 1 1 0) | blue (Color 0 0 1) | red (Color 1 0 0) | | ) fromObjectLiteral.
Please read my earlier description of why I think JSON is more readable as you haven't addressed the main points with this format...
yes, because i do not regarding them as significant.
| | this is human-written object literal. It took me very little effort | to | express correctly the data structure i need to get out of it, with | little chance of doing some syntax mistake. | For smalltalker, like me, i find this expression is natural and | straightforward to read.
I understand that you can read this format, but I still maintain that in the end the lack of a few syntactic elements make this format ambiguous to read/write for the human...You need to full expression to make sense of it though.
It is not the fact that the expression works evaluates correctly but the fact that the interpretation of all of the elements relies upon knowledge of the underlying implementation ... for example, I am not familiar with the Color class so:
(Color 1 1 0)
tells me nothing when I read it ... are those rgb values cyn or some other encoding the lack of the names causes me problems .... if the shape of the Color class changes, then this particular expression will be useless ... in the wild classes tend to change shape over time ...
But this is what conventions for (and conversions written to conform with conventions). I do not see a big problem here. Second, (and that's one of the reasons for not implementing generic Object>>asObjectLiteral), you can allow conversion only for certain set of classes, Point, Number, Collection(s) etc, i.e. the ones which has ~0 chance of changing shape/representation. Like in case of dictionary, we do not reflecting the shape of this class directly i.e. (tally and array ivars), but rather reflecting its data-structure, so internal representation is not very important there and hence ca be made highly portable across dialects.
Third, if you are not familiar with Color , as long as you won't start using it in some of your project(s), i cannot see what should happen to make (Color 1 0 0) appear in the data what you dealing with in your projects. From other side, for other person(s) it could be very important for them to be able to serialize colors. So they will be using it , but in their own project(s). Now since you never cross roads, i do not see how you can have any issues with that: it is not your data, therefore not your headache.
Fourth, take CSS , for example. they having three ways defining color: #rrggbb #rgb or rgb(r,g,b)
and same thing, as you may guess #75927 notation means nothing for somebody who not familiar with CSS. (he may also make a wild guess, maybe it is cyn? who knows.. ;) )
So, if you don't like (Color 1 0 0) nothing prevents you from denoting colors in more explicit way, like: (RGBColor 1 0 0) or (RGB 1 0 0) or (Color r 1 g 0 b 0 alpha 0) or whatever you see fit.
In this notation use of class names is just a cheap and fast way to for denoting the stored object. With some little code, you can use arbitrary "type name" for denoting that, it is just your responsibility to recognize it and represent it with proper object at the end. But notation form don't needs to be altered, is will still stay (<data type name> <values>) and still smalltalk syntax.
| | And do not discount the environment where people working in: it is | smalltalk. | So, even if i not understand what is inside, i can always select that | piece of code and press Cmd-I | to inspect it (or explore it) and then i will see everything very | clear :)
except when you sitting in a text editor or when you are in a Smalltalk dialect that doesn't have the class you are looking at or the shape of the class in that dialect is different ...
in addition to my above comment: if your goal to make data dialect neutral, you making sure it is dialect neutral (no magic ;) , either by avoiding using non-compatible data structures, or represent them in a dialect-neutral way.
Look what we actually doing with JSON: since in smalltalk we can't have native representation of JS object, we representing it with surrogate (either dictionary or instance of JSONObject class etc).
| | As well, as you can do reverse: you can craft a complex thingy, and | then send #asObjectLiteral | and after some prettyfying, you can make it clearly readable. (not | mentioning that you can of course | pretty-print it automatically). | | While with JSON, if you evaluate json code in JS, you will get same | JSON as response.. | which is cool, because of invariant, but won't make it easier to | understand by any bit. | | > That's fine. | > | > I also mentioned that YAML is a standard format that is designed to | > be very readable by humans while still being parsable by a | > machine. You told me that I was missing the point. | > | yes, because my intent was to use smalltalk syntax (so that we | reusing | existing codebase, and keep uniformity, which is also important). | | > That's fine. | > | > You told me that the point is that you can encode arbitrary objects | > in literal arrays and that this representation is optimizable by | > the compiler. | > | | right, but that's a side effect (which i discovered discussing here | btw). I didn't had that in mind nor putting that as a requirement of | design. Still, admit, that this side effect is quite nice :) | | > That's nice, but it is still not readable by humans (in my opinion) | > and I don't want to involve the compiler ... I don't want to | > execute code directly from the repository - I want to insert a | > parser, so that we have control over the code that gets executed. | | i know. But my implementation does not evaluating any new code: it | just parses the input and transforms it into objects. It doesn't | installs new behavior to system. If you don't trust me, you're free | to | debug the code to see what it does. | | | > | > Obviously the goals that you have for this notation do not match up | > with the requirements that I have. | > | | my goal is just one: use smalltalk syntax to express data. | If you take smalltalker who knows smalltalk and nothing else, i think | he will learn to read that notation much faster comparing to learning | JSON/STON/YAML first. | Because it is already smalltalk and needs just a slight shift in POV | to see through braces. | That's the main point.
Regarding this goal...you realize that you are entering the territory where you have a solution (using smalltalk syntax to express data) and are looking for a problem to solve.
The problem I had (9 months ago, which was solved by using JSON/STON) is still not solved by your solution... you don't fail in terms of functionality, but in the simple fact that I value the extra syntax that STON/JSON provides that differentiates between arrays and dictionaries ...
You create a literal dictionary/object syntax for Smalltalk and you might have a convert.
In that case, i think , better would be to stay with STON then.
Dictionaries is quite complex data structure, comparing to lists (arrays) and basic values (numbers, strings and symbols). How many other languages, apart from JS, has syntax to denote dictionary-like structures?
Ruby: {:foo => 1, :bar => 2} Clojure: {:foo 1 :bar 2} Python: {'foo': 1, 'bar': 2} frank
I do not see a need in having separate syntax for dictionary. Because this goes to nowhere in form of never-ending story: - tomorrow i want syntactic sugar for Sets
Because with syntax for lists and dictionaries you can roll any kind of literal you might care for.
- then for Colors
A dictionary with keys of 'r', 'g' and 'b', Or 'c', 'm', 'y', 'k'. Or anything else.
- then for Points, Rectangles and Circles
A dictionary with 'x' and 'y' keys (or 'rho' and 'theta'), a list of four dictionaries (for the points), and a list with two dictionaries for the points.
... - and Pink Elephants
one of the reasons, why i like smalltalk syntax, is small grammar, minimal syntactic constructs, yet high expressive power. Smalltalk (and LISP) is a good demonstration that massive set of different syntax sugars/rules and expressive power are not correlating values.
Ah, but it's precisely Lisp's uniformity in appearance that trips people up. And that's precisely why in Clojure a list is (1 2 3), a vector is [1 2 3] and a dictionary is {:a 1 :b 2} - different things are visually distinct. You don't need a _lot_ of difference, because a little goes a long way. frank
If you think otherwise, i think you better start using Perl instead, where you can find sugars everywhere and will find that you can write same expression using infinite number of ways, up to the point that it is no longer possible to understand the code which you didn't wrote yourself.
| | > That's fine. | > | > I am not in dire need of "yet another Notation format". STON | > adequately fills the bill for what I need at the moment. | > | > I have responded to Eliot with more detail about why I consider | > JSON to be more readable than your original suggestion. I haven't | > commented on the readability of your other suggestions because I | > am assuming that you don't have code written to actually parse the | > different variations that you proposed. | > | > Sooo, it's not clear that I can contribute much more. | > | | Dale i value your contribution. You know we can criticize and fight | to death. | But when i demonstrated that you can use | #( Dictionary a -> b) | instead of | #( Dictionary a b) | notation, i actually wanted your input from different perspective: | if we going to introduce a smalltalk-based notation (one that using | smalltalk syntax), | is proposed variant good enough, or there can be alternative(s), | which | may be better than proposed. | As i said, i didn't wanted to contrast it with JSON, and derail the | whole thing into fight between camps | with zero value for community.
Igor, you are asking form my _opinion_ and I' giving you my _opinion_, and I will repeat it again, I think there needs to be a syntactic difference between dictionary and array ... only to make it possible for the poor human to make sense of things.... the lack of the syntactic demarcation is the weakness here.
I really think that your current variant is way to dependent upon magical ordering...multiple platforms do not represent common classes the same way and positional parameters don't allow for shape changes over time ... way to rigid and structured...
I think this don't needs additional comment(s) from me, since i answered to them above.
Dale
-- Best regards, Igor Stasenko.
+1 ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Saturday, October 20, 2012 1:49:10 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 04:13, Igor Stasenko <siguctua@gmail.com> wrote: | > On 20 October 2012 03:48, Dale Henrichs <dhenrich@vmware.com> | > wrote: | >> | >> | >> ----- Original Message ----- | >> | From: "Igor Stasenko" <siguctua@gmail.com> | >> | To: Pharo-project@lists.gforge.inria.fr | >> | Sent: Friday, October 19, 2012 4:46:47 PM | >> | Subject: Re: [Pharo-project] Yet another Notation format: Object | >> | literals | >> | | >> | On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> | >> | wrote: | >> | > Igor, | >> | > | >> | > It's not clear that I need to be part of this discussion. | >> | > | >> | > If you want to invent a new serialization format, then go for | >> | > it. | >> | > | >> | > I did chime in with my opinion that your suggested format was | >> | > not | >> | > very readable. You happen to disagree with me. | >> | > | >> | | >> | Yes, i disagree. Tell me what is not readable in this: | >> | | >> | #( Dictionary | >> | | >> | yellow (Color 1 1 0) | >> | blue (Color 0 0 1) | >> | red (Color 1 0 0) | >> | | >> | ) fromObjectLiteral. | >> | >> Please read my earlier description of why I think JSON is more | >> readable as you haven't addressed the main points with this | >> format... | > | > yes, because i do not regarding them as significant. | > | >> | | >> | this is human-written object literal. It took me very little | >> | effort | >> | to | >> | express correctly the data structure i need to get out of it, | >> | with | >> | little chance of doing some syntax mistake. | >> | For smalltalker, like me, i find this expression is natural and | >> | straightforward to read. | >> | >> I understand that you can read this format, but I still maintain | >> that in the end the lack of a few syntactic elements make this | >> format ambiguous to read/write for the human...You need to full | >> expression to make sense of it though. | >> | >> It is not the fact that the expression works evaluates correctly | >> but the fact that the interpretation of all of the elements | >> relies upon knowledge of the underlying implementation ... for | >> example, I am not familiar with the Color class so: | >> | >> (Color 1 1 0) | >> | >> tells me nothing when I read it ... are those rgb values cyn or | >> some other encoding the lack of the names causes me problems .... | >> if the shape of the Color class changes, then this particular | >> expression will be useless ... in the wild classes tend to change | >> shape over time ... | >> | > | > But this is what conventions for (and conversions written to | > conform | > with conventions). | > I do not see a big problem here. | > Second, (and that's one of the reasons for not implementing generic | > Object>>asObjectLiteral), | > you can allow conversion only for certain set of classes, Point, | > Number, Collection(s) etc, i.e. the ones | > which has ~0 chance of changing shape/representation. | > Like in case of dictionary, we do not reflecting the shape of this | > class directly i.e. (tally and array ivars), | > but rather reflecting its data-structure, so internal | > representation | > is not very important there and hence ca be made highly portable | > across dialects. | > | > Third, if you are not familiar with Color , as long as you won't | > start | > using it in some of your project(s), | > i cannot see what should happen to make (Color 1 0 0) appear in the | > data what you dealing with in your projects. | > From other side, for other person(s) it could be very important for | > them to be able to serialize colors. So they will be using it , but | > in | > their own project(s). Now since you never cross roads, i do not see | > how you can have any issues with that: it is not your data, | > therefore | > not your headache. | > | > Fourth, take CSS , for example. they having three ways defining | > color: | > #rrggbb | > #rgb | > or | > rgb(r,g,b) | > | > and same thing, as you may guess #75927 notation means nothing for | > somebody who not familiar with CSS. (he may also make a wild guess, | > maybe it is cyn? who knows.. ;) ) | > | > So, if you don't like (Color 1 0 0) | > nothing prevents you from denoting colors in more explicit way, | > like: | > (RGBColor 1 0 0) | > or | > (RGB 1 0 0) | > or | > (Color r 1 g 0 b 0 alpha 0) | > or whatever you see fit. | > | > In this notation use of class names is just a cheap and fast way to | > for denoting the stored object. | > With some little code, you can use arbitrary "type name" for | > denoting | > that, it is just your responsibility to recognize it | > and represent it with proper object at the end. But notation form | > don't needs to be altered, is will still stay | > (<data type name> <values>) | > and still smalltalk syntax. | > | > | >> | | >> | And do not discount the environment where people working in: it | >> | is | >> | smalltalk. | >> | So, even if i not understand what is inside, i can always select | >> | that | >> | piece of code and press Cmd-I | >> | to inspect it (or explore it) and then i will see everything | >> | very | >> | clear :) | >> | >> except when you sitting in a text editor or when you are in a | >> Smalltalk dialect that doesn't have the class you are looking at | >> or the shape of the class in that dialect is different ... | > | > in addition to my above comment: if your goal to make data dialect | > neutral, you making sure it is dialect neutral (no magic ;) , | > either | > by avoiding using non-compatible data structures, or represent them | > in | > a dialect-neutral way. | > | > Look what we actually doing with JSON: since in smalltalk we can't | > have native representation of JS object, we representing it with | > surrogate (either dictionary or instance of JSONObject class etc). | > | > | >> | >> | | >> | As well, as you can do reverse: you can craft a complex thingy, | >> | and | >> | then send #asObjectLiteral | >> | and after some prettyfying, you can make it clearly readable. | >> | (not | >> | mentioning that you can of course | >> | pretty-print it automatically). | >> | | >> | While with JSON, if you evaluate json code in JS, you will get | >> | same | >> | JSON as response.. | >> | which is cool, because of invariant, but won't make it easier to | >> | understand by any bit. | >> | | >> | > That's fine. | >> | > | >> | > I also mentioned that YAML is a standard format that is | >> | > designed to | >> | > be very readable by humans while still being parsable by a | >> | > machine. You told me that I was missing the point. | >> | > | >> | yes, because my intent was to use smalltalk syntax (so that we | >> | reusing | >> | existing codebase, and keep uniformity, which is also | >> | important). | >> | | >> | > That's fine. | >> | > | >> | > You told me that the point is that you can encode arbitrary | >> | > objects | >> | > in literal arrays and that this representation is optimizable | >> | > by | >> | > the compiler. | >> | > | >> | | >> | right, but that's a side effect (which i discovered discussing | >> | here | >> | btw). I didn't had that in mind nor putting that as a | >> | requirement of | >> | design. Still, admit, that this side effect is quite nice :) | >> | | >> | > That's nice, but it is still not readable by humans (in my | >> | > opinion) | >> | > and I don't want to involve the compiler ... I don't want to | >> | > execute code directly from the repository - I want to insert a | >> | > parser, so that we have control over the code that gets | >> | > executed. | >> | | >> | i know. But my implementation does not evaluating any new code: | >> | it | >> | just parses the input and transforms it into objects. It doesn't | >> | installs new behavior to system. If you don't trust me, you're | >> | free | >> | to | >> | debug the code to see what it does. | >> | | >> | | >> | > | >> | > Obviously the goals that you have for this notation do not | >> | > match up | >> | > with the requirements that I have. | >> | > | >> | | >> | my goal is just one: use smalltalk syntax to express data. | >> | If you take smalltalker who knows smalltalk and nothing else, i | >> | think | >> | he will learn to read that notation much faster comparing to | >> | learning | >> | JSON/STON/YAML first. | >> | Because it is already smalltalk and needs just a slight shift in | >> | POV | >> | to see through braces. | >> | That's the main point. | >> | >> Regarding this goal...you realize that you are entering the | >> territory where you have a solution (using smalltalk syntax to | >> express data) and are looking for a problem to solve. | >> | >> The problem I had (9 months ago, which was solved by using | >> JSON/STON) is still not solved by your solution... you don't fail | >> in terms of functionality, but in the simple fact that I value | >> the extra syntax that STON/JSON provides that differentiates | >> between arrays and dictionaries ... | >> | >> You create a literal dictionary/object syntax for Smalltalk and | >> you might have a convert. | >> | > | > In that case, i think , better would be to stay with STON then. | > | > Dictionaries is quite complex data structure, comparing to lists | > (arrays) and basic values (numbers, strings and symbols). How many | > other languages, apart from JS, has syntax to denote | > dictionary-like | > structures? | | Ruby: {:foo => 1, :bar => 2} | Clojure: {:foo 1 :bar 2} | Python: {'foo': 1, 'bar': 2} | | frank | | > I do not see a need in having separate syntax for dictionary. | > Because this goes to nowhere in form of never-ending story: | > - tomorrow i want syntactic sugar for Sets | | Because with syntax for lists and dictionaries you can roll any kind | of literal you might care for. | | > - then for Colors | | A dictionary with keys of 'r', 'g' and 'b', Or 'c', 'm', 'y', 'k'. Or | anything else. | | > - then for Points, Rectangles and Circles | | A dictionary with 'x' and 'y' keys (or 'rho' and 'theta'), a list of | four dictionaries (for the points), and a list with two dictionaries | for the points. | | > ... | > - and Pink Elephants | > | > one of the reasons, why i like smalltalk syntax, is small grammar, | > minimal syntactic constructs, | > yet high expressive power. | > Smalltalk (and LISP) is a good demonstration that massive set of | > different syntax sugars/rules and expressive power are not | > correlating | > values. | | Ah, but it's precisely Lisp's uniformity in appearance that trips | people up. And that's precisely why in Clojure a list is (1 2 3), a | vector is [1 2 3] and a dictionary is {:a 1 :b 2} - different things | are visually distinct. | | You don't need a _lot_ of difference, because a little goes a long | way. | | frank | | > If you think otherwise, i think you better start using Perl | > instead, | > where you can find sugars everywhere | > and will find that you can write same expression using infinite | > number of ways, | > up to the point that it is no longer possible to understand the | > code | > which you didn't wrote yourself. | > | >> | | >> | > That's fine. | >> | > | >> | > I am not in dire need of "yet another Notation format". STON | >> | > adequately fills the bill for what I need at the moment. | >> | > | >> | > I have responded to Eliot with more detail about why I | >> | > consider | >> | > JSON to be more readable than your original suggestion. I | >> | > haven't | >> | > commented on the readability of your other suggestions because | >> | > I | >> | > am assuming that you don't have code written to actually parse | >> | > the | >> | > different variations that you proposed. | >> | > | >> | > Sooo, it's not clear that I can contribute much more. | >> | > | >> | | >> | Dale i value your contribution. You know we can criticize and | >> | fight | >> | to death. | >> | But when i demonstrated that you can use | >> | #( Dictionary a -> b) | >> | instead of | >> | #( Dictionary a b) | >> | notation, i actually wanted your input from different | >> | perspective: | >> | if we going to introduce a smalltalk-based notation (one that | >> | using | >> | smalltalk syntax), | >> | is proposed variant good enough, or there can be alternative(s), | >> | which | >> | may be better than proposed. | >> | As i said, i didn't wanted to contrast it with JSON, and derail | >> | the | >> | whole thing into fight between camps | >> | with zero value for community. | >> | >> Igor, you are asking form my _opinion_ and I' giving you my | >> _opinion_, and I will repeat it again, I think there needs to be | >> a syntactic difference between dictionary and array ... only to | >> make it possible for the poor human to make sense of things.... | >> the lack of the syntactic demarcation is the weakness here. | >> | >> I really think that your current variant is way to dependent upon | >> magical ordering...multiple platforms do not represent common | >> classes the same way and positional parameters don't allow for | >> shape changes over time ... way to rigid and structured... | > | > I think this don't needs additional comment(s) from me, since i | > answered to them above. | > | >> | >> Dale | >> | > | > | > | > -- | > Best regards, | > Igor Stasenko. | > | |
On 20 October 2012 10:49, Frank Shearar <frank.shearar@gmail.com> wrote:
Ruby: {:foo => 1, :bar => 2} Clojure: {:foo 1 :bar 2} Python: {'foo': 1, 'bar': 2}
That's it? I can add some more :) This is interesting actually.. how hard you must try in attempt to make it look sane and readable. Dicts is quite complex data structure for describing in text. Another thing is , how often you need something more complex than dictionary where keys and values is both simple values? (i am talking about literals , of course). Dictionaries as keys? Just out of practical reasons #hash and #= is quite expensive to calculate for dictionary, for using them as keys. In my practice, using dictionary as key/values in another dictionary (or any other object) having sense only when you use identity dictionary (to serve as cache) but not within regular dictionary. And again, cache is usually constructed dynamically, not from literal(s). Also, how often you need more than two levels of nesting for describing literal data structure? Because, even if you will have nice syntax to denote dicts vs arrays vs lists, if you start nesting them deeply, at some point you will find that it is no longer readable, because you will get lost in [{() }]} maze very soon. And for shallow hierarchies, distinct syntax is not really important.
frank
I do not see a need in having separate syntax for dictionary. Because this goes to nowhere in form of never-ending story: - tomorrow i want syntactic sugar for Sets
Because with syntax for lists and dictionaries you can roll any kind of literal you might care for.
- then for Colors
A dictionary with keys of 'r', 'g' and 'b', Or 'c', 'm', 'y', 'k'. Or anything else.
how you determine that this is Color but not dictionary which coincidentally has same keys?
- then for Points, Rectangles and Circles
A dictionary with 'x' and 'y' keys (or 'rho' and 'theta'), a list of four dictionaries (for the points), and a list with two dictionaries for the points.
same again, list with 'x' and 'y' is not Point list with 4 dictionaries is not Rectangle etc.
... - and Pink Elephants
one of the reasons, why i like smalltalk syntax, is small grammar, minimal syntactic constructs, yet high expressive power. Smalltalk (and LISP) is a good demonstration that massive set of different syntax sugars/rules and expressive power are not correlating values.
Ah, but it's precisely Lisp's uniformity in appearance that trips people up. And that's precisely why in Clojure a list is (1 2 3), a vector is [1 2 3] and a dictionary is {:a 1 :b 2} - different things are visually distinct.
You don't need a _lot_ of difference, because a little goes a long way.
frank
-- Best regards, Igor Stasenko.
On 20 October 2012 20:52, Igor Stasenko <siguctua@gmail.com> wrote:
On 20 October 2012 10:49, Frank Shearar <frank.shearar@gmail.com> wrote:
Ruby: {:foo => 1, :bar => 2} Clojure: {:foo 1 :bar 2} Python: {'foo': 1, 'bar': 2}
That's it? I can add some more :)
I'm sure. These are just the ones I knew off the top of my head. I was too lazy to look up ML, Haskell, etc. syntax.
This is interesting actually.. how hard you must try in attempt to make it look sane and readable. Dicts is quite complex data structure for describing in text.
Another thing is , how often you need something more complex than dictionary where keys and values is both simple values? (i am talking about literals , of course).
Dictionaries as keys? Just out of practical reasons #hash and #= is quite expensive to calculate for dictionary, for using them as keys. In my practice, using dictionary as key/values in another dictionary (or any other object) having sense only when you use identity dictionary (to serve as cache) but not within regular dictionary. And again, cache is usually constructed dynamically, not from literal(s).
Also, how often you need more than two levels of nesting for describing literal data structure? Because, even if you will have nice syntax to denote dicts vs arrays vs lists, if you start nesting them deeply, at some point you will find that it is no longer readable, because you will get lost in [{() }]} maze very soon.
And for shallow hierarchies, distinct syntax is not really important.
frank
I do not see a need in having separate syntax for dictionary. Because this goes to nowhere in form of never-ending story: - tomorrow i want syntactic sugar for Sets
Because with syntax for lists and dictionaries you can roll any kind of literal you might care for.
- then for Colors
A dictionary with keys of 'r', 'g' and 'b', Or 'c', 'm', 'y', 'k'. Or anything else.
how you determine that this is Color but not dictionary which coincidentally has same keys?
There's a difference? :) I mean that only half in jest: it's idiomatic Clojure to do just this (use dictionaries to store structured data with named parts), and that's how CLOS works too. The only difference between the dictionary and the object is that the object also has keys pointing to methods. Most of the time though the source and target of the literal both have the same behaviour so there's not much need for transporting the methods. And you'd need much more machinery (well beyond the scope of this bikeshed) to permit the safe sending of data+code - capabilities, sandboxing, ... frank
- then for Points, Rectangles and Circles
A dictionary with 'x' and 'y' keys (or 'rho' and 'theta'), a list of four dictionaries (for the points), and a list with two dictionaries for the points.
same again, list with 'x' and 'y' is not Point list with 4 dictionaries is not Rectangle etc.
... - and Pink Elephants
one of the reasons, why i like smalltalk syntax, is small grammar, minimal syntactic constructs, yet high expressive power. Smalltalk (and LISP) is a good demonstration that massive set of different syntax sugars/rules and expressive power are not correlating values.
Ah, but it's precisely Lisp's uniformity in appearance that trips people up. And that's precisely why in Clojure a list is (1 2 3), a vector is [1 2 3] and a dictionary is {:a 1 :b 2} - different things are visually distinct.
You don't need a _lot_ of difference, because a little goes a long way.
frank
-- Best regards, Igor Stasenko.
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 8:13:12 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 03:48, Dale Henrichs <dhenrich@vmware.com> wrote: | > | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Friday, October 19, 2012 4:46:47 PM | > | Subject: Re: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> | > | wrote: | > | > Igor, | > | > | > | > It's not clear that I need to be part of this discussion. | > | > | > | > If you want to invent a new serialization format, then go for | > | > it. | > | > | > | > I did chime in with my opinion that your suggested format was | > | > not | > | > very readable. You happen to disagree with me. | > | > | > | | > | Yes, i disagree. Tell me what is not readable in this: | > | | > | #( Dictionary | > | | > | yellow (Color 1 1 0) | > | blue (Color 0 0 1) | > | red (Color 1 0 0) | > | | > | ) fromObjectLiteral. | > | > Please read my earlier description of why I think JSON is more | > readable as you haven't addressed the main points with this | > format... | | yes, because i do not regarding them as significant. Then I don't think I should be the one that you get feedback from ... or perhaps you should re-evaluate your thoughts that they are not significant ... At this point in time I don't see the point in discussing anything more ... You seem to be trying to convince me that I should be able to read a format that I consider unreadable ... you don't seem to want to hear that I consider the format unreadable ... We are done... Dale
On 20 October 2012 16:29, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 8:13:12 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 03:48, Dale Henrichs <dhenrich@vmware.com> wrote: | > | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Friday, October 19, 2012 4:46:47 PM | > | Subject: Re: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | On 20 October 2012 00:54, Dale Henrichs <dhenrich@vmware.com> | > | wrote: | > | > Igor, | > | > | > | > It's not clear that I need to be part of this discussion. | > | > | > | > If you want to invent a new serialization format, then go for | > | > it. | > | > | > | > I did chime in with my opinion that your suggested format was | > | > not | > | > very readable. You happen to disagree with me. | > | > | > | | > | Yes, i disagree. Tell me what is not readable in this: | > | | > | #( Dictionary | > | | > | yellow (Color 1 1 0) | > | blue (Color 0 0 1) | > | red (Color 1 0 0) | > | | > | ) fromObjectLiteral. | > | > Please read my earlier description of why I think JSON is more | > readable as you haven't addressed the main points with this | > format... | | yes, because i do not regarding them as significant.
Then I don't think I should be the one that you get feedback from ... or perhaps you should re-evaluate your thoughts that they are not significant ...
At this point in time I don't see the point in discussing anything more ...
You seem to be trying to convince me that I should be able to read a format that I consider unreadable ... you don't seem to want to hear that I consider the format unreadable ...
We are done...
yes, we are :)
Dale
-- Best regards, Igor Stasenko.
Hi Dale, I have followed this issue from very very far, so I may miss something important.\
{ "category" : "Topez-Client-Core", "classinstvars" : [ ], "classvars" : [ ], "commentStamp" : "", "instvars" : [ "project", "package", "currentClass", "classOrInstance", "category", "selector", "history", "currentWindowId", "windows", "namedWindows" ], "name" : "TZTopezStatus", "pools" : [ ], "super" : "Object", "type" : "normal" }
Could not it be #( (category 'Topez-Client-Core') (classinstvars ) (classvars ) (commentStamp '') (instvars 'project' 'package') (name 'TZTopezStatus') (pools ) (super 'Object') (type 'normal')) Like this, no parser at all is required. By the way, why keep pools? should type be specified in case it is normal? Cheers, Alexandre
which brings us back to were we started.
Smalltalk does not have a literal syntax for dictionaries. While fabricating dictionaries from literal arrays is possible, the results are not very readable ... unless you start taking liberties with Smalltalk syntax...
If you are no longer restricting yourself to Smalltalk syntax, then what's wrong with the STON notation above?
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 9:10:26 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 16:55, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > I'm afraid that your notation is not very friendly to humans ... a | > computer can keep track of the key value pairs in the literal | > dictionary, but a human will fail very quickly... | > | > The appeal of JSON (and STON) is that the output is readable by | > mere mortals: | > | > (JavaScript Object Notation) is a lightweight | > data-interchange format. It is easy for humans to | > read and write. | > | > What we're missing from Smalltalk is a literal dictionary or | > literal map syntax ... without that I'm afraid that for human | > friendly, lightweight notations we have to step away from the | > Smalltalk syntax - STON does this very nicely BTW... | | no problem, Dale. | What symbol you want to have to separate keys from values? | is '->' ok? | | Dictionary>>asObjectLiteral | | "convert a receiver into an object literal " | | ^ Array streamContents: [:stream | | stream nextPut: self class name. | self keysAndValuesDo: [:key :value | | stream | nextPut: key asObjectLiteral; | nextPut: #->; | nextPut: value asObjectLiteral ] ] | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | | #(#Dictionary | #a #'->' #b | #c #'->' #d) | | which if you pretty-print will look like: | | #( | Dictionary | a -> b | c -> d | ) | | is it better? | or you prefer this one: | | #( | Dictionary | (a -> b) | (c -> d) | ) | | you can do anything you like, by implementing the conversion methods | in a way you like :) | | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | > | Sent: Friday, October 19, 2012 4:09:22 AM | > | Subject: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | Hi, | > | as i promised before, here the simple smalltalk-based literal | > | format. | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | > | needs | > | to | > | have separate parser (a normal smalltalk parser used for that). | > | | > | The idea is quite simple: | > | you can tell any object to represent itself as an 'object | > | literal' , | > | for example: | > | | > | (1@3) asObjectLiteral | > | --> #(#Point 1 3) | > | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | > | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | > | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | > | asObjectLiteral | > | -> | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | | > | Next thing, you can 'pretty-print' it (kinda): | > | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' | > | | > | | > | and sure thing, you can do reverse conversion: | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' parseAsObjectLiteral | > | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | > | | > | Initially, i thought that it could be generic (by implementing | > | default | > | Object>>#asObjectLiteral), | > | but then after discussing it with others, we decided to leave | > | | > | Object>>#asObjectLiteral to be a subclass responsibility. | > | So, potentially the format allows to represent any object(s) as | > | literals, except from circular referencing objects, of course. | > | | > | The implementation is fairly simple, as you may guess and | > | contains no | > | new classes, but just extension methods here and there. | > | | > | Take it with grain and salt, since it is just a small proof of | > | concept. (And if doing it for real it may need some changes etc). | > | Since i am far from areas right now, where it can be used, i | > | don't | > | want to pursue it further or advocate if this is the right way to | > | do | > | things. | > | Neither i having a public repository for this project.. | > | | > | So, if there anyone who willing to pick it up and pursue the idea | > | further, please feel free to do so and make a public repository | > | for | > | project. | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | | | -- | Best regards, | Igor Stasenko. | |
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 19 Oct 2012, at 19:20, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Could not it be
#( (category 'Topez-Client-Core') (classinstvars ) (classvars ) (commentStamp '') (instvars 'project' 'package') (name 'TZTopezStatus') (pools ) (super 'Object') (type 'normal'))
Like this, no parser at all is required. By the way, why keep pools? should type be specified in case it is normal?
I think someone whose initials are SD is smiling right now ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Could not it be
#( (category 'Topez-Client-Core') (classinstvars ) (classvars ) (commentStamp '') (instvars 'project' 'package') (name 'TZTopezStatus') (pools ) (super 'Object') (type 'normal'))
Like this, no parser at all is required. By the way, why keep pools? should type be specified in case it is normal?
I think someone whose initials are SD is smiling right now ;-)
well I did not talk about that over lunch or any other moment. People know what I think and igor is a grown up with his own free mind :) Stef
Alexandre, Could? Certainly. However... At the time and possible even now, one would have to write a parser to parse that format (using the compiler and executing code is not allowed for security reasons). Portability was also a concern and GemStone does not have a public Smalltalk parser. A JSON parser consisting of 27 methods was already in existence (very portable - runs on 7 different Smalltalk dialects and counting) , so it was a no-brainer to choose JSON... It is now 9 months after the original decision and an acceptable substitute based on literal arrays has yet to come into existence. OTOH, STON _has_ appeared on the scene and it is preferable to JSON, since arbitrary classes of objects beyond Dictionary, Array, etc. can be easily (and clearly) written to disk. Moving forward I will be using STON. In the end I am a consumer ... I am not interested in writing my own parser/writer .... I don't have the aversion to the J in JSON that some folks seem to have ... I've got bits on disk that can be manipulated by humans and machines ( ... does it really matter what the bits look like? REALLY matter?) Dale ----- Original Message ----- | From: "Alexandre Bergel" <alexandre.bergel@me.com> | To: "Pharo-project@lists.gforge.inria.fr Smalltalk" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, October 19, 2012 10:20:04 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | Hi Dale, | | I have followed this issue from very very far, so I may miss | something important.\ | | > { | > "category" : "Topez-Client-Core", | > "classinstvars" : [ | > ], | > "classvars" : [ | > ], | > "commentStamp" : "", | > "instvars" : [ | > "project", | > "package", | > "currentClass", | > "classOrInstance", | > "category", | > "selector", | > "history", | > "currentWindowId", | > "windows", | > "namedWindows" ], | > "name" : "TZTopezStatus", | > "pools" : [ | > ], | > "super" : "Object", | > "type" : "normal" } | | Could not it be | | #( (category 'Topez-Client-Core') (classinstvars ) (classvars ) | (commentStamp '') (instvars 'project' 'package') (name | 'TZTopezStatus') (pools ) (super 'Object') (type 'normal')) | | Like this, no parser at all is required. | By the way, why keep pools? should type be specified in case it is | normal? | | Cheers, | Alexandre | | | > | > which brings us back to were we started. | > | > Smalltalk does not have a literal syntax for dictionaries. While | > fabricating dictionaries from literal arrays is possible, the | > results are not very readable ... unless you start taking | > liberties with Smalltalk syntax... | > | > If you are no longer restricting yourself to Smalltalk syntax, then | > what's wrong with the STON notation above? | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Friday, October 19, 2012 9:10:26 AM | > | Subject: Re: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | On 19 October 2012 16:55, Dale Henrichs <dhenrich@vmware.com> | > | wrote: | > | > Igor, | > | > | > | > I'm afraid that your notation is not very friendly to humans | > | > ... a | > | > computer can keep track of the key value pairs in the literal | > | > dictionary, but a human will fail very quickly... | > | > | > | > The appeal of JSON (and STON) is that the output is readable by | > | > mere mortals: | > | > | > | > (JavaScript Object Notation) is a lightweight | > | > data-interchange format. It is easy for humans to | > | > read and write. | > | > | > | > What we're missing from Smalltalk is a literal dictionary or | > | > literal map syntax ... without that I'm afraid that for human | > | > friendly, lightweight notations we have to step away from the | > | > Smalltalk syntax - STON does this very nicely BTW... | > | | > | no problem, Dale. | > | What symbol you want to have to separate keys from values? | > | is '->' ok? | > | | > | Dictionary>>asObjectLiteral | > | | > | "convert a receiver into an object literal " | > | | > | ^ Array streamContents: [:stream | | > | stream nextPut: self class name. | > | self keysAndValuesDo: [:key :value | | > | stream | > | nextPut: key asObjectLiteral; | > | nextPut: #->; | > | nextPut: value asObjectLiteral ] ] | > | | > | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | > | | > | #(#Dictionary | > | #a #'->' #b | > | #c #'->' #d) | > | | > | which if you pretty-print will look like: | > | | > | #( | > | Dictionary | > | a -> b | > | c -> d | > | ) | > | | > | is it better? | > | or you prefer this one: | > | | > | #( | > | Dictionary | > | (a -> b) | > | (c -> d) | > | ) | > | | > | you can do anything you like, by implementing the conversion | > | methods | > | in a way you like :) | > | | > | > | > | > Dale | > | > | > | > ----- Original Message ----- | > | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | > | > | Sent: Friday, October 19, 2012 4:09:22 AM | > | > | Subject: [Pharo-project] Yet another Notation format: Object | > | > | literals | > | > | | > | > | Hi, | > | > | as i promised before, here the simple smalltalk-based literal | > | > | format. | > | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | > | > | needs | > | > | to | > | > | have separate parser (a normal smalltalk parser used for | > | > | that). | > | > | | > | > | The idea is quite simple: | > | > | you can tell any object to represent itself as an 'object | > | > | literal' , | > | > | for example: | > | > | | > | > | (1@3) asObjectLiteral | > | > | --> #(#Point 1 3) | > | > | | > | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | > | > | | > | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | > | > | | > | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | > | > | asObjectLiteral | > | > | -> | > | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | > | | > | > | Next thing, you can 'pretty-print' it (kinda): | > | > | | > | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | > | printObjectLiteral | > | > | | > | > | '#(#Dictionary | > | > | 1 | > | > | (#Array 1 2 3) | > | > | ''foo'' ''bar'')' | > | > | | > | > | | > | > | and sure thing, you can do reverse conversion: | > | > | | > | > | '#(#Dictionary | > | > | 1 | > | > | (#Array 1 2 3) | > | > | ''foo'' ''bar'')' parseAsObjectLiteral | > | > | | > | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | > | > | | > | > | Initially, i thought that it could be generic (by | > | > | implementing | > | > | default | > | > | Object>>#asObjectLiteral), | > | > | but then after discussing it with others, we decided to leave | > | > | | > | > | Object>>#asObjectLiteral to be a subclass responsibility. | > | > | So, potentially the format allows to represent any object(s) | > | > | as | > | > | literals, except from circular referencing objects, of | > | > | course. | > | > | | > | > | The implementation is fairly simple, as you may guess and | > | > | contains no | > | > | new classes, but just extension methods here and there. | > | > | | > | > | Take it with grain and salt, since it is just a small proof | > | > | of | > | > | concept. (And if doing it for real it may need some changes | > | > | etc). | > | > | Since i am far from areas right now, where it can be used, i | > | > | don't | > | > | want to pursue it further or advocate if this is the right | > | > | way to | > | > | do | > | > | things. | > | > | Neither i having a public repository for this project.. | > | > | | > | > | So, if there anyone who willing to pick it up and pursue the | > | > | idea | > | > | further, please feel free to do so and make a public | > | > | repository | > | > | for | > | > | project. | > | > | | > | > | | > | > | -- | > | > | Best regards, | > | > | Igor Stasenko. | > | > | | > | > | > | | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | > | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | |
HI Dale, Hi Igor, On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
"you can do anything you like" ... you mean like choosing to use STON and not invent my own notation format?
STON is a perfectly good notation format for Smalltalk...
Methinks that with your recent suggestions are no longer using literal Smalltalk syntax which is fine, if we are not restricted to literal Smalltalk syntax, then the following should be a valid format:
{ "category" : "Topez-Client-Core", "classinstvars" : [ ], "classvars" : [ ], "commentStamp" : "", "instvars" : [ "project", "package", "currentClass", "classOrInstance", "category", "selector", "history", "currentWindowId", "windows", "namedWindows" ], "name" : "TZTopezStatus", "pools" : [ ], "super" : "Object", "type" : "normal" }
which brings us back to were we started.
Sorry to come late to the party and sorry to point out the obvious but the above is fine in Igor's scheme if one gives up double quotes (since these are comment characters). So the above, with single quotes replacing the double quotes, and #(...) replacing {...} is a valid Smalltalk literal. Is the latter any the less readable? I don't think so. Do you, Dale? (and sorry if the conversation has already moved on).
Smalltalk does not have a literal syntax for dictionaries. While fabricating dictionaries from literal arrays is possible, the results are not very readable ... unless you start taking liberties with Smalltalk syntax...
If you are no longer restricting yourself to Smalltalk syntax, then what's wrong with the STON notation above?
Dale
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 9:10:26 AM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 19 October 2012 16:55, Dale Henrichs <dhenrich@vmware.com> wrote: | > Igor, | > | > I'm afraid that your notation is not very friendly to humans ... a | > computer can keep track of the key value pairs in the literal | > dictionary, but a human will fail very quickly... | > | > The appeal of JSON (and STON) is that the output is readable by | > mere mortals: | > | > (JavaScript Object Notation) is a lightweight | > data-interchange format. It is easy for humans to | > read and write. | > | > What we're missing from Smalltalk is a literal dictionary or | > literal map syntax ... without that I'm afraid that for human | > friendly, lightweight notations we have to step away from the | > Smalltalk syntax - STON does this very nicely BTW... | | no problem, Dale. | What symbol you want to have to separate keys from values? | is '->' ok? | | Dictionary>>asObjectLiteral | | "convert a receiver into an object literal " | | ^ Array streamContents: [:stream | | stream nextPut: self class name. | self keysAndValuesDo: [:key :value | | stream | nextPut: key asObjectLiteral; | nextPut: #->; | nextPut: value asObjectLiteral ] ] | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | | #(#Dictionary | #a #'->' #b | #c #'->' #d) | | which if you pretty-print will look like: | | #( | Dictionary | a -> b | c -> d | ) | | is it better? | or you prefer this one: | | #( | Dictionary | (a -> b) | (c -> d) | ) | | you can do anything you like, by implementing the conversion methods | in a way you like :) | | > | > Dale | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | > | Sent: Friday, October 19, 2012 4:09:22 AM | > | Subject: [Pharo-project] Yet another Notation format: Object | > | literals | > | | > | Hi, | > | as i promised before, here the simple smalltalk-based literal | > | format. | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | > | needs | > | to | > | have separate parser (a normal smalltalk parser used for that). | > | | > | The idea is quite simple: | > | you can tell any object to represent itself as an 'object | > | literal' , | > | for example: | > | | > | (1@3) asObjectLiteral | > | --> #(#Point 1 3) | > | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | > | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | > | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | > | asObjectLiteral | > | -> | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | > | | > | Next thing, you can 'pretty-print' it (kinda): | > | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' | > | | > | | > | and sure thing, you can do reverse conversion: | > | | > | '#(#Dictionary | > | 1 | > | (#Array 1 2 3) | > | ''foo'' ''bar'')' parseAsObjectLiteral | > | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | > | | > | Initially, i thought that it could be generic (by implementing | > | default | > | Object>>#asObjectLiteral), | > | but then after discussing it with others, we decided to leave | > | | > | Object>>#asObjectLiteral to be a subclass responsibility. | > | So, potentially the format allows to represent any object(s) as | > | literals, except from circular referencing objects, of course. | > | | > | The implementation is fairly simple, as you may guess and | > | contains no | > | new classes, but just extension methods here and there. | > | | > | Take it with grain and salt, since it is just a small proof of | > | concept. (And if doing it for real it may need some changes etc). | > | Since i am far from areas right now, where it can be used, i | > | don't | > | want to pursue it further or advocate if this is the right way to | > | do | > | things. | > | Neither i having a public repository for this project.. | > | | > | So, if there anyone who willing to pick it up and pursue the idea | > | further, please feel free to do so and make a public repository | > | for | > | project. | > | | > | | > | -- | > | Best regards, | > | Igor Stasenko. | > | | > | | | | -- | Best regards, | Igor Stasenko. | |
-- best, Eliot
Eliot, STON (and JSON IIRC) allows either $" or $' as string literal delimiters, so I am not holding onto the $" as a key readability component. For me: { 'category' : 'Topez-Client-Core'} is perfectly readable and could be accomplished with the JSON reader/writer.... Dale ----- Original Message ----- | From: "Eliot Miranda" <eliot.miranda@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 2:07:28 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | HI Dale, Hi Igor, | | | On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs < dhenrich@vmware.com | > wrote: | | | Igor, | | "you can do anything you like" ... you mean like choosing to use STON | and not invent my own notation format? | | STON is a perfectly good notation format for Smalltalk... | | Methinks that with your recent suggestions are no longer using | literal Smalltalk syntax which is fine, if we are not restricted to | literal Smalltalk syntax, then the following should be a valid | format: | | { | "category" : "Topez-Client-Core", | "classinstvars" : [ | ], | "classvars" : [ | ], | "commentStamp" : "", | "instvars" : [ | "project", | "package", | "currentClass", | "classOrInstance", | "category", | "selector", | "history", | "currentWindowId", | "windows", | "namedWindows" ], | "name" : "TZTopezStatus", | "pools" : [ | ], | "super" : "Object", | "type" : "normal" } | | which brings us back to were we started. | | | | Sorry to come late to the party and sorry to point out the obvious | but the above is fine in Igor's scheme if one gives up double quotes | (since these are comment characters). So the above, with single | quotes replacing the double quotes, and #(...) replacing {...} is a | valid Smalltalk literal. Is the latter any the less readable? I | don't think so. Do you, Dale? (and sorry if the conversation has | already moved on). | | | | | Smalltalk does not have a literal syntax for dictionaries. While | fabricating dictionaries from literal arrays is possible, the | results are not very readable ... unless you start taking liberties | with Smalltalk syntax... | | If you are no longer restricting yourself to Smalltalk syntax, then | what's wrong with the STON notation above? | | | Dale | | ----- Original Message ----- | | From: "Igor Stasenko" < siguctua@gmail.com > | | | | To: Pharo-project@lists.gforge.inria.fr | | Sent: Friday, October 19, 2012 9:10:26 AM | | Subject: Re: [Pharo-project] Yet another Notation format: Object | | literals | | | | On 19 October 2012 16:55, Dale Henrichs < dhenrich@vmware.com > | | wrote: | | > Igor, | | > | | > I'm afraid that your notation is not very friendly to humans ... | | > a | | > computer can keep track of the key value pairs in the literal | | > dictionary, but a human will fail very quickly... | | > | | > The appeal of JSON (and STON) is that the output is readable by | | > mere mortals: | | > | | > (JavaScript Object Notation) is a lightweight | | > data-interchange format. It is easy for humans to | | > read and write. | | > | | > What we're missing from Smalltalk is a literal dictionary or | | > literal map syntax ... without that I'm afraid that for human | | > friendly, lightweight notations we have to step away from the | | > Smalltalk syntax - STON does this very nicely BTW... | | | | no problem, Dale. | | What symbol you want to have to separate keys from values? | | is '->' ok? | | | | Dictionary>>asObjectLiteral | | | | "convert a receiver into an object literal " | | | | ^ Array streamContents: [:stream | | | stream nextPut: self class name. | | self keysAndValuesDo: [:key :value | | | stream | | nextPut: key asObjectLiteral; | | nextPut: #->; | | nextPut: value asObjectLiteral ] ] | | | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | | | | #(#Dictionary | | #a #'->' #b | | #c #'->' #d) | | | | which if you pretty-print will look like: | | | | #( | | Dictionary | | a -> b | | c -> d | | ) | | | | is it better? | | or you prefer this one: | | | | #( | | Dictionary | | (a -> b) | | (c -> d) | | ) | | | | you can do anything you like, by implementing the conversion | | methods | | in a way you like :) | | | | > | | > Dale | | > | | > ----- Original Message ----- | | > | From: "Igor Stasenko" < siguctua@gmail.com > | | > | To: "Pharo Development" < Pharo-project@lists.gforge.inria.fr > | | > | Sent: Friday, October 19, 2012 4:09:22 AM | | > | Subject: [Pharo-project] Yet another Notation format: Object | | > | literals | | > | | | > | Hi, | | > | as i promised before, here the simple smalltalk-based literal | | > | format. | | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | | > | needs | | > | to | | > | have separate parser (a normal smalltalk parser used for that). | | > | | | > | The idea is quite simple: | | > | you can tell any object to represent itself as an 'object | | > | literal' , | | > | for example: | | > | | | > | (1@3) asObjectLiteral | | > | --> #(#Point 1 3) | | > | | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | | > | | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | > | | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | | > | asObjectLiteral | | > | -> | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | > | | | > | Next thing, you can 'pretty-print' it (kinda): | | > | | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' | | > | | | > | | | > | and sure thing, you can do reverse conversion: | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' parseAsObjectLiteral | | > | | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | > | | | > | Initially, i thought that it could be generic (by implementing | | > | default | | > | Object>>#asObjectLiteral), | | > | but then after discussing it with others, we decided to leave | | > | | | > | Object>>#asObjectLiteral to be a subclass responsibility. | | > | So, potentially the format allows to represent any object(s) as | | > | literals, except from circular referencing objects, of course. | | > | | | > | The implementation is fairly simple, as you may guess and | | > | contains no | | > | new classes, but just extension methods here and there. | | > | | | > | Take it with grain and salt, since it is just a small proof of | | > | concept. (And if doing it for real it may need some changes | | > | etc). | | > | Since i am far from areas right now, where it can be used, i | | > | don't | | > | want to pursue it further or advocate if this is the right way | | > | to | | > | do | | > | things. | | > | Neither i having a public repository for this project.. | | > | | | > | So, if there anyone who willing to pick it up and pursue the | | > | idea | | > | further, please feel free to do so and make a public repository | | > | for | | > | project. | | > | | | > | | | > | -- | | > | Best regards, | | > | Igor Stasenko. | | > | | | > | | | | | | | | -- | | Best regards, | | Igor Stasenko. | | | | | | | | | | -- | best, | Eliot |
On Fri, Oct 19, 2012 at 2:42 PM, Dale Henrichs <dhenrich@vmware.com> wrote:
Eliot,
STON (and JSON IIRC) allows either $" or $' as string literal delimiters, so I am not holding onto the $" as a key readability component.
For me:
{ 'category' : 'Topez-Client-Core'}
is perfectly readable and could be accomplished with the JSON reader/writer....
agreed, but you're not answering my question. Is Igor's any the less readable?
Dale ----- Original Message ----- | From: "Eliot Miranda" <eliot.miranda@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 2:07:28 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | HI Dale, Hi Igor, | | | On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs < dhenrich@vmware.com | > wrote: | | | Igor, | | "you can do anything you like" ... you mean like choosing to use STON | and not invent my own notation format? | | STON is a perfectly good notation format for Smalltalk... | | Methinks that with your recent suggestions are no longer using | literal Smalltalk syntax which is fine, if we are not restricted to | literal Smalltalk syntax, then the following should be a valid | format: | | { | "category" : "Topez-Client-Core", | "classinstvars" : [ | ], | "classvars" : [ | ], | "commentStamp" : "", | "instvars" : [ | "project", | "package", | "currentClass", | "classOrInstance", | "category", | "selector", | "history", | "currentWindowId", | "windows", | "namedWindows" ], | "name" : "TZTopezStatus", | "pools" : [ | ], | "super" : "Object", | "type" : "normal" } | | which brings us back to were we started. | | | | Sorry to come late to the party and sorry to point out the obvious | but the above is fine in Igor's scheme if one gives up double quotes | (since these are comment characters). So the above, with single | quotes replacing the double quotes, and #(...) replacing {...} is a | valid Smalltalk literal. Is the latter any the less readable? I | don't think so. Do you, Dale? (and sorry if the conversation has | already moved on). | | | | | Smalltalk does not have a literal syntax for dictionaries. While | fabricating dictionaries from literal arrays is possible, the | results are not very readable ... unless you start taking liberties | with Smalltalk syntax... | | If you are no longer restricting yourself to Smalltalk syntax, then | what's wrong with the STON notation above? | | | Dale | | ----- Original Message ----- | | From: "Igor Stasenko" < siguctua@gmail.com > | | | | To: Pharo-project@lists.gforge.inria.fr | | Sent: Friday, October 19, 2012 9:10:26 AM | | Subject: Re: [Pharo-project] Yet another Notation format: Object | | literals | | | | On 19 October 2012 16:55, Dale Henrichs < dhenrich@vmware.com > | | wrote: | | > Igor, | | > | | > I'm afraid that your notation is not very friendly to humans ... | | > a | | > computer can keep track of the key value pairs in the literal | | > dictionary, but a human will fail very quickly... | | > | | > The appeal of JSON (and STON) is that the output is readable by | | > mere mortals: | | > | | > (JavaScript Object Notation) is a lightweight | | > data-interchange format. It is easy for humans to | | > read and write. | | > | | > What we're missing from Smalltalk is a literal dictionary or | | > literal map syntax ... without that I'm afraid that for human | | > friendly, lightweight notations we have to step away from the | | > Smalltalk syntax - STON does this very nicely BTW... | | | | no problem, Dale. | | What symbol you want to have to separate keys from values? | | is '->' ok? | | | | Dictionary>>asObjectLiteral | | | | "convert a receiver into an object literal " | | | | ^ Array streamContents: [:stream | | | stream nextPut: self class name. | | self keysAndValuesDo: [:key :value | | | stream | | nextPut: key asObjectLiteral; | | nextPut: #->; | | nextPut: value asObjectLiteral ] ] | | | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | | | | #(#Dictionary | | #a #'->' #b | | #c #'->' #d) | | | | which if you pretty-print will look like: | | | | #( | | Dictionary | | a -> b | | c -> d | | ) | | | | is it better? | | or you prefer this one: | | | | #( | | Dictionary | | (a -> b) | | (c -> d) | | ) | | | | you can do anything you like, by implementing the conversion | | methods | | in a way you like :) | | | | > | | > Dale | | > | | > ----- Original Message ----- | | > | From: "Igor Stasenko" < siguctua@gmail.com > | | > | To: "Pharo Development" < Pharo-project@lists.gforge.inria.fr > | | > | Sent: Friday, October 19, 2012 4:09:22 AM | | > | Subject: [Pharo-project] Yet another Notation format: Object | | > | literals | | > | | | > | Hi, | | > | as i promised before, here the simple smalltalk-based literal | | > | format. | | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | | > | needs | | > | to | | > | have separate parser (a normal smalltalk parser used for that). | | > | | | > | The idea is quite simple: | | > | you can tell any object to represent itself as an 'object | | > | literal' , | | > | for example: | | > | | | > | (1@3) asObjectLiteral | | > | --> #(#Point 1 3) | | > | | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | | > | | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | > | | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | | > | asObjectLiteral | | > | -> | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | > | | | > | Next thing, you can 'pretty-print' it (kinda): | | > | | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' | | > | | | > | | | > | and sure thing, you can do reverse conversion: | | > | | | > | '#(#Dictionary | | > | 1 | | > | (#Array 1 2 3) | | > | ''foo'' ''bar'')' parseAsObjectLiteral | | > | | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | > | | | > | Initially, i thought that it could be generic (by implementing | | > | default | | > | Object>>#asObjectLiteral), | | > | but then after discussing it with others, we decided to leave | | > | | | > | Object>>#asObjectLiteral to be a subclass responsibility. | | > | So, potentially the format allows to represent any object(s) as | | > | literals, except from circular referencing objects, of course. | | > | | | > | The implementation is fairly simple, as you may guess and | | > | contains no | | > | new classes, but just extension methods here and there. | | > | | | > | Take it with grain and salt, since it is just a small proof of | | > | concept. (And if doing it for real it may need some changes | | > | etc). | | > | Since i am far from areas right now, where it can be used, i | | > | don't | | > | want to pursue it further or advocate if this is the right way | | > | to | | > | do | | > | things. | | > | Neither i having a public repository for this project.. | | > | | | > | So, if there anyone who willing to pick it up and pursue the | | > | idea | | > | further, please feel free to do so and make a public repository | | > | for | | > | project. | | > | | | > | | | > | -- | | > | Best regards, | | > | Igor Stasenko. | | > | | | > | | | | | | | | -- | | Best regards, | | Igor Stasenko. | | | | | | | | | | -- | best, | Eliot |
-- best, Eliot
Ah, So you are asking whether I think this: {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} is more readable than this: #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 #(#Array 1 2 3))) My answer is that I find the JSON style more readable. With JSON, I can look a sequence from the middle of the character sequence and recognize the syntactic elements: 'foo': bar', 3 as a key/value pair (foo/bar) and that 3 is probably a key ... while the following sequence is not recognizable as anything: 'foo' 'bar' 3 is it 3 elements in an array? is foo, bar or 3 a key? To get it right I have to count the key value pairs from the beginning of the dictionary, something that only a machine can do or a human presented with a small list of elements to look at. This readability is important when looking at larger structures that may span a screen full of items in a text editor. The {} delimiting a dictionary allows me to recognize the following sequence: 3]} as the end of an array and a dictionary whereas the following sequence could mean anything in the literal Smalltalk array world: 3)) I can use a text editor to find the terminator for a dictionary or an array. With a smalltalk literal array it isn't possible..again the human must resort to careful counting. I wouldn't think that I would need to point out that the #Dictionary and #Array also introduce quite a bit of visual noise... and the JSON sequence is about half as long as the literal array sequence and still quite readable... So, yes I find the JSON format more readable than Igor's suggested format. Dale ----- Original Message ----- | From: "Eliot Miranda" <eliot.miranda@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 2:47:22 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | | | | On Fri, Oct 19, 2012 at 2:42 PM, Dale Henrichs < dhenrich@vmware.com | > wrote: | | | Eliot, | | STON (and JSON IIRC) allows either $" or $' as string literal | delimiters, so I am not holding onto the $" as a key readability | component. | | For me: | | { 'category' : 'Topez-Client-Core'} | | is perfectly readable and could be accomplished with the JSON | reader/writer.... | | | | agreed, but you're not answering my question. Is Igor's any the less | readable? | | | | | Dale | ----- Original Message ----- | | | From: "Eliot Miranda" < eliot.miranda@gmail.com > | | To: Pharo-project@lists.gforge.inria.fr | | | | Sent: Friday, October 19, 2012 2:07:28 PM | | Subject: Re: [Pharo-project] Yet another Notation format: Object | | literals | | | | HI Dale, Hi Igor, | | | | | | On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs < | | dhenrich@vmware.com | | > wrote: | | | | | | Igor, | | | | "you can do anything you like" ... you mean like choosing to use | | STON | | and not invent my own notation format? | | | | STON is a perfectly good notation format for Smalltalk... | | | | Methinks that with your recent suggestions are no longer using | | literal Smalltalk syntax which is fine, if we are not restricted to | | literal Smalltalk syntax, then the following should be a valid | | format: | | | | { | | "category" : "Topez-Client-Core", | | "classinstvars" : [ | | ], | | "classvars" : [ | | ], | | "commentStamp" : "", | | "instvars" : [ | | "project", | | "package", | | "currentClass", | | "classOrInstance", | | "category", | | "selector", | | "history", | | "currentWindowId", | | "windows", | | "namedWindows" ], | | "name" : "TZTopezStatus", | | "pools" : [ | | ], | | "super" : "Object", | | "type" : "normal" } | | | | which brings us back to were we started. | | | | | | | | Sorry to come late to the party and sorry to point out the obvious | | but the above is fine in Igor's scheme if one gives up double | | quotes | | (since these are comment characters). So the above, with single | | quotes replacing the double quotes, and #(...) replacing {...} is a | | valid Smalltalk literal. Is the latter any the less readable? I | | don't think so. Do you, Dale? (and sorry if the conversation has | | already moved on). | | | | | | | | | | Smalltalk does not have a literal syntax for dictionaries. While | | fabricating dictionaries from literal arrays is possible, the | | results are not very readable ... unless you start taking liberties | | with Smalltalk syntax... | | | | If you are no longer restricting yourself to Smalltalk syntax, then | | what's wrong with the STON notation above? | | | | | | Dale | | | | ----- Original Message ----- | | | From: "Igor Stasenko" < siguctua@gmail.com > | | | | | | | To: Pharo-project@lists.gforge.inria.fr | | | Sent: Friday, October 19, 2012 9:10:26 AM | | | Subject: Re: [Pharo-project] Yet another Notation format: Object | | | literals | | | | | | On 19 October 2012 16:55, Dale Henrichs < dhenrich@vmware.com > | | | wrote: | | | > Igor, | | | > | | | > I'm afraid that your notation is not very friendly to humans | | | > ... | | | > a | | | > computer can keep track of the key value pairs in the literal | | | > dictionary, but a human will fail very quickly... | | | > | | | > The appeal of JSON (and STON) is that the output is readable by | | | > mere mortals: | | | > | | | > (JavaScript Object Notation) is a lightweight | | | > data-interchange format. It is easy for humans to | | | > read and write. | | | > | | | > What we're missing from Smalltalk is a literal dictionary or | | | > literal map syntax ... without that I'm afraid that for human | | | > friendly, lightweight notations we have to step away from the | | | > Smalltalk syntax - STON does this very nicely BTW... | | | | | | no problem, Dale. | | | What symbol you want to have to separate keys from values? | | | is '->' ok? | | | | | | Dictionary>>asObjectLiteral | | | | | | "convert a receiver into an object literal " | | | | | | ^ Array streamContents: [:stream | | | | stream nextPut: self class name. | | | self keysAndValuesDo: [:key :value | | | | stream | | | nextPut: key asObjectLiteral; | | | nextPut: #->; | | | nextPut: value asObjectLiteral ] ] | | | | | | (Dictionary newFromPairs: #( a b c d)) asObjectLiteral | | | | | | #(#Dictionary | | | #a #'->' #b | | | #c #'->' #d) | | | | | | which if you pretty-print will look like: | | | | | | #( | | | Dictionary | | | a -> b | | | c -> d | | | ) | | | | | | is it better? | | | or you prefer this one: | | | | | | #( | | | Dictionary | | | (a -> b) | | | (c -> d) | | | ) | | | | | | you can do anything you like, by implementing the conversion | | | methods | | | in a way you like :) | | | | | | > | | | > Dale | | | > | | | > ----- Original Message ----- | | | > | From: "Igor Stasenko" < siguctua@gmail.com > | | | > | To: "Pharo Development" < Pharo-project@lists.gforge.inria.fr | | | > | > | | | > | Sent: Friday, October 19, 2012 4:09:22 AM | | | > | Subject: [Pharo-project] Yet another Notation format: Object | | | > | literals | | | > | | | | > | Hi, | | | > | as i promised before, here the simple smalltalk-based literal | | | > | format. | | | > | It based on smalltalk syntax, and so, unlike JSON, it doesn't | | | > | needs | | | > | to | | | > | have separate parser (a normal smalltalk parser used for | | | > | that). | | | > | | | | > | The idea is quite simple: | | | > | you can tell any object to represent itself as an 'object | | | > | literal' , | | | > | for example: | | | > | | | | > | (1@3) asObjectLiteral | | | > | --> #(#Point 1 3) | | | > | | | | > | { 1@2. 3@4. true. false . nil } asObjectLiteral | | | > | | | | > | -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) | | | > | | | | > | (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) | | | > | asObjectLiteral | | | > | -> | | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | | > | | | | > | Next thing, you can 'pretty-print' it (kinda): | | | > | | | | > | #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') | | | > | printObjectLiteral | | | > | | | | > | '#(#Dictionary | | | > | 1 | | | > | (#Array 1 2 3) | | | > | ''foo'' ''bar'')' | | | > | | | | > | | | | > | and sure thing, you can do reverse conversion: | | | > | | | | > | '#(#Dictionary | | | > | 1 | | | > | (#Array 1 2 3) | | | > | ''foo'' ''bar'')' parseAsObjectLiteral | | | > | | | | > | a Dictionary('foo'->'bar' 1->#(1 2 3) ) | | | > | | | | > | Initially, i thought that it could be generic (by | | | > | implementing | | | > | default | | | > | Object>>#asObjectLiteral), | | | > | but then after discussing it with others, we decided to leave | | | > | | | | > | Object>>#asObjectLiteral to be a subclass responsibility. | | | > | So, potentially the format allows to represent any object(s) | | | > | as | | | > | literals, except from circular referencing objects, of | | | > | course. | | | > | | | | > | The implementation is fairly simple, as you may guess and | | | > | contains no | | | > | new classes, but just extension methods here and there. | | | > | | | | > | Take it with grain and salt, since it is just a small proof | | | > | of | | | > | concept. (And if doing it for real it may need some changes | | | > | etc). | | | > | Since i am far from areas right now, where it can be used, i | | | > | don't | | | > | want to pursue it further or advocate if this is the right | | | > | way | | | > | to | | | > | do | | | > | things. | | | > | Neither i having a public repository for this project.. | | | > | | | | > | So, if there anyone who willing to pick it up and pursue the | | | > | idea | | | > | further, please feel free to do so and make a public | | | > | repository | | | > | for | | | > | project. | | | > | | | | > | | | | > | -- | | | > | Best regards, | | | > | Igor Stasenko. | | | > | | | | > | | | | | | | | | | | | -- | | | Best regards, | | | Igor Stasenko. | | | | | | | | | | | | | | | | | | -- | | best, | | Eliot | | | | | | | | -- | best, | Eliot |
On 20 October 2012 00:26, Dale Henrichs <dhenrich@vmware.com> wrote:
Ah,
So you are asking whether I think this:
{1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}}
is more readable than this:
#(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 #(#Array 1 2 3)))
My answer is that I find the JSON style more readable.
With JSON, I can look a sequence from the middle of the character sequence and recognize the syntactic elements:
'foo': bar', 3
as a key/value pair (foo/bar) and that 3 is probably a key ... while the following sequence is not recognizable as anything:
'foo' 'bar' 3
is it 3 elements in an array? is foo, bar or 3 a key? To get it right I have to count the key value pairs from the beginning of the dictionary, something that only a machine can do or a human presented with a small list of elements to look at.
This readability is important when looking at larger structures that may span a screen full of items in a text editor.
The {} delimiting a dictionary allows me to recognize the following sequence:
3]}
as the end of an array and a dictionary whereas the following sequence could mean anything in the literal Smalltalk array world:
3))
I can use a text editor to find the terminator for a dictionary or an array. With a smalltalk literal array it isn't possible..again the human must resort to careful counting.
I wouldn't think that I would need to point out that the #Dictionary and #Array also introduce quite a bit of visual noise... and the JSON sequence is about half as long as the literal array sequence and still quite readable...
So, yes I find the JSON format more readable than Igor's suggested format.
Frankly i do not see any difference between those two. I think, if you ask an outsider who don't knows neither JS nor Smalltalk syntax (to have unbiased opinion), i bet he will not be able to easily interpret any of them. Apart of that , is of course, being able to tell the class of object literal. Try to express that with JSON: #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3))) maybe you don't need that. But i think there's plenty of others who may find it very useful. I didn't wanted to turn this discussion into anti-JSON war. So sorry for that. (But you know, sometimes it is hard to stop fighting ;) So, as i already demonstrated, this format, while maybe not best for humans having clear advantages comparing to have NOTHING at all: - you can use it for expressing literals in methods (and even easily extend compiler to pre-evaluate them at compile time) - you can easily extend it to use for many different classes, without breaking anything. - and finally, it is fairly small, and simple, because of code reuse (smalltalk parser)
Dale
-- Best regards, Igor Stasenko.
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:09:18 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:26, Dale Henrichs <dhenrich@vmware.com> wrote: | > Ah, | > | > So you are asking whether I think this: | > | > {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} | > | > is more readable than this: | > | > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 | > #(#Array 1 2 3))) | > | > My answer is that I find the JSON style more readable. | > | > With JSON, I can look a sequence from the middle of the character | > sequence and recognize the syntactic elements: | > | > 'foo': bar', 3 | > | > as a key/value pair (foo/bar) and that 3 is probably a key ... | > while the following sequence is not recognizable as anything: | > | > 'foo' 'bar' 3 | > | > is it 3 elements in an array? is foo, bar or 3 a key? To get it | > right I have to count the key value pairs from the beginning of | > the dictionary, something that only a machine can do or a human | > presented with a small list of elements to look at. | > | > This readability is important when looking at larger structures | > that may span a screen full of items in a text editor. | > | > The {} delimiting a dictionary allows me to recognize the following | > sequence: | > | > 3]} | > | > as the end of an array and a dictionary whereas the following | > sequence could mean anything in the literal Smalltalk array world: | > | > 3)) | > | > I can use a text editor to find the terminator for a dictionary or | > an array. With a smalltalk literal array it isn't possible..again | > the human must resort to careful counting. | > | > I wouldn't think that I would need to point out that the | > #Dictionary and #Array also introduce quite a bit of visual | > noise... and the JSON sequence is about half as long as the | > literal array sequence and still quite readable... | > | > So, yes I find the JSON format more readable than Igor's suggested | > format. | > | Frankly i do not see any difference between those two. Igor, It depends upon what you are looking for and what is important to you ... I have explained the syntax elements that make JSON more readable for me. Do you acknowledge that the syntax elements {}, [], :, and ,, provide additional syntactic structure that is lacking in the literal array syntax? You may not agree that they are important, but can you at least acknowledge that they might provide useful information that is absent in the pure literal array syntax? If you cannot acknowledge this little bit, then I'm not sure that it is worth discussing any further... | I think, if you ask an outsider who don't knows neither JS nor | Smalltalk syntax (to have unbiased opinion), | i bet he will not be able to easily interpret any of them. Of course .... and my _opinion_ is that the additional syntactic elements in JSON are very useful hints that makes it easier to interpret what you are looking at...when you know what you are looking at. | | Apart of that , is of course, being able to tell the class of object | literal. | Try to express that with JSON: | | #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 | #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3))) Sven implemented STON (which is actually the format that I prefer ... have you looked at STON?) and has inserted the class names into the format ... STON retains the [], : and {} elements to improve readability. | | maybe you don't need that. But i think there's plenty of others who | may find it very useful. Like I said I prefer STON because it does include class information, you should really take a look:) | | I didn't wanted to turn this discussion into anti-JSON war. So sorry | for that. | (But you know, sometimes it is hard to stop fighting ;) I am shocked that a little bit of JSON on disk has created such waves ... If STON had existed at the time I started I would have used that, although I suspect the same animosity would be directed towards STON, because it is a superset of JSON... | | So, as i already demonstrated, this format, while maybe not best for | humans having clear advantages comparing to have NOTHING at all: | | - you can use it for expressing literals in methods (and even easily | extend compiler to pre-evaluate them at compile time) I don't put STON into literals ... in the smalltalk image, the STON is generated from the objects and written to disk where it may be read/editted by developers using a standard text editor, with emphasis on _may_. | - you can easily extend it to use for many different classes, | without | breaking anything. STON shares this feature... | - and finally, it is fairly small, and simple, because of code reuse | (smalltalk parser) and we're back to where we started from 9 months ago ... GemStone does not have an accessible Smalltalk parser, and the number one requirement for this format is easy portability between dialects (7 smalltalk dialects are involved here...the JSON parser from Seaside with only 27 methods was easily ported to those dialects lacking their own JSON parser ... STON isn't quite as portable, but because of it's additional features will be worth the effort porting)... Dale
On 20 October 2012 03:17, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Friday, October 19, 2012 4:09:18 PM | Subject: Re: [Pharo-project] Yet another Notation format: Object literals | | On 20 October 2012 00:26, Dale Henrichs <dhenrich@vmware.com> wrote: | > Ah, | > | > So you are asking whether I think this: | > | > {1:[1,2,3],'foo':'bar',3:{1:2,3:[1,2,3]}} | > | > is more readable than this: | > | > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar' 3 #(#Dictionary 1 2 3 | > #(#Array 1 2 3))) | > | > My answer is that I find the JSON style more readable. | > | > With JSON, I can look a sequence from the middle of the character | > sequence and recognize the syntactic elements: | > | > 'foo': bar', 3 | > | > as a key/value pair (foo/bar) and that 3 is probably a key ... | > while the following sequence is not recognizable as anything: | > | > 'foo' 'bar' 3 | > | > is it 3 elements in an array? is foo, bar or 3 a key? To get it | > right I have to count the key value pairs from the beginning of | > the dictionary, something that only a machine can do or a human | > presented with a small list of elements to look at. | > | > This readability is important when looking at larger structures | > that may span a screen full of items in a text editor. | > | > The {} delimiting a dictionary allows me to recognize the following | > sequence: | > | > 3]} | > | > as the end of an array and a dictionary whereas the following | > sequence could mean anything in the literal Smalltalk array world: | > | > 3)) | > | > I can use a text editor to find the terminator for a dictionary or | > an array. With a smalltalk literal array it isn't possible..again | > the human must resort to careful counting. | > | > I wouldn't think that I would need to point out that the | > #Dictionary and #Array also introduce quite a bit of visual | > noise... and the JSON sequence is about half as long as the | > literal array sequence and still quite readable... | > | > So, yes I find the JSON format more readable than Igor's suggested | > format. | > | Frankly i do not see any difference between those two.
Igor, It depends upon what you are looking for and what is important to you ... I have explained the syntax elements that make JSON more readable for me.
Do you acknowledge that the syntax elements {}, [], :, and ,, provide additional syntactic structure that is lacking in the literal array syntax?
Smalltalk is also famous for lacking curly-brace syntax {} for statement grouping and ';' as statement terminating symbol and of course missing '.' between receiver and 'member method call'. What is your point? :) Why space is worse that comma? If you can provide arguments for using commas, next thing which i will ask from you to apply same argumentation for using 'object.foo' instead of 'object foo' for message sends... and if you can argument that, then i will also ask argument writing 'object.foo()', as well, and then finally 'object.foo();' :) and then we will be very happy (assuming that i will accept your argumentation ;) Btw, one of the reasons why i hate Python is that they using white space for statement grouping. But that is slightly different: treating an arbitrary number of 'white space' characters as single white space is not the same as counting each white-space character to determine statement nesting. That's quite evil , and that's why i live with smalltalk not python.
You may not agree that they are important, but can you at least acknowledge that they might provide useful information that is absent in the pure literal array syntax?
If you cannot acknowledge this little bit, then I'm not sure that it is worth discussing any further...
You right, i cannot. But as i mentioned before , nothing prevents you from using punctuation to separate values (and throw them away after smalltalk parser did its job). And as you said then it is nothing better than STON: if STON syntax can be modified to be parsed using smalltalk parser (no matter what weird literal you will get as result), i think that would be just advantageous.
| I think, if you ask an outsider who don't knows neither JS nor | Smalltalk syntax (to have unbiased opinion), | i bet he will not be able to easily interpret any of them.
Of course .... and my _opinion_ is that the additional syntactic elements in JSON are very useful hints that makes it easier to interpret what you are looking at...when you know what you are looking at.
Hints only for those who know JSON :) But not for those who know smalltalk. Yesterday everyone was using XML, today its JSON.. tomorrow it will be another over-hyped format. Why we can't have own? Ah, yes we have it - STON :)
| | Apart of that , is of course, being able to tell the class of object | literal. | Try to express that with JSON: | | #(IdentityDictionary 1 #(#OrderedCollection 1 2 3) 'foo' 'bar' 3 | #(WeakKeyDictionary 1 2 3 #(#Set 1 2 3)))
Sven implemented STON (which is actually the format that I prefer ... have you looked at STON?) and has inserted the class names into the format ... STON retains the [], : and {} elements to improve readability.
I looked at it briefly.. Sure thing i didn't read details. So, if you say STON can deal with that, then cool :)
| | maybe you don't need that. But i think there's plenty of others who | may find it very useful.
Like I said I prefer STON because it does include class information, you should really take a look:)
Yes. As well as many other interesting stuff which happens around.
| | I didn't wanted to turn this discussion into anti-JSON war. So sorry | for that. | (But you know, sometimes it is hard to stop fighting ;)
I am shocked that a little bit of JSON on disk has created such waves ... If STON had existed at the time I started I would have used that, although I suspect the same animosity would be directed towards STON, because it is a superset of JSON...
If you want to understand why it created such waves, try to do: 'port install cairo' on your mac, which brings half of the unix distribution as dependencies including xml parser, python and god knows what else, just to build this library. While later i discovered that you can build it without having python installed neither xml parser, but just 3 other C libraries which are direct dependencies of it. This is where such way of thinking leads to, when you put extra dependencies without attempting to find a way how to stay minimalist. To me, i find it very compelling to find good arguments, why you needing JSON parser in a project which deals with smalltalk and only smalltalk and nothing else, in same way as why C library needs python in order to be built (while C compiler is sufficient for that).
| | So, as i already demonstrated, this format, while maybe not best for | humans having clear advantages comparing to have NOTHING at all: | | - you can use it for expressing literals in methods (and even easily | extend compiler to pre-evaluate them at compile time)
I don't put STON into literals ... in the smalltalk image, the STON is generated from the objects and written to disk where it may be read/editted by developers using a standard text editor, with emphasis on _may_.
| - you can easily extend it to use for many different classes, | without | breaking anything.
STON shares this feature...
| - and finally, it is fairly small, and simple, because of code reuse | (smalltalk parser)
and we're back to where we started from 9 months ago ... GemStone does not have an accessible Smalltalk parser, and the number one requirement for this format is easy portability between dialects (7 smalltalk dialects are involved here...the JSON parser from Seaside with only 27 methods was easily ported to those dialects lacking their own JSON parser ... STON isn't quite as portable, but because of it's additional features will be worth the effort porting)...
Dale, i know that. Now, don't let me get started to enumerate numerous reasons why it is good to have parser implemented in language side (apart from being used for purposes we currently talking about). In your place, i would see it as a good opportunity for implementing new cross-dialect smalltalk parser, given that the one which we have in Pharo is not that good as we want it to be, and Pharoers (don't know how Squeakers), would be really happy seeing progress in that area, and would only welcome that. Having parser which can work across dialects is very good thing (tm), isn't?
Dale
-- Best regards, Igor Stasenko.
Hi all! Yeah, yeah, we have all been through this but let me just note a few things: 1. This blog article I wrote compares these formats and discusses a few interesting ideas IMHO (extending object literals for example) 2. My implementation of Tirade actually *includes* a stripped down object literal parser. So we have one! And it is much faster than the regular Compiler and of course *safe*. You can read more about that in my Tirade-articles: http://goran.krampe.se/?s=Tirade&x=0&y=0 regards, Göran
participants (9)
-
Alexandre Bergel -
Dale Henrichs -
drush66 -
Eliot Miranda -
Frank Shearar -
Göran Krampe -
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe