> 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 > <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. Esteban > > > > > > > Marcus > > > > > > > > > > > > > >
