> 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!


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to