[bitc-dev] Revisiting stack-ref

[Sam Mason]

On Mon, Jun 04, 2007 at 09:51:55AM -0400, Jonathan S. Shapiro wrote:
> On Mon, 2007-06-04 at 11:23 +0100, Sam Mason wrote:
> > On Sun, Jun 03, 2007 at 10:16:47PM -0400, Jonathan S. Shapiro wrote:
> > >   2. Captured by-reference arguments are legal in *escaping* closures,
> > >      but a *copy* of the by-reference value is made at the time of
> > >      closure construction.
> > >
> > >      This yields sensible behavior and preserves type safety, but it
> > >      introduces behavioral subtlety that will confuse programmers. 
> > 
> > I think this would confuse the semantics a lot, apparently simple
> > changes to an expression could change its behaviour considerably.
> 
> No more so (or less so) than any procedure call that is passed a
> reference.

OK, I think I completely missed what you meant when you said copying
the "by-reference value".  I thought you meant duping the value that
is referenced, this would fix the safety problem (I now realise) by
breaking almost everything else.

I don't think I understand what the "behavioural subtlety" you elided to
is now.

I've just noticed a problem with these by-references values though.
That of calling a "by-reference" method with the reference to an element
of a union and changing the tag of the union invalidating the type of
the element inside the "by-reference" function.  I can only think of
very contrived bits of code that would trigger it, but it would break
type safety.

> The reason I want this is that there is an idiom for writing constructor
> and re-initializer procedures that requires it. The problem at present
> is that there is no clean way to re-initialize a data structure that is
> unboxed, nor any way to characterize field get/set as a procedure call
> within the language.

yes, which is why (I believe) references got added to C++.  I've never
seen a way to do this safely without some heavy type-level stuff, like
alias types.  This is a big step from what you've got at the moment
though.

> I do think it is better than "copy on closure formation", which appears
> to be what the Felix folks are considering.

I don't know Felix at all.  I've had a look through the language
reference[1] on their website but can't seem to find anything about
this.


  Sam

 [1] http://felix.sourceforge.net/doc/refman/en_flx_ref_top.html