const fields for composite types

[StefanKarpinski]

Essentially something like this:

type Rational{T<:Integer} <: Real
  const num::T
  const den::T

  function Rational(num::T, den::T)
    if num == 0 && den == 0
      error("invalid rational: 0//0")
    end
    g = gcd(den, num)
    num = div(num, g)
    den = div(den, g)
    new(num, den)
  end
end

A const field, like a const variable is write-once. In the case of a const field, that means that the value assigned by new is the permanent value of the field and it cannot be changed.

[grandinj]

Rather than introduce a function like new(), you could follow the example of the java compiler.
It performs a basic data-flow analysis for constructor functions.
LLVM will probably already do this for you.

If you do that, you could either
(a) make sure that each const field is assigned to at least once, and then take the const value as the last assigned value
or
(b) make sure that each const field is assigned to once and only once.

[StefanKarpinski]

The new business is already how things work. The design is actually one of my favorite things in the language — you can read about it here. It may not be necessary to require const fields to be assigned by new, however, since they could be assigned after new, by the constructor. However, it would be relatively simple to just make all the const fields required arguments of new. Then there just wouldn't be any way to construct an object that doesn't have all of its const fields initialized.

[grandinj]

Seems like a decent approach.
You might want to consider named parameters, though, because an object with lots of const fields is going to be confusing to initialise.

[StefanKarpinski]

We've talked about keyword arguments to functions in general — and once that feature exists, it would be natural for new to take keyword arguments as well as positional parameters. In fact, it would probably be special in allowing arguments to be either given positionally or by keyword, whereas for normal functions, parameters would be exclusively positional or given by keyword.

[JeffBezanson]

I suppose we could use this syntax with the assignable-cell model: fields not marked const would have the extra level of indirection. Instead of writing field::Ref{T}. But, if the field type is going to be stored as Ref{T} then having to write it that way makes the system easier to understand.

[StefanKarpinski]

I think that's way too verbose for the default. If we go with immutable composites with assignable ref fields, I was thinking that using & in the syntax would be nice and terse — and conceptually similar to its use in ccall. Either &x::T or x::&T.

[JeffBezanson]

Fair enough.

Another issue is finalization --- it seems to me we can only support finalizers on objects with mutable fields; then the finalizer can be attached to one of the ref cells.

[StefanKarpinski]

yeah, that seems sensible.

[JeffBezanson]

Merging with issue #13.