October 2012 - Pharo-dev - lists.pharo.org

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

by Dale Henrichs

+1 ----- Original Message ----- | From: "Frank Shearar" <frank.shearar(a)gmail.com> | To: Pharo-project(a)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(a)gmail.com> wrote: | > On 20 October 2012 03:48, Dale Henrichs <dhenrich(a)vmware.com> | > wrote: | >> | >> | >> ----- Original Message ----- | >> | From: "Igor Stasenko" <siguctua(a)gmail.com> | >> | To: Pharo-project(a)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(a)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. | > | |

Oct. 20, 2012

[Pharo-project] Still Alive

by Sean P. DeNigris

Hey guys, A few of you reached out since I have been absent from commits and the mailing lists. I am very much still around, just furiously hacking on a Pharo project (and a little burnt out from ESUG, but in a good way). Thanks for the love :) Sean -- View this message in context: http://forum.world.st/Still-Alive-tp4652126.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 20, 2012

Re: [Pharo-project] what is your pharo story?

by Sean P. DeNigris

Marcus Denker-4 wrote > building a feedback loop is more important > than being perfect with the first iteration... Yes, yes, yes!!! Take a small step and error correct... it's the only way!!! -- View this message in context: http://forum.world.st/what-is-your-pharo-story-tp4651655p4652125.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 20, 2012

Re: [Pharo-project] Fw: what is your pharo story?

by Sean P. DeNigris

kilon wrote > my goal is... to use pharo to "script" blender Awesome! That would be a killer app :) I've used Blender a bunch, but being spoiled by Smalltalk, I feel suffocated in environments (most apps) that are not live, direct, dynamic, turtles-all-the-way-down... The great thing about REST being "cool" is that many services that would have been trapped behind crappy UIs are now free to be wrapped... yet I digress... Cheers, Sean -- View this message in context: http://forum.world.st/what-is-your-pharo-story-tp4651655p4652123.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 20, 2012

Re: [Pharo-project] Progress bar in 2.0

by Sean P. DeNigris

EstebanLM wrote > it is supposed to be... Step by step we evolve... under the covers, the new progress system bears little resemblance to the previous mess. It is much more powerful, allowing us to create, manage, and receive updates about units of work. And, we will continuously improve it... Sean -- View this message in context: http://forum.world.st/Progress-bar-in-2-0-tp4651694p4652122.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 20, 2012

[Pharo-project] On Object literals...

by GÃ¶ran Krampe

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

Oct. 20, 2012

Re: [Pharo-project] Reduced Cuis

by Edgar J. De Cleene

On 10/20/12 9:02 AM, "Craig Latta" <craig(a)netjam.org> wrote: > > Hi Edgar-- > > Yes, I want to make Naiad modules from the Morphic in Cuis. > > > thanks, File in spoon3b2 the .cs and drag and drop the .obj. By the way my modification to Object is a three way (Squeak Pharo Cuis) for exporting / importing basic objects using ReferenceStream. How I could tell Spoon copy this list of class and methods into the "history" ? How I come whit this list? I do the reverse of you do. Instead of see which methods do not was executed, I know this is the minimal you have when you see the World (#PasteUpMorph). I do not saying if you put this into the history you have a real minimal Morphic thing, but like to try.... Edgar

Oct. 20, 2012

Re: [Pharo-project] Reduced Cuis

by Craig Latta

Hi Edgar-- Yes, I want to make Naiad modules from the Morphic in Cuis. thanks, -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

Oct. 20, 2012

[Pharo-project] Reduced Cuis

by Edgar J. De Cleene

Fellows Squeakers, Pharopatas and Cuiseros http://squeakros.org/Cuis3dot2/CuiSantafesino.zip Here you could download the smaller Morphic system. All credit belongs to Juan Vuletich http://www.jvuletich.org/Cuis/Index.html My wish is some day build a more compatible system with current Squeak 4.4 and/or Pharo 1.4 Also start with Spoon and reach the Cuis.image or use Seed / Hazelnut and start from the Â³class repositoryÂ² into http://squeakros.org/Cuis3dot2/ Runs with old Squeak 4.2.5beta1U (I could use my old G4s !!!) or with newer Cog VM (Elliot and Esteban) Edgar

Oct. 20, 2012

Re: [Pharo-project] [update 2.0] #20352

by StÃ©phane Ducasse

this is good to see better method comments! Stef On Oct 20, 2012, at 10:58 AM, Marcus Denker wrote: > 20352 > ----- > > Issue 6834: Failing test: ReleaseTest>>testUnpackagedClasses > http://code.google.com/p/pharo/issues/detail?id=6834 > > Issue 6847: More Error handling Documentation > http://code.google.com/p/pharo/issues/detail?id=6847 > > Issue 6825: Nautilus code uses Symbol readFromString: > http://code.google.com/p/pharo/issues/detail?id=6825 > Diff information: > http://ss3.gemstone.com/ss/Pharo20/RPackage-SystemIntegration-MarcusDenker.… > http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-MarcusDenker.194.diff > http://ss3.gemstone.com/ss/Pharo20/NautilusCommon-MarcusDenker.99.diff > http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.372.diff > http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1217.diff > > > > -- > Marcus Denker -- http://marcusdenker.de > >

Oct. 20, 2012