> 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 >> <mailto:b...@openinworld.com>> wrote: >> >> On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaih...@gmail.com >> <mailto:nicolaih...@gmail.com>> wrote: >>> >>> >>> 2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com >>> <mailto:eliot.mira...@gmail.com>>: >>>> >>>> Hi All, >>>> >>>> >>>> >>>> _,,,^..^,,,_ (phone) >>>>> On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.den...@inria.fr >>>>> <mailto: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
signature.asc
Description: Message signed with OpenPGP using GPGMail
