Hi Stephane and all!
On 05/09/2012 08:29 AM, Stéphane Ducasse wrote:
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.
Good, agreement. :)
[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 :)
...then why did you write "then this is not a literal array anymore". I
was presuming that you meant "because => is not a literal syntax, it is
a message". But perhaps you meant something else?
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
Ok, regarding changing the syntax of Smalltalk:
- Personally I don't care that much for ANSI. It's dead. I think
Smalltalk needs to evolve and bloody hell, you have *Traits* in Pharo,
that is a HUGE difference compared to a bit of literal changes. ;)
- If we *do* decide to "Hey, let's take a look at our literal syntax",
then we should probably see if we can harmonize a bit. Again, see my
article for some thoughts in that area.
I agree that Smalltalk literals are quite powerful but I think they can
be improved.
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.
I don't follow. JavaScript has literal syntax for Arrays and Objects.
And yes, "Dictionaries" and Objects are the same in js, although it's
limited to only string keys etc.
In Smalltalk we have literal syntax for Arrays (three different ones
even) but none for Dictionaries. Why do you say that adding syntax for
Dictionaries looks like a "patch" but having syntax for Arrays is
perfectly fine? What is the distinguishing feature of Array that makes
them so different?
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:
How do you know "what I want" when you don't read the article? Or have
you read it now?
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.
Sure, limited. But that is the whole point of literals, that they are
limited. And in the case of Smalltalk of course - that they are actually
evaluated and constructed at *compile time* and not at run time, that is
also a very important aspect.
but in that case why don't we use literal syntax for objects?
Why stopping at Dictionary.
This kind of argument is not fruitful.
If you ask me I would remove #() as a syntactic elements because most of the
time { } is what you want.
Well... The fact that #() are constructed at compile time is a BIG
difference. So I still think both constructs are useful.
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….
Again, not fruitful.
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.
I know, but I/we are not discussing that here. Ok? I know it was the
seed of all these threads but THIS thread is not about that.
For me personally this sums it up fairly well:
- It would be nice with a strong, heavily supported fast and slick
implementation of JSON. If STON can be that (superset of JSON) then I
support Sven all the way to the moon! For Smalltalk source code meta
data? No, personally I would also prefer literals I guess. Or Tirade :)
- Tirade covers a different spectra. People get stuck on its name, for
whatever reason, call it "Cascade" if it makes you happy. I think it is
quite interesting in its capabilities and if anyone wants to help me
evolve it more, please do. It was after all created because I felt the
need for a good format for Deltas and JSON failed the test (strings in
JSON can't have linefeeds!!!).
- Smalltalk should not be set in stone. The literal syntax of Smalltalk
has a bit of "warts" and it would be awesome if Pharo (with all its
momentum) could go forward and say "Hey, let's take another step
forward!" and try to bring it up a notch. That would involve both
perhaps simplifying, harmonizing and making it a tad more powerful.
This last part is something that got evident to me after working with
Tirade (felt the lack of Associations there) and later with Amber (which
also felt a strong lacking in the same area when trying to mix with js).
I will try to write some kind of separate posting on that subject, and
see if it "sticks to the wall".
Now... Stef - I like you a lot and if you want to discuss this last part
constructively I am all game. But hey, if you just want to shoot down
everything we say, without even giving it a second thought or (gasp!)
taking the time to read - then I do have better things to do.
regards, Göran
