Proposal for Extensible Primitives (was: FFI)

> Stef,
>
> To be sure it is possible that my reactions to the arguments are  
> the result
> of naivety.  I am not aware of much of the past history and I have not
> reviewed the relative parser implementations.  I will back off and let
> Andreas and Lukas discuss the details.
>
> From my perspective, as limited as it is, there have not been enough
> arguments about the benefits of the change itself.  I'm sure the  
> pragma
> implantation is quite good based on your judgement but what does  
> that have
> to do with FFI.  Using the pragmas implementation for FFI doesn't  
> add or
> remove anything from pragmas.  What I can say is that FFI on  
> windows works
> well and that the differences suggested for the api are minor but the
> compatibility issues are major.
>
> For me there would have to be a really good reason to want to  
> change the api
> for FFI and the arguments I've heard are just not good enough.  IF  
> we could
> consolidate the implementation without changing the api I would  
> have no
> opinion about this issue accept to point out that FFI as far as I know
> belongs currently to Andreas.
>
> Lukas should aggressively pursue his line of argument so that we  
> can fully
> understand the benefits of what he is proposing.  Lukas and Andreas  
> are both
> very talented and we would be very foolish not to listen to either  
> of them.
>
>
> Let's leave politics behind; argument and discussion that leads to a
> solution is good for the community and for Squeak.  We don't all  
> have to
> agree, we don't need consensus, we need to make sure everyone is  
> heard, make
> a decision and then move on.  Like I said the decisions should come  
> from
> Andreas and Lukas.
>
> Ron
>
>> From: stéphane ducasse
>> Sent: Wednesday, August 16, 2006 4:53 PM
>> Ron
>>
>> do not be naive. I asked explicitly to lukas to show his approach to
>> get a MUCH cleaner system and we were sure that andreas
>> would react that way because we are idiots. So let us be idiots!
>>
>> Now I think that taking advantage of pragmas (because you know that
>> lukas did all the implementation of pragmas even arguing
>> with andreas that he was wrong on certain comments of this
>> implementation - this was offline but his happened and lukas was
>> right and the implementation of lukas is much better than the one of
>> andreas in tweak) would be something to have and discussing how a
>> ***smooth transition*** plan could have been prepared. We are not
>> saying that everything should change, but preparing to change
>> is sometimes really important. Else we would all be programming in
>> assembly because it worked.
>>
>> But what lukas said is bullshit of course!
>>
>> Stef
>>
>>
>> On 16 août 06, at 18:18, Ron Teitelbaum wrote:
>>
>>> +1
>>>
>>> The arguments presented are not sufficient in my opinion to warrant
>>> the
>>> change.
>>>
>>> In general the amount of difference in the interface that is
>>> suggested is
>>> trivial when compared to the amount of learning necessary to use  
>>> FFI.
>>> Consistency does not appear to me to be a valid argument.
>>>
>>> Considering the alternatives presented by Andreas that allows this
>>> minor
>>> difference in syntax while satisfying requirements for isolation, I
>>> would
>>> say it's better to leave current systems working and the current
>>> syntax as
>>> is even if it is slightly different than pragmas.  Isolation of
>>> code and
>>> removing of unnecessary code when FFI is unloaded does not appear
>>> to be a
>>> valid argument considering alternatives discussed.
>>>
>>> I understand the original stated goal is to unify the parser and
>>> clean up
>>> the parsing code, but in general that doesn't seem to be enough  
>>> of an
>>> argument to change the interface of working systems.  Can the two
>>> parsers be
>>> combined without changing the FFI syntax?
>>>
>>> Ron Teitelbaum
>>>
>>>> -----Original Message-----
>>>> From: [hidden email] [mailto:squeak-
>>>> dev-
>>>> [hidden email]] On Behalf Of Andreas Raab
>>>> Sent: Wednesday, August 16, 2006 11:36 AM
>>>> To: The general-purpose Squeak developers list
>>>> Subject: Re: Proposal for Extensible Primitives (was: FFI)
>>>>
>>>> stéphane ducasse wrote:
>>>>> would not be possible to have a plan for a smooth transition even
>>>>> with
>>>>> the two approaches happily living side by side?
>>>>
>>>> A transition implies that the proposed change is desirable or
>>>> necessary.
>>>> This is not the case. The idea to change the syntax of the FFI is a
>>>> classic "fresh from the ivory tower" idea, neglecting the
>>>> realities of
>>>> an already deployed, perfectly working and functioning system.
>>>>
>>>> Sorry but changing FFI syntax ain't gonna happen on my watch.
>>>>
>>>> Cheers,
>>>>   - Andreas
>>>>
>>>>>
>>>>> Stef
>>>>>
>>>>> On 16 août 06, at 09:41, Andreas Raab wrote:
>>>>>
>>>>>> Lukas Renggli wrote:
>>>>>>>> Let's repeat the last part: "while explicitly preserving its
>>>>>>>> meaning
>>>> or
>>>>>>>> behavior". Not to break things. I'm perfectly cool with that.
>>>>>>> Unfortunately my suggestion is no refactoring from your point
>>>>>>> of view,
>>>>>>> it breaks backward compatibility.
>>>>>>
>>>>>> It's not "from my point of view", but rather "by definition" of
>>>>>> what
>>>>>> refactoring means. I have really come to dislike how the term
>>>>>> "refactoring" is abused on this list to mean "explicitly breaking
>>>>>> code" instead of what it means, namely explicitly NOT breaking
>>>>>> code.
>>>>>>
>>>>>> So, let's be clear: You are not talking about a refactoring.  
>>>>>> If you
>>>>>> were, I'd be cool. You are talking about a fundamental and
>>>>>> incompatible change to the FFI. And I'm not cool with that.
>>>>>>
>>>>>>> I am not in favor of keeping backward compatibility, in most
>>>>>>> cases it
>>>>>>> makes things worse and there are already plenty of bad  
>>>>>>> examples in
>>>>>>> Squeak.
>>>>>>
>>>>>> Sure. Depending on the circumstances, e.g., how big your
>>>>>> investment in
>>>>>> Squeak has been and how reliant you are on a specific subsystem,
>>>>>> that
>>>>>> may be a fine option for you. Not all users of Squeak are that  
>>>>>> way.
>>>>>> And while I'm not against change in general, I will insist that
>>>>>> changes that introduce fundamental incompatibilities must be
>>>>>> carefully
>>>>>> weighed against the benefits they bring.
>>>>>>
>>>>>> Otherwise, hey, I'm willing to "refactor" Squeak to use proper
>>>>>> static
>>>>>> typing, which will make the code "more extensible", "cleaner" or
>>>>>> whatever attributes of choice you've been recently using. And
>>>>>> all you
>>>>>> need to do is to rewrite every single method declaration which
>>>>>> seems a
>>>>>> fair deal since you're requesting the same from the FFI users.  
>>>>>> See
>>>>>> what I mean? ;-)
>>>>>>
>>>>>>> The following presentation of Gilad Bracha might be  
>>>>>>> interesting to
>>>>>>> read, especially the end of the presentation where it says:
>>>>>>> "Rotting
>>>>>>> Bits for a better World -- A model which expects
>>>>>>> incompatibility as a
>>>>>>> matter of course is better than denying change."
>>>>>>>     http://www.bracha.org/oopsla05-dls-talk.pdf
>>>>>>
>>>>>> As usual, a thought-provoking presentation from Gilad. He is
>>>>>> certainly
>>>>>> right that being prepared for change instead of denying it is the
>>>>>> better strategy - whether that means to entirely drop having any
>>>>>> negotiated interfaces however, stands very much to reason.
>>>>>> Personally,
>>>>>> I find that a necessary requirement to be able to deal with  
>>>>>> change.
>>>>>>
>>>>>> Cheers,
>>>>>>   - Andreas
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>

> > of naivety.  I am not aware of much of the past history and I have not
> > reviewed the relative parser implementations.  I will back off and let
> > Andreas and Lukas discuss the details.
>
> Please don't. We have too little user perspective in this discussion. As
> a maintainer, I will be perfectly happy to change things if there are
> FFI users requesting changes (and if they are within my abilities to
> change). So rather than listening to Stefane's insults I'd like to get
> more feedback from FFI users, in particular with respect to the
> following questions:
>
> If you are an FFI user and like the proposed changes:
> a) Where do you see the advantage of it for your work? How would you
> describe the value added? How would you argue to convince someone else
> that their code should be changed to the new model?
> b) Since there is room for ambiguity in supporting the current FFI spec
> and the proposed changes, do you think both styles should be supported
> for an intermediate period?
>     b1) If yes, for how long?
>     b2) If no, how do you propose to deal with migration?
> c) Given the choice, would you rather have an "inplace" change or
> perhaps an alternative version of the foreign function interface, aptly
> called FFII (pronounce as FF-2)?
>
> Cheers,
>    - Andreas
>