Stef, I mentioned several weeks ago that the Cypress implementation takes advantage of the fact that the JSON parser produces dictionaries ... this is a bit of functionality that I called out as critical ... STON is the first Smalltalk-centric text format that I've seen that has a nice syntax for producing Dictionaries. Of course, I think it is a bonus that you can use it to represent specific class instances as that can prove to be very useful. Of course I am a Smalltalk programmer, so if you give me STON, instead of meticulously constructing a JSON structure that matches the fields of the classes (for each dialect) I think that we would be inclined to ask the class to create a STON representation and dump that to disk ... So the immediate value of STON would be that we'd be sending messages to objects instead of translating formats .... the messages that we send will end up creating a nice human-readable format ... win-win. Of course for multiple dialects we agreed that we would use the same set of field names for the class attributes so that a dialect could create the class using the fields that it recognized ... so that would imply some level of standardization of the STON field names to be used, but that shouldn't be too hard since there aren't that many fields to monkey with for classes ... Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 3:36:47 PM | Subject: Re: [Pharo-project] SimpleLiteralArray Spec | | | On Apr 25, 2012, at 12:17 AM, Dale Henrichs wrote: | | > Stef, | > | > Which is more important: | > | > implementation or functionality? | | functionality: how to store meta data of class or method. So far I do | not see why I need ston. | | Now if you tell me that you need a textual serializer then this is | another story and scenario. | But this is not the one we need to store meta data of class and | method. | | I'm not that approximate to mix the two. | | Stef | > | > You appear to be fixated on a particular solution and seem to be | > ignoring the actual problems. | > | > Dale | > | > ----- Original Message ----- | > | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | > | To: Pharo-project@lists.gforge.inria.fr | > | Sent: Tuesday, April 24, 2012 3:13:20 PM | > | Subject: Re: [Pharo-project] SimpleLiteralArray Spec | > | | > | | > | On Apr 24, 2012, at 1:26 PM, Sven Van Caekenberghe wrote: | > | | > | > OK, just to get started, let try to write a spec for | > | > SimpleLiteralArray, this is based on JSON (and my own STON, not | > | > ready for public consumption). It will soon become clear that | > | > this | > | > is slightly harder than expected, IMO a writer is needed as | > | > well. | > | > | > | > S y n t a x | > | > | > | > value | > | > primitive-value | > | > list | > | > nil | > | > primitive-value | > | > number | > | > true | > | > false | > | > symbol | > | > string | > | > classname | > | | > | In a literal array a class name is just a symbol | > | | > | #(Foo) first | > | #Foo | > | | > | > list | > | > #() | > | > #( elements ) | > | > elements | > | > value | > | > value , elements | > | > string | > | > '' | > | > ' chars ' | > | > chars | > | > char | > | > char chars | > | > char | > | > any-printable-ASCII-character- | > | > except-"-or-\ | > | > \" | > | > \\ | > | > \/ | > | > \b | > | > \f | > | > \n | > | > \r | > | > \t | > | > \u four-hex-digits | > | | > | why do we need that? | > | | > | > symbol | > | > # chars-limited | > | > # ' chars ' | > | > chars-limited | > | > char-limited | > | > char-limited chars-limited | > | > char-limited | > | > a-z A-Z 0-9 - _ . / | > | > classname | > | > uppercase-alpha-char alphanumeric-char | > | | > | there is not need for classname as element | > | classname is just a pair that the interpretation should handle if | > | necessary | > | | > | | > | > number | > | > int | > | > int frac | > | > int exp | > | > int frac exp | > | > int | > | > digit | > | > digit1-9 digits | > | > - digit | > | > - digit1-9 digits | > | > frac | > | > . digits | > | > exp | > | > e digits | > | > digits | > | > digit | > | > digit digits | > | > e | > | > e | > | > e+ | > | > e- | > | > E | > | > E+ | > | > E- | > | > | > | > | > | > Questions remain: | > | > | > | > - is the escaping OK ? | > | | > | I do not know but in literal array there is no escaping. Now if | > | you | > | want to put a cr into a string you probably need that | > | | > | > - what about symbols without a leading # ? | > | | > | #(foo) -> #(#foo) | > | #(true nil false 1 'n') -> #(true nil false 1 'n') | > | | > | > - what should be allowed in unquoted symbols ? | > | I did not get the question | > | | > | > - what should be allowed for classnames ? | > | Nothing | > | | > | > - what about namespaces ? | > | Nothing no need I do not think that they are in literal arrays. | > | (may | > | be in VW but I did not check) | > | | > | > - do we allow infinite precision integers ? | > | Yes | > | | > | > - maybe the toplevel should always be an array ? | > | | > | I would say so else this is not a literalArray but a literal. | > | | > | | > | > | > | > | > | > Now: shoot! | > | > | > | > | > | > Sven | > | > | > | > | > | > -- | > | > Sven Van Caekenberghe | > | > http://stfx.eu | > | > Smalltalk is the Red Pill | > | > | > | > | > | > | > | > | > | > | > | | > | | > | | > | | |