pure functions without invariant (a get-rid-of-const proposal)

BCS none at anon.com
Sun Mar 8 09:43:35 PDT 2009


Hello hasen,

> The line of thinking for introducing const/invariant seems to go like
> this:
> 
> - D needs to be suitable for parallelism
> - let's introduce pure functions
> - pure functions need to accept immutable data only
> - let's introduce const!! (invariant)
> OK, I can agree with most of this, except for the last part! It's not
> necessary that invariant is needed to introduce pure functions into D.
> There must be better ways.
> 
> First of all, one could argue, why? what's wrong with invariant?
> 
> Well, there are a number of things that are wrong with it:
> 
> First of all, immutable data is a concept, implementing it as
> "invariant" seems kind of hackish. By definition, immutable data
> doesn't
> change. Forcing invariant on top of a mutable type is like saying
> "This
> data would usually change, but please, for this instance, make it not
> un-changeable!"

That is, in fact, exactly what I think people want.

> This is a HACK. Immutable types should have immutability be a
> fundamental part of the type, not some kind of a glue on top of it; a
> flag that's set on or off!

what about an "immutable int" are you proposing that it be a totally separate 
type? 

> For instance, it doesn't make sense to have an invariant pointer to
> invariant pointer to invariant data. If the data is invariant, then
> why access it through pointers at all?

Because arrays /are/ pointers because objects are pointers, because ref parameters 
are pointers, because passing large structs by value is to expensive and 
the alternative is a pointer.

OK, I'll admit that all but the last case are not pointer at the code level 
but I'm not seeing any way your argument would work work that doesn't also 
apply to those cases.

> 
> When data is immutable, then all you need is the data! You shouldn't
> need to know where is it stored.
> 

pointers are a way to access data, not a way to tell you where it is.

> Invariant pointers just don't make sense!

they make a lot of sence to me.

> 
> Another thing to consider. When you have an object (in the oop sense
> of the term), and you mark it as immutable, what's the point? The
> whole point of objects is to encapsulate state that could change. If
> the object's state doesn't change at all, then it becomes much less
> interesting as an object. All you need then is the data in that
> object, and not the object itself.

IIRC, the point of objects is to encapsulate implementation that can change. 

> Invariant (oop) objects don't make sense.
> 

they make a lot of sence to me.

> You're trying to glue completely different things together and hope
> that they stick.
> 
> I see this as similar to C++ trying to be "Object Oriented" without
> automatic memory management, and it just doesn't make sense! They put
> high level concepts in a low level language with no consideration to
> how people actually need to use OOP. (They can argue all day long
> about how they have inheritance and polymorphism!)
> 
> Similarly for D2, are we considering how people actually need to use
> immutable data in their code?

I'm reasonably sure they have.

> 
> Wouldn't it make much more sense, to have immutable data-types (such
> as python tuples, and python strings), and remove the "invariant"
> concept all together?
> 

There are to make cases where the data that will be wanted immutable is of 
a type (that already exists) that is also wanted in a mutable form. 


> Let's step back and look at what we're trying to achieve again, and
> think of a different way to implement it.
> 
> We want to have pure functions, but those have some restrictions!
> A pure function's result can only depend on its input parameters (so
> cannot have side effects)
> - doesn't read global state

wrong, it can access anything (including globals) that can be proven won't 
change (that is they are immutable)

> - doesn't perform I/O operations
> - doesn't change input parameters (if they are passed by reference,
> that is)
> It's clear that we need immutable types, so, just introduce immutable
> types, but would they be like?

Based on your comment about globals it is not clear that immutables are needed. 
Based on the above, all that would be needed is const.

[...]

> - while we're at it, string slice and index operations should
> operate on characters, not bytes!

That's a side issue, but indexing char's is an O(n) operation.

> - I actually prefer that string is an actual type, not
> just
> an alias
> -the elements of the list must also be immutable.
> - immutable list to mutable data doesn't make sense (wouldn't
> be used or needed in practice)

You, me and walter aggree on that.

[...]

After reading this far and skimming the rest my only question is "WHY?". 
I see exactly zero benefit to your proposal. You have defined a system that 
has all the problems of the current one and more. If we were to switch to 
it I expect that we would end up with a common idiom of defining two almost 
identical types where one is immutable and the other is not.

*What does your system give me that the current system does not?*





More information about the Digitalmars-d mailing list