Janice Caron wrote:
> 
> So, we're all clear, right? Everyone understands why we say "const is
> transitive", not "const is recursive"?

I'd be interested in your definition of "recursive", given at the same level of detail with which you examined "transitive".  I'd think you'd find you're saying exactly the same thing.  Transitivity is recursive in nature.

-Jeff

On 06/04/2008, Jeff Nowakowski <jeff@dilacero.org> wrote:
>  I'd be interested in your definition of "recursive", given at the same
> level of detail with which you examined "transitive".

Wikipedia defines recursion as follows:

Recursion, in mathematics and computer science, is a method of defining functions in which the function being defined is applied within its own definition.

Further down the page, it tells us:

Functional recursion - A function may be partly defined in terms of
itself. A familiar example is the Fibonacci number sequence: F(n) =
F(n − 1) + F(n − 2). For such a definition to be useful, it must lead
to values which are non-recursively defined, in this case F(0) = 0 and
F(1) = 1.


Now, the way I see it, const() is a function. It's a function which
takes a type as its input, and returns a type as its output. According
accu-functional.pdf, const() is defined by four rules (numbered 0 to
3). Rule 1 says:

Rule 1: If T.field has type U, then const(T).field has type const(U)

That, to me, looks like a classic example of a recursive definition.



> I'd think you'd find
> you're saying exactly the same thing.  Transitivity is recursive in nature.

Are you sure about that? In what way is "less than" recursive? "Less
than" is certainly transitive, by definition (if (a < b), and (b < c),
then it must be true that (a < c)). However, you'd be hard pressed to
claim that "less-than" was "recursive". It's not defined in terms of
itself.

If I recall correctly, (a < b) is defined to be true if and only if there exists a positive number c such that a + c = b. That is a surely a non-recursive definition? The transitivity of "less than" is merely an emergent property, a /consequence/ of that definition. No recursion involved.

Janice Caron wrote:
> Now, the way I see it, const() is a function. It's a function which
> takes a type as its input, and returns a type as its output. According
> accu-functional.pdf, const() is defined by four rules (numbered 0 to
> 3). Rule 1 says:
> 
> Rule 1: If T.field has type U, then const(T).field has type const(U)
> 
> That, to me, looks like a classic example of a recursive definition.

Ok, you've changed my mind.  Saying "const is transitive" is sloppy, even though it's easy to see how that phrase could come about and it's intuitive to me -- since const(T) is riding on the transitive nature of data accessibility.

Walter has said academics papers validate his usage.  Maybe he can cite a source?  I've looked around and haven't found any examples where "x is transitive" and x is a non-binary relation.

-Jeff

On Fri, 2008-04-04 at 11:17 -0700, Walter Bright wrote:
> BCS wrote:
> > Walter Bright wrote:
> >> Janice Caron wrote:
> >>
> >>> Sorry to go all grammar/mathematics nit-picky, but isn't "transitive" completely the wrong word?
> >>
> >>
> >> No, it is used in this sense in academic papers on the subject.
> > 
> > That might not answer the question.
> > 
> > One question that should be asked (but it might be to late to ask) is; is transitive the word that /should/ be used? Note that this is distinct from the question of transitive being the world that /is/ used.
> 
> We should only invent new jargon if we're forced to. I don't see any compelling reason not to use transitive in the same form that academics use it to write papers about.

It's dubious, but not "wrong".

given const(int) a;
and a is typeof(b)
and b is typeof(c)
then c is const(int).

This is generally true with all type classes and other attributes of a type system, with the exception of storage classes such as static, final, and const.  Transitive const would imply that const storage class is now transitive, where previously only the type was transitive.  Naturally, this has another implication of making const an attribute of the value, as opposed to an attribute of the identifier, which interestingly subsequently enough revokes it's previous definition of being a storage class.  This means const is no longer a storage class, but an attribute of the value type.

That is, const(int) is not the value type int with the storage class
const.  const is now an attribute of the value type system and int is
no longer the type of a int marked "const", it's now simply
const(int).  It might be possible that it could be demoted into an int
by copy-on-reference, or promoted into an invariant(int).  It might
also be that const(int) is a descendant of int.  But const(int) is now
the type.

