Re: [Pharo-project] Yet another Notation format: Object literals

Oct. 20, 2012


      +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.
| >
| 
|