2012/4/4 Frank Shearar <frank.shearar@gmail.com>

On 4 April 2012 12:15, Francisco Garau <francisco.garau@gmail.com> wrote:
> 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.

Attached! fbs.1 is the result of my loading your two changesets into a
clean image and moving the -Support extensions to the *TypeInference
category. (So for example all the #mirrorIn: implementations were in
'type inference' and are now in '*TypeInference' so that Monticello
can recognise they're in the TypeInference package.)

I didn't keep all the method changes to Set: if Sets need their
behaviour adjusted, we should fix Set directly, rather than from this
package.

fbs.2 just adds the change I described earlier: I replaced "key class
== Association" with "key isVariableBinding".

One thing the package definitely needs is a large test suite :) That
would also let someone assess whether they've hit a known limitation
of the inference engine or a bug. For example, analysing 'n := 2. n
log' told me that "UndefinedObject would not understand #contextTag"
and I'm unsure why a MethodContext (the only implementor of
#contextTag) would be involved in calculating a log.

frank

> 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
>> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>