Naturally this opens the door for other terms which could be used to define the concept: the const value type attribute.  Or, const as a part of the value type system, or whatever.

So now that we're all talking about this, how about normalizing the syntax of const?

private const int foo;

The above example is inconsistent for a number of reasons.  The first, that const is listed as a storage class as opposed to an attribute of the value type.  And again it's inconsistent in a context I previously brought up:

private const int foo;
public const const(int) bar () { return foo; }

In the above example, the behavior of the keyword "const" is relatively schizophrenic.  const is listed as a part of the storage class for foo, and then as an access qualifier for bar(), with the same syntax.  It would seem more consistent with the essence of const if const was always an attribute of the type, when associated with a value.

private const(int) foo;

This would also mean that:

private const int foo;

could maintain it's previous definition, which is a part of what's making people so frustrated about const.  Since const is listed in the storage-class part of the declaration, const as a storage class could be possible.  Alternatively, const as a storage class could be a syntax error.

Cheerio,
	Scott S. McCoy

Janice Caron wrote:
> 
> Aha - so
> 
> (1) "const" is short for "const with respect to reachability", and
> 
> (2) "const with respect to reachability" actually means "(a is const)
> and (b is reachable from a) implies (b is const)".
> 
> So, when we say "const is transitive", what we /in fact/ mean is:
> 
> ((a is const) and (b is reachable from a) implies (b is const)) and
> ((b is const) and (c is reachable from b) implies (c is const))
> implies ((a is const) and (c is reachable from a) implies (c is
> const))
> 
> Now why didn't I see that before? It's just so blindingly obvious!
> (The sarcasm wasn't aimed at you, by the way. Thanks for explaining).
> 
> So, we're all clear, right? Everyone understands why we say "const is
> transitive", not "const is recursive"?

You say "It's just so blindingly obvious!" with sarcasm, as if it isn't obvious?

Well, I *do* think all of the above is indeed obvious. (or at least "clear"). In fact, saying "const is transitive" is clearer to me than saying "const is recursive".
You seem to think "transitive" is something that is said only of binary relationships. But another common usage is saying a given property is transitive, which is taken to mean that that property applies to all "objects" reachable from the original "object". Brad Roberts said it best, so I'll just quote him:

"The term 'transitive' comes from the term 'transitive closure' used in
graphs.  Data structures form a graph and so the term transitive applies
quite well."


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Jeff Nowakowski wrote:
> 
> Walter has said academics papers validate his usage.  Maybe he can cite a source?  I've looked around and haven't found any examples where "x is transitive" and x is a non-binary relation.
> 
> -Jeff

http://groups.csail.mit.edu/pag/pubs/tschantz-refimmut-mengthesis.pdf
"Transitive - Provide transitive (deep) immutability that protects the entire abstract state of an object."

(PS: I wish I had an euro every time I posted the Javari paper during the const discussion...)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> 
> http://groups.csail.mit.edu/pag/pubs/tschantz-refimmut-mengthesis.pdf
> "Transitive - Provide transitive (deep) immutability that protects the entire abstract state of an object."

Thanks for the reference.  I'm looking forward to reading the paper.  As I said, I found the "transitive" term intuitive.  Maybe this satisfies Janice?

> (PS: I wish I had an euro every time I posted the Javari paper during the const discussion...)

I'm sure many things have been repeated in the const discussions :) Sometimes it takes a few times to get through.

-Jeff

Bruno Medeiros, el 10 de abril a las 21:12 me escribiste:
> Jeff Nowakowski wrote:
> >Walter has said academics papers validate his usage.  Maybe he can cite a source?  I've
> >looked around and haven't found any examples where "x is transitive" and x is a
> >non-binary relation.
> >-Jeff
> 
> http://groups.csail.mit.edu/pag/pubs/tschantz-refimmut-mengthesis.pdf
> "Transitive - Provide transitive (deep) immutability that protects the entire abstract
> state of an object."

This will put again in the table the flame about const vs readonly =P

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Pity's very underrated. I like pity. It's good.
	-- George Constanza