Hi guys

We should develop a simple Literal Array parser that is dialect independant so that we can avoid using JSON for meta data. So I will start to develop. I will start to write some tests and do it test first.

Gofer new repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; package: 'SimpleLiteralArrayParser'; load

Now I still wonder what do we do about floats. May be the situation changed but Squeak and VW floats were not the same.

I don't get it. You define your own float format, and then each dialect parses it and converts it to their correspondant format... Now, I do not know the format differences so I do not know which one take :).

It can work for simple scenario but if you save a float with e120 and save it and you get e70 then you are in trouble. Stef

Mariano read the metacello mailing list mails I sent. I hate hate hate repeating myself. I started to work on the LIteralArrayParser so that we do not have the problem in the future. Stef On Apr 24, 2012, at 12:52 PM, Mariano Martinez Peck wrote:

On Tue, Apr 24, 2012 at 12:43 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Hi guys

We should develop a simple Literal Array parser that is dialect independant so that we can avoid using JSON for meta data. So I will start to develop. I will start to write some tests and do it test first.

Gofer new repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; package: 'SimpleLiteralArrayParser'; load

Now I still wonder what do we do about floats. May be the situation changed but Squeak and VW floats were not the same.

I don't get it. You define your own float format, and then each dialect parses it and converts it to their correspondant format... Now, I do not know the format differences so I do not know which one take :).

It can work for simple scenario but if you save a float with e120 and save it and you get e70 then you are in trouble.

You are not in trouble. And if you are, then you are exactlty the same as if you were using a literal parser. You have a specification. You say that floats are written in THIS XXX text representation. Nobody cares how your floats are represented inside your Smalltalk. For JSON you write floats in a particular way, explained by the JSON specification. Then, when you code the parser, you will need to crate an instance of Float from the string. Each dialect will know how to do that. So, again, where is the problem? And how the literal parser would solve it? because I think it will happen the same.

Cheers,

Stef

-- Mariano http://marianopeck.wordpress.com

P.S. The ANSI Standard [1] 3.4.6 Literals A literal is a syntactic construct that that directly describes a statically created object. Instances of several classes of objects can be represented literally. These include numbers, characters, strings, symbols, message selectors, and arrays. Each type of literal is discussed in individual sections below. For each type of literal, a protocol is specified to which objects of that literal form must conform. <literal> ::= <number literal> | <string literal> | <character literal> | <symbol literal> | <selector literal> | <array literal> 3.4.6.6 Array Literals An array literal is a sequenced collection with numeric keys which may contain any number of other literals. <array literal> ::= '#(' <array element>* ')' <array element> ::= <literal> | identifier The value of an array literal is an object that implements the <sequencedReadableCollection> protocol. The elements of an array literal can consist of any combination of literal forms. If an identifier appears as an <array element> and it is one of the reserved identifiers nil, true or false the value of the corresponding element of the collection is the value of that reserved identifier. The meaning is undefined if any other identifier is used as an <array element>. If an <array literal> has no <array element>clauses the collection has no elements [1] NCITS J20 DRAFT of ANSI Smalltalk Standard December, 1997 revision 1.9 Draft American National Standard for Information Systems - Programming Languages - Smalltalk accessed through http://wiki.squeak.org/squeak/172 On 5/10/12, H. Hirzel <hannes.hirzel@gmail.com> wrote:

Hi Stéphane

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

<citation> Literal Smalltalk arrays

The simplest notation of all in the lineup is the literal array syntax in Smalltalk. The example below covers all its capabilities AFAIK (in Pharo/Squeak), please tell me if I missed anything:

#(4711 3.4 16r3F 'string' #symbol #'another-symbol' (nested array) #(one more) true false nil $x #[12 32])

</citation>

Do you agree that this covers everything in terms of literal arrays?

--Hannes

On 4/24/12, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Mariano

read the metacello mailing list mails I sent. I hate hate hate repeating myself.

I started to work on the LIteralArrayParser so that we do not have the problem in the future.

Stef

On Apr 24, 2012, at 12:52 PM, Mariano Martinez Peck wrote:

...

On Tue, Apr 24, 2012 at 12:43 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Hi guys

We should develop a simple Literal Array parser that is dialect independant so that we can avoid using JSON for meta data. So I will start to develop. I will start to write some tests and do it test first.

Gofer new repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; package: 'SimpleLiteralArrayParser'; load

Now I still wonder what do we do about floats. May be the situation changed but Squeak and VW floats were not the same.

I don't get it. You define your own float format, and then each dialect parses it and converts it to their correspondant format... Now, I do not know the format differences so I do not know which one take :).

It can work for simple scenario but if you save a float with e120 and save it and you get e70 then you are in trouble.

You are not in trouble. And if you are, then you are exactlty the same as if you were using a literal parser. You have a specification. You say that floats are written in THIS XXX text representation. Nobody cares how your floats are represented inside your Smalltalk. For JSON you write floats in a particular way, explained by the JSON specification. Then, when you code the parser, you will need to crate an instance of Float from the string. Each dialect will know how to do that. So, again, where is the problem? And how the literal parser would solve it? because I think it will happen the same.

Cheers,

Stef

-- Mariano http://marianopeck.wordpress.com

On Tue, Apr 24, 2012 at 12:15 PM, Sven Van Caekenberghe <sven@beta9.be>wrote:

On 24 Apr 2012, at 11:40, stephane ducasse wrote:

...

Hi guys

We should develop a simple Literal Array parser that is dialect independant so that we can avoid using JSON for meta data. So I will start to develop. I will start to write some tests and do it test first.

Gofer new repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; package: 'SimpleLiteralArrayParser'; load

Now I still wonder what do we do about floats. May be the situation changed but Squeak and VW floats were not the same.

Stef

Good idea!

I was already thinking about doing that ;-)

But shouldn't there be a specification first ?

For primitives, have a look at JSON, don't make it more complicated than that.

Taking your last two sentences I would conclude that then we are yet reinventing the wheele again? I think noone has still say which is the big problem of using JSON. The answer "we need a parser" is not enough. You will need a parser for the literal array also. Dale said the parser for JSON was decoupled from Seaside and quite small. So...can someone tell me the real problem with numbers and facts please? -- Mariano http://marianopeck.wordpress.com