Now, this is something cool, I think. Let’s investigate this further. One issue is whether the Pragma class should be modified to take into account the new semantics.
Cheers, Doru > On Sep 20, 2016, at 10:41 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > 2016-09-19 16:24 GMT+02:00 Henrik Johansen <henrik.s.johan...@veloxit.no>: > >> On 19 Sep 2016, at 4:03 , Henrik Johansen <henrik.s.johan...@veloxit.no> >> wrote: >> >>> >>> On 17 Sep 2016, at 4:17 , Ben Coman <b...@openinworld.com> wrote: >>> >>> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaih...@gmail.com> wrote: >>>> >>>> >>>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>: >>>>> >>>>> Hi All, >>>>> >>>>> >>>>> >>>>> _,,,^..^,,,_ (phone) >>>>>> On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.den...@inria.fr> >>>>>> wrote: >>>>>> >>>>>> >>>>>>>> >>>>>>>> We can change it back and maybe add support for the reformatter to not >>>>>>>> convert it to the literal array #(3 #+ 4) . >>>>>>> >>>>>>> I do not know in fact this is why I asked :) >>>>>>> Now may be my idea to use pragma to get something like pythondoctest is >>>>>>> a bad idea >>>>>>> but I really want to have literal programming. >>>>>>> What do you think? >>>>>> I like the idea to show examples/tests close to code, but pragmas are >>>>>> not really good... >>>>>> >>>>>>> If we have ' ' then it would be good that the syntax higlighter works >>>>>>> with a special mode inside the ' ' >>>>>> >>>>>> it is just a string. How do you know that it contains code? >>>>>> >>>>>> Would you highlight all string in all code as if it contained code? Or >>>>>> would you add this just for >>>>>> Pragmas? But even there, strings are string, not code. >>>>>> >>>>>> I think we can conclude that pragmas are not a good solution to the >>>>>> problem, as they are far >>>>>> too limited to express code. >>>>> >>>>> I think that's not a safe conclusion. We know from Igor's use of Kieran >>>>> arrays for C signatures in the UFFI, and can easily extrapolate here, that >>>>> arbitrary Smalltalk expressions /can/ be expressed in literal arrays. S >>>>> expressions work for lisp. >>>>> >>>>> In this particular case special casing pretty printing of literal arrays >>>>> in pragmas would be all that's needed to make the code look beautiful. >>>>> Why >>>>> throw the baby out with the bath water? It would be so easy to make this >>>>> work well. >>>> >>>> >>>> We can try this as well. And it is far more easier to work with this >>>> expressions if they are pragma arguments, than to parse the comment to find >>>> some code within. >>>> On the other hand, it looks much nicer if we have the examples right in the >>>> method doc. you have some text describing the method, some code, some more >>>> text about the reslt. >>>> >>>> >>>>> >>>>> >>>>> The only thing I'd do would be to print like this to make it clear that >>>>> the argument t is a literal Array and not some magic form of code: >>>>> >>>>> <expr: #(3 + 4) result: 7> >>>>> >>>> >>>> Yes, I would like to change this anyway, even for literal arrays for ffi, >>>> calls like >>>> >>>> mouseStateX: x y: y >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>>> errorCode> >>>> ^ self nbCall: #( Uint32 SDL_GetMouseState ( int* x , int* y ) ) >>>> >>>> this will be reformatted to >>>> >>>> mouseStateX: x y: y >>>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >>>> 'errorCode'> >>>> ^ self nbCall: #(#Uint32 #SDL_GetMouseState #(#int #* #x #, #int #* #y)) >>> >>> errr, yuck! Thats not pretty at all. Is there some way to avoid >>> that? As I've been getting started with FFI its been really nice >>> visually to see a *direct* correspondence between the C header file >>> declaration and the in-Image method. >> >> +1, that's about the main thought behind it... >> As long as the only required use of a # inside of literal arrays is >> differentiating whether something is a literal string or symbol, changing to >> format *all* symbols using it seems somewhat overzealous. >> >> Personally, if a solution using method properties/+ browser improvements to >> show/create them in a good way is out of the question, >> I have a weakness for using empty blocks as method-local, syntax-highlighted >> code comments (at least compared to special comment syntax, or pragmas >> backed by a whole literal -> ST parser). >> Though lately, the code critic (rightly, and very usefully, in the cases >> where it's a user error) points out they are dead code, and the IR optimizes >> them out entirely, meaning they miss out on >> senders/implementors/refactorings functionality. (Full blocks would >> potentially let us change the IR to leave them alone, put them in the >> literal slot and be searchable, at no additional runtime-cost/use in >> bytecodes) >> >> Cheers, >> Henry > > Now imagine if tags were scoped, and you could do > > Number >> #+ aNumber > <prim ....> > [ <insertInlineExampleTagNameHere> 3 + 4 == 7 ]. > ^self fallbackAdd: aNumber > > And have the browser pick it up, and either > - collapse it > - display text with alpha < 1 > > Make the code critic aware as well, and no more warnings of unused blocks > when used for examples! > > Cheers, > Henry > > Hm, dead blocks, nice idea. > > see attached cs, you can file it in and have to uncomment one line in > RBParser>>#parseBlock (the parsePragmasInto: aNode line) > to activate pragmas in blocks, now you can add a "dead block" like > > [<example> 3+4] > > and the icon styler lets you execute (inspect) the code. > (Just a quick and dirty implementation) > > > > <exampmle_blocks.cs><example_blocks.png> -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."
