On 5/9/12, Göran Krampe <[email protected]> wrote: > 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. +1, makes sense and it partially self-explaining.
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 > >
