On Sat, Sep 17, 2016 at 3:45 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-09-16 18:42 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi All,
_,,,^..^,,,_ (phone)
On Sep 14, 2016, at 10:50 PM, Marcus Denker <marcus.denker@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. Actually I think it would be useful to go a step further to have positional rather than named parameters for FFI methods. At the moment the method names still end up a bit mangled. This seems feasible since currently an open-round-bracket is invalid syntax if not preceded by an assignment or colon. e.g. myvar := (a + b). "okay" self setVar: (a + b). "okay" self setVar( a + b ). "currently invalid syntax - but could could represent an FFI call" defined like... SomeLibrary class >> setVar( newValue ) ^ self ffiCall: #( int setVar ( int newValue ) But I expect its not something we'd want to leap into. cheers -ben