proto and baseenv()

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

proto and baseenv()

Peter Danenberg-3
I understand why the following happens ($.proto delegates to get,
which ascends the parent hierarchy up to globalenv()), but I still
find it anti-intuitive:

  > z <- 1
  > y <- proto(a=2)
  > y$z
  [1] 1

Although this is well-documented behavior; wouldn't it uphold the
principle of least surprise to inherit instead from baseenv() or
emptyenv()? (See attached patch.)

Spurious parent definitions have already been the source of bizarre
bugs, prompting me to use proto like this:

  > z <- 1
  > y <- proto(baseenv(), a=2)
  > y$z
  Error in get(x, env = this, inherits = inh) : object 'z' not found

It's cumbersome, but it ensures that parent definitions don't pollute
my object space; I would rather that be the default behaviour, though.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Ben Escoto
Wow, thanks for the heads-up.  That is horrible behavior.  But using
baseenv() doesn't seem like the solution either.  I'm new to proto,
but it seems like this is also a big drawback:

> z <- 1
> proto(baseenv(), expr={a=z})$a
Error in eval(expr, envir, enclos) : object "z" not found


--
Ben


----------------- Original message -----------------
From: Peter Danenberg <[hidden email]>
To: [hidden email]
Date: Wed, 24 Feb 2010 22:38:54 -0600
I understand why the following happens ($.proto delegates to get,
which ascends the parent hierarchy up to globalenv()), but I still
find it anti-intuitive:

  > z <- 1
  > y <- proto(a=2)
  > y$z
  [1] 1

Although this is well-documented behavior; wouldn't it uphold the
principle of least surprise to inherit instead from baseenv() or
emptyenv()? (See attached patch.)

Spurious parent definitions have already been the source of bizarre
bugs, prompting me to use proto like this:

  > z <- 1
  > y <- proto(baseenv(), a=2)
  > y$z
  Error in get(x, env = this, inherits = inh) : object 'z' not found

It's cumbersome, but it ensures that parent definitions don't pollute
my object space; I would rather that be the default behaviour, though.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Peter Danenberg-3
In reply to this post by Peter Danenberg-3
Quoth Ben Escoto on Sweetmorn, the 56th of Chaos:
> I'm new to proto, but it seems like this is also a big drawback:
>
> > z <- 1
> > proto(baseenv(), expr={a=z})$a
> Error in eval(expr, envir, enclos) : object "z" not found

Ouch, good point; it may be that parent pollution is the lesser of two
evils, then.

It's a little bit of a catch 22, it seems; because even if you ascend
up the parent hierarchy until you hit a non-prototype, the first
environment that has `a' also has `z':

  > library(proto)
  > get.proto <- function(x, env) {
  +   print(list(env=env,
  +              ls=ls(env, all.names=TRUE)))
  +   if (is.proto(env))
  +     tryCatch(get(x, env=env, inherits=FALSE),
  +              error=function(e) get.proto(x, env$.super))
  +   else
  +     stop(sprintf('object \'%s\' not found', x))
  +
  + }
  >
  > (function() { z <- 1; get.proto('a', proto(eval={a=z})) })()
  $env
  <environment: 0x1d12180>
  attr(,"class")
  [1] "proto"       "environment"

  $ls
  [1] ".super" ".that"  "eval"

  $env
  <environment: 0x1d12918>

  $ls
  [1] "a" "z"

  Error in get.proto(x, env$.super) : object 'a' not found
  >

So, even if the $ environment diverged, say, from the eval
environment; the first relevant environment is already polluted.

