Hi Frank - I'd appreciate if you can send me those mcz - I am trying to figure out how Monticello works and that would be helpful.��

As far as I remember one of the sources of imprecision in Squeak was the treatment of block variables or block arguments (can't remember exactly), which was in my to-do list that never got done.��

I know there has been work in the Compiler in Pharo and that block and Closures were a hot topic. Is that now fixed in Pharo?

Sorry, if the above is a generic question. But I can't remember exactly what was wrong with the blocks in Squeak. I did notice that the #isArg: method was removed in Pharo.��

Cheers,��
Francisco

PS: I am thinking in giving the Type Inference project a name: Telar or Tilar.��

Telar means Loom in Spanish and it gives the idea of the interwoven data and control flow of Smalltalk (or any other OO language).��

I also just learn that Loom in Arabic is pronounced Nul or (��������������)��

On 3 April 2012 21:56, Frank Shearar <frank.shearar@gmail.com> wrote:
On 30 March 2012 22:19, Frank Shearar <frank.shearar@gmail.com> wrote:
> In case anyone's interested in the paper behind Francisco's work
> (thanks Francisco!), you can find "Concrete Type Inference: Delivering
> Object Oriented Applications" here:
> https://labs.oracle.com/technical-reports/1996/smli_tr-96-52.pdf
>
> Interestingly, typing 'Display boundBox' fails in Squeak trunk because
> "UndefinedObject won't understand #origin:corner:". Odd, since
> evaluating same will happily return a Rectangle. I'll look into it and
> see what I can find.

It turns out that in Pharo we use Association and in Squeak we use
ReadOnlyVariableBinding; by changing VariableNode >> #isSharedVarNode
to

isSharedVarNode
�� ��^ self type = 4 and: [key isVariableBinding]

TypeInference works in both!

Now I have some mczs, but I don't have a place to publish them...

frank

> frank
>
> On 30 March 2012 14:33, Francisco Garau <francisco.garau@gmail.com> wrote:
>> No unit tests, sorry...
>>
>> Is not profiling, it's abstract intrepretation using types instead of
>> objects.
>>
>> - Francisco
>>
>>
>> On 30 Mar 2012, at 15:15, Alexandre Bergel <alexandre.bergel@me.com> wrote:
>>
>> Hi Francisco,
>>
>> I've tried your implementation. It seems to work in Pharo 1.4. Do you have
>> unit test somewhere?
>> How does your profiler work? From what you have said in your email, it seems
>> you are profiling the execution. Is that true?
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 29 Mar 2012, at 18:47, Francisco Garau wrote:
>>
>> Load the attached ChangeSets: first Ti-Engine and then Ti-Support.
>>
>> You could then evaluate the below expressions -- watch the Transcript to see
>> which methods are being analysed.
>>
>> TiSystem current reset.
>> string := '3 + 4'.
>> Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1].
>> "=> return {<SmallInteger>} "
>>
>> TiSystem current reset.
>> string := 'Display boundingBox'.
>> Compiler new analyze: string in: nil to: nil notifying: nil ifFail: [1].
>> "=> return {<Rectangle origin: <Point x: <SmallInteger> y: <SmallInteger>>
>> corner: <Point x: <SmallInteger> y: <SmallInteger>>>}"
>>
>> TiSystem current explore.
>>
>>
>> Analysing 'Display boundingBox' shows a couple of surprises:
>>
>> The code never goes through the #new method (it creates objects using
>> #basicNew and #@)
>> Object code goes through Object>>value but knowing that the implementation
>> just answers self, it could be easily optimised.
>>
>>
>> I will try to package it more nicely under Monticello -- there are still a
>> few rough edges that need to be polished before getting it to the same state
>> it was in 2001...
>>
>> Cheers,
>> Francisco
>> <Ti-Engine.2.cs><Ti-Support.2.cs>
>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel����http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>