Smalltalk › Squeak › Squeak - Dev

NewCompiler and Preferences compileBlocksAsClosures

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Klaus D. Witzel

NewCompiler and Preferences compileBlocksAsClosures

List,

the value of Preferences compileBlocksAsClosures can have a meaning

- for a single or a group of methods
- for all methods of one or more classes
- for the lifetime of the current session
- forever

It is easy to predict problems when a method was compiled with Preferences
compileBlocksAsClosures set true and, after it was distributed, whoever
loads it has Preferences compileBlocksAsClosures set false.

Wouldn't it be time to make Preferences compileBlocksAsClosures a pragma
(a method property), in the sense of a compiler directive, in the scope of
the method being (re-)compiled.

/Klaus

Marcus Denker

Re: NewCompiler and Preferences compileBlocksAsClosures

On 16.10.2006, at 10:51, Klaus D. Witzel wrote:

> List,
>
> the value of Preferences compileBlocksAsClosures can have a meaning
>
> - for a single or a group of methods
> - for all methods of one or more classes
> - for the lifetime of the current session
> - forever
>

If you set this preference to true, new methods are compiled with the
closures. Even when you turn it off, these methods keep on having
closure semantics.

> It is easy to predict problems when a method was compiled with
> Preferences compileBlocksAsClosures set true and, after it was
> distributed, whoever loads it has Preferences
> compileBlocksAsClosures set false.
>

Yes.

> Wouldn't it be time to make Preferences compileBlocksAsClosures a
> pragma (a method property), in the sense of a compiler directive,
> in the scope of the method being (re-)compiled.
>

I don't think this is that good... we want to be able to recompile
the whole image with closures without needing to put a pragma in all
methods.

Marcus

Stephan Rudlof

Re: NewCompiler and Preferences compileBlocksAsClosures

On 16.10.2006 15:09, Marcus Denker wrote:

>
> On 16.10.2006, at 10:51, Klaus D. Witzel wrote:
>
>> List,
>>
>> the value of Preferences compileBlocksAsClosures can have a meaning
>>
>> - for a single or a group of methods
>> - for all methods of one or more classes
>> - for the lifetime of the current session
>> - forever
>>
>
> If you set this preference to true, new methods are compiled with the
> closures. Even when you turn it off, these methods keep on having
> closure semantics.
>
>> It is easy to predict problems when a method was compiled with
>> Preferences compileBlocksAsClosures set true and, after it was
>> distributed, whoever loads it has Preferences compileBlocksAsClosures
>> set false.
>>
>
> Yes.
>
>> Wouldn't it be time to make Preferences compileBlocksAsClosures a
>> pragma (a method property), in the sense of a compiler directive, in
>> the scope of the method being (re-)compiled.
>>
>
> I don't think this is that good... we want to be able to recompile the
> whole image with closures without needing to put a pragma in all methods.

What about two preferences
- compileBlocksAsClosuresDefault (default false, for methods without pragma and pragma value "followPreference")
- forceCompileAllBlocksAsClosures (default false with no effect then; overriding pragma and previous pref, if true)
, with a pragmaCompileBlocksAsClosures having three possible values
- true (overriding compileBlocksAsClosuresDefault),
- false (overriding compileBlocksAsClosuresDefault) or
- followPreference (following compileBlocksAsClosuresDefault)
?

Stephan

>
> Marcus
>
>
>

--
Stephan Rudlof ([hidden email])
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3

johnmci

Re: NewCompiler and Preferences compileBlocksAsClosures

I'm wondering here if anyone has thought about writing some code that
attempts to figure out if a given block is changed from the current
implementation to having closure
if that would affect the results of the block evaulation. Going
forward if you turn on forcecompileallblocksasclosure then how would
you know if it would have side-effects or not
in a random method in the base image?

On 16-Oct-06, at 1:33 PM, Stephan Rudlof wrote:

>
> What about two preferences
> - compileBlocksAsClosuresDefault (default false, for methods
> without pragma and pragma value "followPreference")
> - forceCompileAllBlocksAsClosures (default false with no effect
> then; overriding pragma and previous pref, if true)

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Stephan Rudlof

Re: NewCompiler and Preferences compileBlocksAsClosures

On 16.10.2006 22:59, John M McIntosh wrote:
> I'm wondering here if anyone has thought about writing some code that
> attempts to figure out if a given block is changed from the current
> implementation to having closure
> if that would affect the results of the block evaulation.

> Going forward
> if you turn on forcecompileallblocksasclosure then how would you know if
> it would have side-effects or not
> in a random method in the base image?

I assume the wish to have something like forceCompileAllBlocksAsClosures arises from the need to answer this question by test runs: e.g. the result of the block evaluation may depend on how often the block is used, and this may be user/use dependent...

Marcus?

Stephan

>
> On 16-Oct-06, at 1:33 PM, Stephan Rudlof wrote:
>
>>
>> What about two preferences
>> - compileBlocksAsClosuresDefault (default false, for methods without
>> pragma and pragma value "followPreference")
>> - forceCompileAllBlocksAsClosures (default false with no effect then;
>> overriding pragma and previous pref, if true)
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>

--
Stephan Rudlof ([hidden email])
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3