2016-09-19 19:14 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:

>
>
> 2016-09-19 17:08 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>>
>> On 19 Sep 2016, at 16:49, Nicolai Hess <nicolaih...@gmail.com> wrote:
>>
>>
>> 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)
>>
>>
>> ah, then we agree :)
>>
>>
> Generally speaking, reformatting 16rF0F0 into 61680 is never going to be a
> good idea.
> Same for carefully aligned arrays
>   #(
>      #( 16r00 16r01 16r03 16rFF )
>      #( 16r00 16r01 16r03 16rFF )
>    )
> or #[
>         16r00 16r01 16r03 16rFF
>         16r00 16r01 16r03 16rFF
>    ]
>

Pharo now uses RBParser and a formatter based on RBParsers AST-Nodes, and
here, at least the number format is preserved, but not the layout of
the array.

foo
|a b|
a := #[ 16r00 16r00 16rFF].
b := #(
       #(1 0 0)
       #(0 1 0)
       #(0 0 1)).

will be formatted to

foo
    | a b |
    a := #[16r00 16r00 16rFF].
    b := #(#(1 0 0) #(0 1 0) #(0 0 1))



>
> The canonical representation for these is absolutely unhelpful for a human.
> The formatting expresses an intention (for example some data structure to
> which the Array will be mapped...).
> You can see plenty examples of things that should not be reformatted in
> VMMaker.
>
> >
>> > Esteban
>> >
>> >>
>> >>
>> >>
>> >>>
>> >>> >
>> >>> >    Marcus
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> >>
>> >
>>
>>
>>
>

Reply via email to