On 27 November 2013 17:09, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Wed, Nov 27, 2013 at 1:51 AM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> I realise that we never have "immutable with a capital I", hence why I
>> used the term "purely functional" to try work around the ambiguity
>> [1]. But the point is that Chris thinks that all Numbers behave like
>> SmallInteger, Boolean and Point in that they are, indeed, "immutable
>> by convention". It sounded to me like Levente was saying that this was
>> not true. If there are Numbers that are not "immutable by convention"
>> we should _make_ them immutable by convention ASAP!
>
>
> Agreed.  But note that there are edge cases in this apparently
> straight-forward case.  The LargeIntegers need to be mutable while they're
> being constructed (they're not all constructed by primitive code and that
> primitive code is optional).

OK, but that's acceptable. Just as long as once they're constructed,
they can no longer mutate.

> But on the "we will never have immutable with a capital I" point I disagree.

I never said that!

> The VM can easily enforce immutability.  I actually implemented this for the
> Newspeak interpreter VM in 2007.

Exactly!

>  It is a "small matter" of implementation
> to move it into Cog.  It's probably two weeks work.  But its not a priority
> yet.  It might be a good thing to introduce when we move to Spur because
> there will be other things that will disturb too (image segments, ephemerons
> to be used, etc).

Indeed. Capital-I Immutability is very cool, and I do think we need it
in the long run (along with a bunch of other goodies like decent
purely functional data structures), and we'll get there sooner or
later. Other things first though.

frank

>> frank
>>
>> [1] "Immutable with a capital I" requires VM support, IIRC
>>
>> On 26 November 2013 22:45, Nicolas Cellier
>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> > What Levente says is that this immutability is purely conventional and
>> > not
>> > guaranteed.
>> > Numbers are technically mutable (but SmallInteger).
>> > Though, I strongly suggest to not play with such mutations, a mutant
>> > Number
>> > would be a frightening thing mathematically speaking...
>> >
>> >
>> > 2013/11/26 Frank Shearar <frank.shearar at gmail.com>
>> >>
>> >> On 26 November 2013 18:02, Levente Uzonyi <leves at elte.hu> wrote:
>> >> > On Tue, 26 Nov 2013, commits at source.squeak.org wrote:
>> >> >
>> >> >> Chris Muller uploaded a new version of Kernel to project The Trunk:
>> >> >> http://source.squeak.org/trunk/Kernel-cmm.821.mcz
>> >> >>
>> >> >> ==================== Summary ====================
>> >> >>
>> >> >> Name: Kernel-cmm.821
>> >> >> Author: cmm
>> >> >> Time: 26 November 2013, 10:24:26.281 am
>> >> >> UUID: 591c1ede-81bc-40d7-8591-af7fe29b2bd5
>> >> >> Ancestors: Kernel-fbs.820
>> >> >>
>> >> >> - Don't let Boolean and Number inherit Object's really slow
>> >> >> #veryDeepCopy.
>> >> >
>> >> >
>> >> > Some Numbers are mutable objects, so this doesn't sound right.
>> >>
>> >> Which Numbers are mutable? They _should_ all be purely functional,
>> >> like Point (which I know is not a Number).
>> >>
>> >> frank
>> >>
>> >> > Levente
>> >> >
>> >> >
>> >> >>
>> >> >> =============== Diff against Kernel-fbs.820 ===============
>> >> >>
>> >> >> Item was added:
>> >> >> + ----- Method: Boolean>>veryDeepCopy (in category 'copying') -----
>> >> >> + veryDeepCopy
>> >> >> +       "Overridden for performance to avoid #fixDependents."
>> >> >> +       ^ self!
>> >> >>
>> >> >> Item was added:
>> >> >> + ----- Method: Number>>veryDeepCopy (in category 'private') -----
>> >> >> + veryDeepCopy
>> >> >> +       "Overridden for performance."
>> >> >> +       ^ self!
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>> >
>> >
>> >
>>
>
>
>
> --
> best,
> Eliot