It almost seems like you have to choose between eval and parent
pollution (unless I'm missing something).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Gabor Grothendieck
In reply to this post by Ben Escoto
That is how R works with free variables, e.g.

z <- 1
f <- function() z
f() # 1

so the current behavior seems consistent with the rest of R.

Note that the example below could be done like this to avoid the error:

> z <- 1
> proto(baseenv(), a = z)$a
[1] 1

On Thu, Feb 25, 2010 at 12:33 AM, Ben <[hidden email]> wrote:

> Wow, thanks for the heads-up.  That is horrible behavior.  But using
> baseenv() doesn't seem like the solution either.  I'm new to proto,
> but it seems like this is also a big drawback:
>
>> z <- 1
>> proto(baseenv(), expr={a=z})$a
> Error in eval(expr, envir, enclos) : object "z" not found
>
>
> --
> Ben
>
>
> ----------------- Original message -----------------
> From: Peter Danenberg <[hidden email]>
> To: [hidden email]
> Date: Wed, 24 Feb 2010 22:38:54 -0600
> I understand why the following happens ($.proto delegates to get,
> which ascends the parent hierarchy up to globalenv()), but I still
> find it anti-intuitive:
>
>  > z <- 1
>  > y <- proto(a=2)
>  > y$z
>  [1] 1
>
> Although this is well-documented behavior; wouldn't it uphold the
> principle of least surprise to inherit instead from baseenv() or
> emptyenv()? (See attached patch.)
>
> Spurious parent definitions have already been the source of bizarre
> bugs, prompting me to use proto like this:
>
>  > z <- 1
>  > y <- proto(baseenv(), a=2)
>  > y$z
>  Error in get(x, env = this, inherits = inh) : object 'z' not found
>
> It's cumbersome, but it ensures that parent definitions don't pollute
> my object space; I would rather that be the default behaviour, though.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Thomas Petzoldt
In reply to this post by Ben Escoto
Am 25.02.2010 06:33, wrote Ben:
> Wow, thanks for the heads-up.  That is horrible behavior.  But using
> baseenv() doesn't seem like the solution either.  I'm new to proto,
> but it seems like this is also a big drawback:
>
>> z<- 1
>> proto(baseenv(), expr={a=z})$a
> Error in eval(expr, envir, enclos) : object "z" not found
>
>

I would say that this behaviour is intentional and not "horrible". proto
objects do simply the same as ordinary functions in R that have also
full access to variables and functions at a higher level:

Try the following:

 > y <- proto(a=2)
 > y$ls()
[1] "a"


ls() is defined in package base and so would even work if you inherit
from baseenv() so why it is surprising that proto objects (by default)
inherit objects from other packages and from the user workspace?


Thomas P.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Ben Escoto
I was disappointed in this behavior because it seems error-prone.
Suppose I declare an environment

> b <- 1
> p <- proto(expr={
    a <- 2
+   ...
+ })
> p$a
[1] 2
> p$b
[1] 1

Presumably if I ask for p$a or p$b later, it's because I'm interesting
in the value of "p$a" or "p$b" that I specifically put inside that
environment.  Otherwise I would just ask for "a" or "b".  If I'm
asking for "p$b" it the above case, that means I forgot to declare b
inside p.  In this case there should be an error telling me that, not
a silent substitution of the wrong quantity.

If someone wanted to do the y$ls() thing, they could always

> y <- proto(a=1)
> with(y, ls())
[1] "a"

Another reason is that there are plenty of other programming languages
that have similar structures and this behavior is very odd.  In
standard languages asking for "b" inside the "p" object gives you an
error, and no one complains.  Even in R, we have this behavior:

> z <- 1
> list(a=3)$z
NULL

(Actually I think the above should be an error, but at least it isn't
1.)  So anyway, I'm not saying that p$b being 1 is an outright 2+2=5
bug, but it does seem to be surprising behavior that leads to bugs.
But I'm sure you're right that there are historical/structural reasons
for this to be the case, so perhaps there's no solution.


--
Ben Escoto

----------------- Original message -----------------
From: Thomas Petzoldt <[hidden email]>
To: Ben <[hidden email]>
Date: Thu, 25 Feb 2010 13:02:40 +0100
Am 25.02.2010 06:33, wrote Ben:
> Wow, thanks for the heads-up.  That is horrible behavior.  But using
> baseenv() doesn't seem like the solution either.  I'm new to proto,
> but it seems like this is also a big drawback:
>
>> z<- 1
>> proto(baseenv(), expr={a=z})$a
> Error in eval(expr, envir, enclos) : object "z" not found
>
>

I would say that this behaviour is intentional and not "horrible". proto
objects do simply the same as ordinary functions in R that have also
full access to variables and functions at a higher level:

Try the following:

 > y <- proto(a=2)
 > y$ls()
[1] "a"


ls() is defined in package base and so would even work if you inherit
from baseenv() so why it is surprising that proto objects (by default)
inherit objects from other packages and from the user workspace?


Thomas P.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Duncan Murdoch
On 25/02/2010 8:50 AM, Ben wrote:

> I was disappointed in this behavior because it seems error-prone.
> Suppose I declare an environment
>
> > b <- 1
> > p <- proto(expr={
>     a <- 2
> +   ...
> + })
> > p$a
> [1] 2
> > p$b
> [1] 1
>
> Presumably if I ask for p$a or p$b later, it's because I'm interesting
> in the value of "p$a" or "p$b" that I specifically put inside that
> environment.  Otherwise I would just ask for "a" or "b".  If I'm
> asking for "p$b" it the above case, that means I forgot to declare b
> inside p.  In this case there should be an error telling me that, not
> a silent substitution of the wrong quantity.
>  

I think you are looking for a different object model than proto offers.  
There aren't many languages that offer the prototype object model.
> If someone wanted to do the y$ls() thing, they could always
>
> > y <- proto(a=1)
> > with(y, ls())
> [1] "a"
>
> Another reason is that there are plenty of other programming languages
> that have similar structures and this behavior is very odd.

Which languages are you thinking of?  The paper about proto only
mentions Self, LispStat, and Javascript. The Wikipedia page
http://en.wikipedia.org/wiki/Prototype-based_programming has a long list
of obscure ones, but the only additional ones I've used are R, Perl and
Tcl, all with add-on packages.

Duncan Murdoch


>  In
> standard languages asking for "b" inside the "p" object gives you an
> error, and no one complains.  Even in R, we have this behavior:
>
> > z <- 1
> > list(a=3)$z
> NULL
>
> (Actually I think the above should be an error, but at least it isn't
> 1.)  So anyway, I'm not saying that p$b being 1 is an outright 2+2=5
> bug, but it does seem to be surprising behavior that leads to bugs.
> But I'm sure you're right that there are historical/structural reasons
> for this to be the case, so perhaps there's no solution.
>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

hadley wickham
In reply to this post by Ben Escoto
> Presumably if I ask for p$a or p$b later, it's because I'm interesting
> in the value of "p$a" or "p$b" that I specifically put inside that
> environment.  Otherwise I would just ask for "a" or "b".  If I'm
> asking for "p$b" it the above case, that means I forgot to declare b
> inside p.  In this case there should be an error telling me that, not
> a silent substitution of the wrong quantity.
>
> If someone wanted to do the y$ls() thing, they could always
>
>> y <- proto(a=1)
>> with(y, ls())
> [1] "a"
>
> Another reason is that there are plenty of other programming languages
> that have similar structures and this behavior is very odd.  In
> standard languages asking for "b" inside the "p" object gives you an
> error, and no one complains.

You might want to have a look at the mutatr package which implements
prototype OO with the behaviour you're looking for (I think).  I also
have a paper available if you email me off list.

Hadley

--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Gabor Grothendieck
On Thu, Feb 25, 2010 at 9:57 AM, hadley wickham <[hidden email]> wrote:

>> Presumably if I ask for p$a or p$b later, it's because I'm interesting
>> in the value of "p$a" or "p$b" that I specifically put inside that
>> environment.  Otherwise I would just ask for "a" or "b".  If I'm
>> asking for "p$b" it the above case, that means I forgot to declare b
>> inside p.  In this case there should be an error telling me that, not
>> a silent substitution of the wrong quantity.
>>
>> If someone wanted to do the y$ls() thing, they could always
>>
>>> y <- proto(a=1)
>>> with(y, ls())
>> [1] "a"
>>
>> Another reason is that there are plenty of other programming languages
>> that have similar structures and this behavior is very odd.  In
>> standard languages asking for "b" inside the "p" object gives you an
>> error, and no one complains.
>
> You might want to have a look at the mutatr package which implements
> prototype OO with the behaviour you're looking for (I think).  I also
> have a paper available if you email me off list.

I think his objection is really only that he must specify baseenv() to
get the behavior he prefers but from what I understand (I am basing
this on my understanding that mutatr works like io language) in mutatr
one must use Object which seems really no different.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Peter Danenberg-3
In reply to this post by hadley wickham
Quoth hadley wickham on Sweetmorn, the 56th of Chaos:
> You might want to have a look at the mutatr package which implements
> prototype OO with the behaviour you're looking for (I think).

Hey, Hadley; I remember your prototype stuff from DSC 2009. I saw some
slides of yours that discussed proto, and was wondering whether mutatr
was still maintained.

Would you mind sending me that paper off-list, if necessary?

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Peter Danenberg-3
In reply to this post by Gabor Grothendieck
Quoth Gabor Grothendieck on Sweetmorn, the 56th of Chaos:
> I think his objection is really only that he must specify baseenv()
> to get the behavior he prefers but from what I understand (I am
> basing this on my understanding that mutatr works like io language)
> in mutatr one must use Object which seems really no different.

Which is exactly what I started doing in proto: declaring a base
prototype (`object') that inherits from baseenv(); whence my
subprototypes spring.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

hadley wickham
In reply to this post by Peter Danenberg-3
> Hey, Hadley; I remember your prototype stuff from DSC 2009. I saw some
> slides of yours that discussed proto, and was wondering whether mutatr
> was still maintained.

Yes, it's maintained, and I've even written a package that uses it
(testthat - both it and mutatr are available on cran).  It's still
mainly an experiment, and I don't currently have any plans to give up
using proto.  However, my entirely personal perspective is that my
code seems to be cleaner when I use mutatr instead of proto (this
probably reflects that I wrote the package though!).

Hadley

--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Ben Escoto
In reply to this post by Duncan Murdoch
> I think you are looking for a different object model than proto
> offers.  There aren't many languages that offer the prototype object
> model.

Yes, your probably right---I don't have much experience using the
prototype model.  This is the way I expected it to work:

> z <- 1
> p <- proto(expr={a <- z})
> p$a
[1] 1
> p$z
Error in get(x, env = this, inherits = inh) : variable "z" was not found

Also it seems it would lead to fewer bugs if it worked that way.
(Peter Danenberg mentions he's run into bugs because of this, and I
can see why.)  But as I mentioned I'm new to prototype programming.
If it worked like in my snippet, would this lead to less effective
prototype programming?


Thanks,

--
Ben

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

hadley wickham
On Thu, Feb 25, 2010 at 7:49 PM, Ben <[hidden email]> wrote:

>> I think you are looking for a different object model than proto
>> offers.  There aren't many languages that offer the prototype object
>> model.
>
> Yes, your probably right---I don't have much experience using the
> prototype model.  This is the way I expected it to work:
>
>> z <- 1
>> p <- proto(expr={a <- z})
>> p$a
> [1] 1
>> p$z
> Error in get(x, env = this, inherits = inh) : variable "z" was not found

> library(mutatr)
>
> z <- 1
> p <- Object$clone()$do({
+   self$a <- z
+ })
> p$a
[1] 1
> p$z
Error: Field z not found in Object <0x1022b66d8>

Hadley

--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Peter Danenberg-3
In reply to this post by Ben Escoto
> > I think you are looking for a different object model than proto
> > offers.  There aren't many languages that offer the prototype object
> > model.
>
> Yes, your probably right---I don't have much experience using the
> prototype model.  This is the way I expected it to work:
>
> > z <- 1
> > p <- proto(expr={a <- z})
> > p$a
> [1] 1
> > p$z
> Error in get(x, env = this, inherits = inh) : variable "z" was not found

Which is exactly how it should work! Namespace pollution is orthogonal
to the specific object model, and Duncan's assertion about the
prevalence of prototypes is a red herring.

Here's how it works in Scheme, for instance, using Neil van Dyke's
Prototype-Delegation package:[1]

  #;1> (use protobj)
  #;2> (define z 1)
  #;3> (define a (%))
  #;4> (! a a z)
  #;5> (? a a)
  1
  #;6> (? a z)

  Error: Object has no such slot:
  #<object>
  z

Just like one would expect! And since protobj is based on self,
Ungar-Smith's original prototype system,[2] I suspect that self
behaves similarly.

Footnotes:
[1]  http://www.neilvandyke.org/protobj/

[2]  http://research.sun.com/self/papers/self-power.html

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Gabor Grothendieck
On Thu, Feb 25, 2010 at 9:23 PM, Peter Danenberg <[hidden email]> wrote:

>> > I think you are looking for a different object model than proto
>> > offers.  There aren't many languages that offer the prototype object
>> > model.
>>
>> Yes, your probably right---I don't have much experience using the
>> prototype model.  This is the way I expected it to work:
>>
>> > z <- 1
>> > p <- proto(expr={a <- z})
>> > p$a
>> [1] 1
>> > p$z
>> Error in get(x, env = this, inherits = inh) : variable "z" was not found
>
> Which is exactly how it should work! Namespace pollution is orthogonal
> to the specific object model, and Duncan's assertion about the
> prevalence of prototypes is a red herring.
>
> Here's how it works in Scheme, for instance, using Neil van Dyke's
> Prototype-Delegation package:[1]
>
>  #;1> (use protobj)
>  #;2> (define z 1)
>  #;3> (define a (%))
>  #;4> (! a a z)
>  #;5> (? a a)
>  1
>  #;6> (? a z)
>
>  Error: Object has no such slot:
>  #<object>
>  z
>
> Just like one would expect! And since protobj is based on self,
> Ungar-Smith's original prototype system,[2] I suspect that self
> behaves similarly.
>
> Footnotes:
> [1]  http://www.neilvandyke.org/protobj/
>
> [2]  http://research.sun.com/self/papers/self-power.html

One would not expect the behavior you cite if you were working in R,
only if you were more familiar with something else.  One can just as
easily argue that consistency and flexibility are more important
principles.   Your preference is inconsistent with how the rest of R
works and is inflexible since everything inherits from Object.  In
contrast proto uses R-like behavior as its default but is flexible
enough that your preference can be accommodated and done so compactly.

Also I think your argument is based partly on repeating the original
erroneous (relative to the writer's intention) proto code without
repeating my correction confusing the discussion with simple user
error.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Peter Danenberg-3
> Your preference is inconsistent with how the rest of R works and is
> inflexible since everything inherits from Object.

Really? Here are a couple of counterexamples in S3 and S4 objects:

  > z <- 1
  >
  > ## S4
  > setClass('A', representation(a='numeric'))
  [1] "A"
  > a <- new('A', a=z)
  > a@z
  Error: no slot of name "z" for this object of class "A"
  >
  > ## S3
  > a <- structure(list(a=z), class='A')
  > a$z
  NULL

As far as flexibility is concerned: keep the ability of people to
inherit from the parent environment if they don't mind
namespace-pollution and unpredictability.

I'm merely asking that the default behavior resemble the twenty-three
years of precedent since Ungar's original Self paper.

> Also I think your argument is based partly on repeating the original
> erroneous (relative to the writer's intention) proto code without
> repeating my correction confusing the discussion with simple user
> error.

I acknowledged your correction in an earlier email when I stated that,
"[one has] to choose between eval and parent pollution."

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Gabor Grothendieck
On Thu, Feb 25, 2010 at 11:16 PM, Peter Danenberg <[hidden email]> wrote:

>> Your preference is inconsistent with how the rest of R works and is
>> inflexible since everything inherits from Object.
>
> Really? Here are a couple of counterexamples in S3 and S4 objects:
>
>  > z <- 1
>  >
>  > ## S4
>  > setClass('A', representation(a='numeric'))
>  [1] "A"
>  > a <- new('A', a=z)
>  > a@z
>  Error: no slot of name "z" for this object of class "A"
>  >
>  > ## S3
>  > a <- structure(list(a=z), class='A')
>  > a$z
>  NULL
>

lists don't have inheritance at all so the last example seems not
relevant.  Also other object systems which are alternatives to proto
seem less relevant than basic scoping and free variable lookup in
functions.  Those are the relevant principles.

> As far as flexibility is concerned: keep the ability of people to
> inherit from the parent environment if they don't mind
> namespace-pollution and unpredictability.

proto does that but uses the consistent default rather than the
inconsistent default that you prefer.

The namespace advantage is an advantage but its lesser than
consistency with R and the flexibility to have it either way.

> I'm merely asking that the default behavior resemble the twenty-three
> years of precedent since Ungar's original Self paper.

That is just what I (and possibly Duncan) have argued.  That your
expectation is based on different systems.

>
>> Also I think your argument is based partly on repeating the original
>> erroneous (relative to the writer's intention) proto code without
>> repeating my correction confusing the discussion with simple user
>> error.
>
> I acknowledged your correction in an earlier email when I stated that,
> "[one has] to choose between eval and parent pollution."

But the last email repeated the wrong code anyways and used that as
the springboard for the discussion.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Peter Danenberg-3
> Also other object systems which are alternatives to proto seem less
> relevant than basic scoping and free variable lookup in functions.

Sorry, but that seems absurd; object systems are less relevant to each
other than the totally orthogonal question of scope?

> proto does that but uses the consistent default rather than the
> inconsistent default that you prefer.

$.proto falls back upon get(), I presume, because the authors didn't
feel like recursing up the parent hierarchy themselves; I'll continue
to believe that the scope pollution was an oversight until they
contradict me. At which point I'll probably switch object systems.

Vague appeals to consistency, when you're really only talking about
naive get() semantics, don't mean much; especially after you've spent
hours debugging mysterious bugs resulting from scope pollution.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: proto and baseenv()

Gabor Grothendieck
On Fri, Feb 26, 2010 at 12:41 AM, Peter Danenberg <[hidden email]> wrote:
>> Also other object systems which are alternatives to proto seem less
>> relevant than basic scoping and free variable lookup in functions.
>
> Sorry, but that seems absurd; object systems are less relevant to each
> other than the totally orthogonal question of scope?

Yes, if you are using one then obviously you have decided to use it in
place of the other.  Also your example of S3 was misleading since it
used lists which do not have inheritance and did not truly illustrate
S3.  Free variables in S3 methods follow the same lookup procedure as
ordinary functions and using S3 together with proto works well.  In
fact, proto uses two S3 classes.

>
>> proto does that but uses the consistent default rather than the
>> inconsistent default that you prefer.
>
> $.proto falls back upon get(), I presume, because the authors didn't
> feel like recursing up the parent hierarchy themselves; I'll continue
> to believe that the scope pollution was an oversight until they
> contradict me. At which point I'll probably switch object systems.

Here I think you are admitting that the basic facilities of R do work
in the way proto does.

Also, your alternative likely would be unusable due to performance
whereas proto is fast enough to be usable (see list of applications
that use it at http://r-proto.googlecode.com/#Applications).  Its not
as fast as S3 (though sometimes you can get it that fast by optimizing
your code).  The development version of proto is even faster than the
current version of proto due to the addition of lazy evaluation.

> Vague appeals to consistency, when you're really only talking about
> naive get() semantics, don't mean much; especially after you've spent
> hours debugging mysterious bugs resulting from scope pollution.

In end it seems that your real beef is with R so perhaps you should be
using a different language.

With respect to proto its really just discussing whether to use

proto(baseenv(), ...) vs proto(...)

since the former gives you everything you want and the distinction
seems pretty trivial given how easy it is to use one or the other.  If
you used iolanguage or similar you would have to specify Object so
there is not even a penalty in terms of compactness.

There have also been threads on how to "fix" scoping in R for
individual functions and various manipulations of environments have
been suggested but in the end no one does this in practice.  In proto
at least you can do the part you want and its trivial to do so.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
12