Am 19.09.2016 4:14 nachm. schrieb "Esteban Lorenzano" <esteba...@gmail.com>:
>
>
>> On 16 Sep 2016, at 21:45, 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))
>
>
> this is ugly… also, it breaks the spirit of UFFI where the purpose of
using the array literals to give a feeling close to the C method.
> I already told before I disagree with this reformatting…. So no, I’m
absolutely against forcing such kind of format.

Where and when did you disagreed?
I always thought this behavior of the formatter was like that from the
beginning, and it wasn't changed afterward.

My suggestion was, to change the formatter to *not* reformat these literal
arrays, so we could at least use a pragma like
<expr:#(3+4) res: 7>
And don't have to use quotes. Or the ugly literal array form #(3 #+ 4)

>
> Esteban
>
>>
>>
>>
>>>
>>> >
>>> >    Marcus
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>

Reply via email to