> --- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 11:45 AM -0700 8/1/03, TOGoS wrote:
> > > ...blah, blah, blah...
> > >
> > > What I don't like about this is
> > > that it's not immediately obvious
> > > from looking at the code whether
> > > you're telling P3 to change its
> > > value or simply replace the PMC
> > > reference stored in P3 with another.
> >
> > This is a reasonable thing to worry
> > about, because we have three separate
> > semantics, set, assign, and clone.
>
> Well, yes. I understand what set, assign,
> and clone do. :-) What I was whining about
> was that 'set' doesn't consistantly copy
> pointers.
>
> If you say
> set PMC, PMC
> it copies a pointer, but if you say
> set PMC, Int
> it behaves like 'assign'.
Yeah, I agree with this.
> I just thought it might be better if
> you had to be explicit about what you
> were doing. If you want assign semantics,
> you should have to say "assign". So
> set PMC, Int
> would be illegal, since you can't copy
> an integer to a PMC pointer. You would
> be forced to say what you really meant,
> which is
> assign PMC, Int
And ghod forbid, for arrays:
elements PMC, int
(an elements op would be really nice, because then infinite lists
could return infinite elements:)
elements PMC, PMC
It might be confusing to have both "set elements" and "get elements"
by the same name. But those are just details.
> And likewise for strings. (At the moment,
> I am forced to use 'set' for strings, because
> assign S0, 23
> throws a 'can't find assign_s_ic' error.)
But the set_s_ic op doesn't do an assign.
S0 = "Hello"
S1 = S0
S1 = 23
print S0
Prints "Hello".
So basically, I'm for getting rid of some of the C<set> variants in
favor of more explicit ops... usually C<assign>.
> I just thought that it might save
> people from a few headaches if "set"
> always meant the same thing :-)
Luke
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
