non-activatable blocks?

I just extended per-object support for turning on/off activation
behavior to Blocks. "Activatable" refers to whether or not an value
"activates" when the slot it is in is accessed. For example, these
changes allow you to do this:

Io> b := block(123)
Io> b
==> 123

Io> getSlot("b") setIsActivatable(false)
Io> b
==> block(123)

Io> b call
==> 123

Now the question is, should we make this the default for Block's
created with block()? (Blocks created with method() would still be
activatable by default).

Cheers,
- Steve

On 14-Jul-06, at 9:55 PM, Steve Dekorte wrote:

>
> I just extended per-object support for turning on/off activation
> behavior to Blocks. "Activatable" refers to whether or not an value
>; "activates" when the slot it is in is accessed. For example, these
>; changes allow you to do this:
>;
> Io> b := block(123)
> Io> b
> ==> 123
>
> Io> getSlot("b") setIsActivatable(false)
> Io> b
> ==> block(123)
>
>; Io> b call
> ==> 123
>
> Now the question is, should we make this the default for Block's
> created with block()? (Blocks created with method() would still be
> activatable by default).

Perhaps we could add another constructor, "function" which is like
block (lexically scoped) but activates by default, and blocks need to
be explicitly call()ed.

Just a thought.

> - Steve

--
Jeremy Tregunna
jtregunnablurgle.ca

";One serious obstacle to the adoption of good programming languages
is the notion that everything has to be sacrificed for speed. In
computer languages as in life, speed kills." -- Mike Vanier

Cool!

Any chance of getting rid of the distinction between block and
method, then? We could have one base object covering both, with
slots setting whether it's activatable and whether its context is
lexically scoped. I realise it's a bit late to make such a major
change, but

(a) it goes with Io's general philosophy of keeping the core language
simple, and

(b) it would be easy to implement backwards compatibility with (e.g.)
block := method clone setLexicalScope.

Jason

Hi Jason,

On 7/15/06, Jason Grossman <Jason.Grossmanstaff.usyd.edu.au&gt; wrote:
&gt; Cool!
>;
> Any chance of getting rid of the distinction between block and
> method, then? We could have one base object covering both, with
> slots setting whether it's activatable and whether its context is
> lexically scoped. I realise it's a bit late to make such a major
>; change, but

Aren't blocks and methods already both implemented using Block, and
the only difference between the two being of it has anything in the
scope slot?

Thanks,
Jonathan.

&gt; (a) it goes with Io's general philosophy of keeping the core language
> simple, and
>
> (b) it would be easy to implement backwards compatibility with (e.g.)
&gt; block := method clone setLexicalScope.
>;
> Jason
>;
>
&gt;
> Yahoo! Groups Links
>;
>
&gt;
>
&gt;
>
>
>

On Jul 15, 2006, at 12:22 AM, Jason Grossman wrote:

> Cool!
>;
> Any chance of getting rid of the distinction between block and
> method, then? We could have one base object covering both, with
> slots setting whether it's activatable and whether its context is
> lexically scoped. I realise it's a bit late to make such a major
>; change, but
>
> (a) it goes with Io's general philosophy of keeping the core language
> simple, and
>
> (b) it would be easy to implement backwards compatibility with (e.g.)
&gt; block := method clone setLexicalScope.

Doesn't this hybrid then need to keep track of its creation context
even if it is, in all likelihood, never going to be used? The per-
object memory requirements are already quite high. I'd actually be
more interested in eliminating "blocks" entirely, although it is
quite likely that someone here can make a good case for them. Given
we have objects, I'm not sure they're needed.

- John

On Jul 14, 2006, at 11:30 PM, Quag wrote:
&gt; Aren't blocks and methods already both implemented using Block, and
> the only difference between the two being of it has anything in the
> scope slot?

That's right.

- Steve