>>
>> Parsing and compiling + execution are three different actions.
>> Parsing: stream -> tokens* but you know it.
>
> Of course. What I mean is that depending on how you "parse" a Smalltalk
> literal you may or may not be susceptible to a security hole. If you just
> blindly use the full Compiler to do the whole thing - then you have a hole.
> If you do not, then you don't. Igor showed a neat way to only use the literal
> array part of the parser - fine, no hole. But if you just use full Compiler -
> not fine.
yes so using literal array does not bring any security problems.
Or we should say stupidly using the compiler introduces security problems and
so far I never advocate for that.
> [SNIP]
>>> My point is that it would be nice if we actually had proper syntax for
>>> Associations (and or Dictionaries).
>>
>> OK I see. But what I want to say is that then this is not a literal array
>> anymore.
>> Literal means that you only need a parser and no execution to get the
>> information. Parse time.
>
> But Stephane... please *read* what I write in the article. Let me repeat:
>
> #-> is a message in Smalltalk, not a literal syntax.
Not in my compiler :)
> We all know that.
>
> BUT... there is nothing preventing us from adding support in the Smalltalk
> parser to handle this as a *literal* syntax that creates an Association.
and what else?
So people want ANSI compatibility and at the same time new syntax
> Tirade has support for it and a large part of the article talks about this,
> but I presume you have not read it.
>
>> Now I would like to know the use case for a dictionary syntax or association.
>
> There are TONS of use cases. The whole success behind JSON is IMHO based on
> the fact that it has explicit syntax for *both* arrays and dictionaries
> (called "objects" in JavaScript). Nested structures of these two building
> blocks is a very potent combination. And Smalltalk literal arrays only give
> us ONE of them.
Not only arrays and dictionaries. Just plain objects and this is a key
difference!!!!!
Dictionaries are not objects in Smalltalk so adding dictionary looks to me like
a patch.
>
>> May be you mean that you want to have the equivalent of { } but for
>> dictionary, why not.
>
> Sigh. "Maybe"? Ok, things would be MUCH simpler if you actually read the
> article you know. And no, not really, because {} is a *dynamic* array with
> expressions in it and I am talking about (primarily) *literal* dictionaries.
ok I was talking about the syntactic aspect of having { } instead of writing
Array new:
because this is what you want
{|%
instead of Dictionary newFrom:
>> Having a syntax for a syntax is not really exciting.
>
> What?
>
>> Now I think that the key problem is dealing with reference between
>> elements. for that STON can be better because why stopping at dictionary?
>> But then the next question if we go down this
>> road is why don't we add this syntax to smalltalk so that we can create
>> literals objects like in Javascript.
>> I mean without message send because this is exactly that no?
>> What is the difference between
>> Dictionary new add: #flop put: 33 ;yourself
>> and
>> {|% flop : 33 %|}
>>
>> or Person {
>> name : 'stef'
>> }
>
> The difference? Well, the first is an imperative Smalltalk program (fully
> insecure of course since I presume you would parse and execute it as full
> Smalltalk) and the second two are declarative literal syntaxes that are safe
> to parse.
You could also say quite limited because you can only put dictionary inside
dictionary and literals. so no objects.
but in that case why don't we use literal syntax for objects?
Why stopping at Dictionary.
If you ask me I would remove #() as a syntactic elements because most of the
time { } is what you want.
>> then this is not really Smalltalk anymore and we cannot say that we only
>> have messages and the parser and ….
>> have to be changed…. This is why I asked what is the use case.
>
> Your reasoning is very... confusing. What do you mean "only have messages" -
> we *already* have a whole bunch of literal syntax for creating objects. What
> makes a Dictionary so special compared to Arrays?
so Dictionary and Set and why not objects….
>
> And "not really Smalltalk anymore"... ehm, I give up.
>
> Anyway, my article mainly says that Smalltalk literals go a long way BUT
> without the support for Dictionaries they fall short of JSON, and that is a
> bit of a shame I think. But still - the article was mainly food for thought -
> I am not fighting a battle here, I am just exploring.
>
>> Finally and I still did not get a clear answer: why there is a need for
>> dictionary syntax to store method meta data.
>
> Can you please stop referring to "method meta data" all the time? This thread
> is about an article I wrote that you haven't read and it has nothing to do
> with that use case. Ok?
Because I do not care if you want to use STON, JSON XML for your own program
this is your choice. I care that I will have
to load JSON, STON in core to load or save code and that I have to use a
different syntax to look at code in Git.
>
> regards, Göran
