> 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 
> <mailto:esteba...@gmail.com>>:
> >
> >
> >> On 16 Sep 2016, at 21:45, 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))
> >
> >
> > 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 :)

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

Reply via email to