On Sat, Sep 17, 2016 at 3:45 AM, 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))
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
