This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Some questions about GOOPS and CLOS in general


Marius Vollmer <mvo@zagadka.ping.de> writes:

> Mikael Djurfeldt <mdj@thalamus.nada.kth.se> writes:
> 
> > The responsibility of administering names is left to the module
> > system.
> 
> I think this is the right answer to the multiple-slots-with-one-name
> problem.  But note that the module system does not administer slot
> names, but only variables (unlike thew CL package system which deals
> with symbols and thus with any kind of name space that CL has).
> 
> I'm getting slowly convinced that the package system of CL isn't that
> bad, precisely because it works on the symbol level.  You can handle
> all kind of name spaces with it, not just top-level environments.
> 
> It is a different questions whether you want to have the many name
> spaces of CL.  Personally, I like to have a unified name space for
> functions, variables and classes.  But I also start to think that
> having just _one_ name space for everything is not realistic.  I don't
> think one wants to put slot names into the same name space as
> functions and variables, for example.
> 
> > > Or we might remove `slot-ref/set!' entirely (or, rather, deport them
> > > to the stklos compatibility module) and by default generate an
> > > accessor for the slot. [...]
> >
> > I think this is a good idea myself, but I had expected reactions to
> > this.  Since no people have complained, I might actually go about
> > removing slot-ref and slot-set! in release 0.1.4.
> 
> Hmm, I agree that using slot-ref and slot-set! in `production' code is
> probably not very important, but there should be a way to get at slots
> without an accessor or without knowing what funky name an accessor
> has.  That is, slot-ref and slot-set! might need to be extended to
> take the class as an argument to disambiguate what slot is referred
> to.
> 
> Or, one could entirely dispose of slot _names_.  That is, there
> wouldn't be any named slots but just accessors that use some
> behind-the-scenes-magic for their implementation, but for the user
> there isn't such a thing as a slot.  The MOP would not talk about
> slots either, only about accessors.

Yes, this is what I meant when talking about removing slot-ref/set!
and names.  The idea is that there would be no slot names.
The following class definition:

  (define-class <c> ()
    (x #:init-value 0)
    y)

would allocate two slots in the instances of <c> and define the
accessors x and y.

If x would be previously defined and y not, the macro above would
expand to:

  (begin
    (define x (ensure-accessor x 'x))
    (define y (make-accessor 'y))
    (define <c> (class () (x #:init-value 0) y #:name '<c>)))

Note that `x' and `y' in the class macro are actually *references* to
the variables x and y.

This is, by the way, how accessors are handled right now in GOOPS.

What is new is that instead of saying #:accessor x, the accessor is
created by default using the accessor name in the CAR of the slot
definition.

With this solution, indeed all names are handled by the module system.

(define-class <agent> ()
  (agent-sim #:accessor agent-sim #:init-keyword #:simulation)
  (agent-env #:accessor agent-env #:init-keyword #:environment))

Below, I've included a few class definitions cut out from real code.
You can see that implementing the suggested change would be quite an
improvement...  :)


(define-class <environment> ()
  (env-sim   #:accessor env-sim)
  (env-agent #:accessor env-agent))

(define-class <simulation> ()
  (environment #:accessor     sim-env
               #:init-keyword #:environment)
  (agent       #:accessor     sim-agent
               #:init-keyword #:agent)
  last-sensation
  next-action)

(define-class <maze> (<environment>)
  (n-states       #:accessor n-states)

  (n-actions      #:accessor n-actions
                  #:init-value 4)

  (xsize          #:accessor xsize
                  #:init-keyword #:xsize
                  #:init-value 10)

  (ysize          #:accessor ysize
                  #:init-keyword #:ysize
                  #:init-value 10)

  (places         #:accessor places
                  #:init-value #f)

  (position       #:accessor position)

  (start-state    #:accessor start-state)

  (goal-state     #:accessor goal-state)

  (default-reward #:accessor default-reward
                  #:init-value 0)

  (goal-reward    #:accessor goal-reward
                  #:init-value 100)

  (bounce-reward  #:accessor bounce-reward
                  #:init-value -1)
  )

(define-class <neuro-sarsa-lambda> (<TD>)
  (last-V #:accessor last-V)
  (e_V #:accessor e_V)
  (e_pi #:accessor e_pi)
  )

(define-class <ad-state-egreedy-policy> (<egreedy-policy>)
  (v-adapt        #:accessor v-adapt
                  #:init-value 50.0)
  (v-gamma        #:accessor v-gamma
                  #:init-value 0.9)
  (v-trace        #:accessor v-trace)
  (v-trace-length #:accessor v-trace-length
                  #:init-value 50)
  )

(define-class <neuro-V> (<action-value-function>)
  (w_V #:accessor w_V)
  (w0_V #:accessor w0_V #:init-value 0.0))

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]