Sven, I see that you have already gone beyond a simple literal array style syntax and it looks like you've headed into YAML territory? ... I'm seeing lots of []... the nice thing about YAML is that they've eliminated a lot of the excess syntactic characters which makes it very readable. The real test for readability would be a variety of sample documents... Dale ----- Original Message ----- | From: "Dale Henrichs" <dhenrich@vmware.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 9:18:26 AM | Subject: Re: [Pharo-project] SimpleLiteralArray Spec | | Sven, | | I know that having the parser produce dictionaries (i.e., dictionary | _syntax_) is very convenient for the consumer of the parsed output | ... | | When javascript evaluates/parses JSON, you will note that you get | real objects back instead of dictionaries and you can send messages | to those objects, so I would think that rather than inventing a | dictionary syntax, you invent a STON-object syntax then we can then | send setter/getter style messages to these boys... then we'd have | _objects_, arrays, strings, numbers and booleans for the STON format | ... a field could be optionally included in the STON object called | _class_ which would optionally allow the parser to produce instances | of that class with all of the fields filled in ... | | JSON on steroids! | | Anyway ... just a thought. | | Dale | | ----- Original Message ----- | | From: "Sven Van Caekenberghe" <sven@beta9.be> | | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | | Sent: Tuesday, April 24, 2012 4:26:12 AM | | Subject: [Pharo-project] SimpleLiteralArray Spec | | | | 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 | | 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 | | 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 | | 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 ? | | - what about symbols without a leading # ? | | - what should be allowed in unquoted symbols ? | | - what should be allowed for classnames ? | | - what about namespaces ? | | - do we allow infinite precision integers ? | | - maybe the toplevel should always be an array ? | | | | | | Now: shoot! | | | | | | Sven | | | | | | -- | | Sven Van Caekenberghe | | http://stfx.eu | | Smalltalk is the Red Pill | | | | | | | | | | | | | |