> 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 
> <mailto: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)


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

Reply via email to