Smart variables, dumb variables

Smart variables, dumb variables

[Marius Vollmer]

Hi,

currently, our global variables are strictly passive containers.
Accessing a variable is just a memory reference.  I think we need to
keep this for performance reasons.

However, we might also want to have more fancy variables.  One might
want to get a notification when a variable is set, or one might want
to fetch the real value from some indirect location.

For example, Emacs has the ability to forward references to Elisp
variables to C variables.  C code can use a normal "int" variable,
say, and Elisp code can use that variable as well.  Translating
between Elisp representation and C representation of values is done
transparently, when Elisp accesses the variable.  RMS convinced me
that that would be a nice feature for Guile as well, in general.

One might say that it is probably better to not use variables for
this, but rather have a more abstract interface using setter and
getter functions.  But when designed carefully. the need to use
stters/getters for things that are in all respects just variables can
also feel awkward.  A good example are the forwarding variables of
Emacs.  It shouldn't really be visible to Elisp code that the
variables are forwarded to C variables (although they don't allow
non-integer values, thus making them different from other Elisp
variables, hmm).


I'd like to propose a slight modification to our variables that would
allow us to cleanly mess with what variables exactly are in the
future.

I would add a 'flags' field to variable smob (there is room for it),
with the following flags defined initially:

   - SCM_F_VARIABLE_DUMB 

     When set, the variable is 'dumb' and can be referened and set
     with SCM_DUMB_VARIABLE_REF and SCM_DUMB_VARIABLE_SET,
     respectively.  When it is not set, you need to call
     scm_variable_ref and scm_variable_set_x.

   - SCM_F_VARIABLE_READONLY

     When set, the variable can not be set.  You are not allowed to
     use SCM_DUMB_VARIABLE_SET and scm_variable_set_x will result in
     an error.

A future execution model (that is slowly forming in my head) will make
it so that most variable flags can be tested at compile time.  Thus, a
compiler can emit more efficient code for dumb variables.

One possible next step would be to somehow involve Goops in this and
turn scm_variable_ref into a generic function, the way scm_sum is
already.

Opinions?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[tomas]

On Tue, Aug 13, 2002 at 10:06:50PM +0200, Marius Vollmer wrote:
> Hi,
> 
> currently, our global variables are strictly passive containers.

[...]

> I would add a 'flags' field to variable smob (there is room for it),
> with the following flags defined initially:
> 
>    - SCM_F_VARIABLE_DUMB 
> 
>      When set, the variable is 'dumb' and can be referened and set
>      with SCM_DUMB_VARIABLE_REF and SCM_DUMB_VARIABLE_SET,
>      respectively.  When it is not set, you need to call
>      scm_variable_ref and scm_variable_set_x.
> 
>    - SCM_F_VARIABLE_READONLY
> 
>      When set, the variable can not be set.  You are not allowed to
>      use SCM_DUMB_VARIABLE_SET and scm_variable_set_x will result in
>      an error.

An attractive idea, indeed. Let's see whether there are objections
from the `language theorists' out there.

I'd propose a slight modification, though: use one flag for the setter,
one for the getter, like so:

   - SCM_F_VARIABLE_DUMB_GETTER

     When set, the variable has a `dumb' getter and can be
     referenced with SCM_DUMB_VARIABLE_REF. Otherwise you
     need to reference it with scm_variable_ref.
     
   - SCM_F_VARIABLE_DUMB_SETTER

     When set, the variable has a `dumb' setter and can be
     referenced with SCM_DUMB_VARIABLE_SET. Otherwise you
     need to set it with scm_variable_set_x.

It looks more symmetric ;-) and it's still possible to implement `unsettable'
variables (by appropriately implementing a setter function which does nothing,
complains, whatever seems appropriate). I think it's even more flexible.

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

tomas@fabula.de writes:

> I'd propose a slight modification, though: use one flag for the setter,
> one for the getter, like so:

Good idea!

> It looks more symmetric ;-) and it's still possible to implement
> `unsettable' variables (by appropriately implementing a setter
> function which does nothing, complains, whatever seems
> appropriate). I think it's even more flexible.

Read-onlyness should be a property of a variable that can be detected
by the compiler so we wouldn't want to bury it only in the setter, I'd
say.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[tomas]

On Wed, Aug 14, 2002 at 09:35:29PM +0200, Marius Vollmer wrote:
> tomas@fabula.de writes:
> 

[...]

> Read-onlyness should be a property of a variable that can be detected
> by the compiler so we wouldn't want to bury it only in the setter, I'd
> say.

For some kind of static integrity checking? (the performance bit
is already taken care of, at least if we assume that writing to
a read-only variable doesn't happen very often ;)

How about a special setter then (e.g. NULL or 'read-only). If someone
changes this setter at run-time I guess they get what they deserve.

The idea would be to spare the precious bit just to say that there's
something special about the setter and to put more information
``down the pointer'', where there is more room (same for the getter).

-- tomas ``if it sounds fuzzy it's because I'm fuzzy myself''


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

tomas@fabula.de writes:

> On Wed, Aug 14, 2002 at 09:35:29PM +0200, Marius Vollmer wrote:
>
> > Read-onlyness should be a property of a variable that can be detected
> > by the compiler so we wouldn't want to bury it only in the setter, I'd
> > say.
> 
> For some kind of static integrity checking?

I had in mind that the compiler could use the bit to decide if it is
allowed to inline some functions (such as '+', 'car', ...) but I no
longer think that would be the right way.

Also, it would be needed for dumb variables when there are no separate
setter and getter flags, but I think we should have these two flags.

So let's forget about the read-only bit for now, I'd say.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[rm]

On Wed, Aug 14, 2002 at 10:48:32PM +0200, Marius Vollmer wrote:
> tomas@fabula.de writes:
> 
> > On Wed, Aug 14, 2002 at 09:35:29PM +0200, Marius Vollmer wrote:
> >
> > > Read-onlyness should be a property of a variable that can be detected
> > > by the compiler so we wouldn't want to bury it only in the setter, I'd
> > > say.
> > 
> > For some kind of static integrity checking?
> 
> I had in mind that the compiler could use the bit to decide if it is
> allowed to inline some functions (such as '+', 'car', ...) but I no
> longer think that would be the right way.

Wouldn't that imply that certain functions will never be 'generic' ?

 Ralf 

> Also, it would be needed for dumb variables when there are no separate
> setter and getter flags, but I think we should have these two flags.
> 
> So let's forget about the read-only bit for now, I'd say.
> 
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
> 
> 
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

rm@fabula.de writes:

> > I had in mind that the compiler could use the bit to decide if it is
> > allowed to inline some functions (such as '+', 'car', ...) but I no
> > longer think that would be the right way.
> 
> Wouldn't that imply that certain functions will never be 'generic' ?

What do you mean with generic?

The way I imagine it, is that you can put declarations on variables
that the compiler is allowed to trust at compile-time, and one such
declaration could be "this variable holds the R5RS primitive procedure
'+' and will always hold it."  This is a reasonable declaration to
make.  The compiler could then inline the fixnum part of '+' and call
out-of-line code for the rest.

So my next proposal is to add declarations to variables... :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Rob Browning]

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

> For example, Emacs has the ability to forward references to Elisp
> variables to C variables.  C code can use a normal "int" variable,
> say, and Elisp code can use that variable as well.  Translating
> between Elisp representation and C representation of values is done
> transparently, when Elisp accesses the variable.  RMS convinced me
> that that would be a nice feature for Guile as well, in general.
>
> One might say that it is probably better to not use variables for
> this, but rather have a more abstract interface using setter and
> getter functions.  But when designed carefully. the need to use
> stters/getters for things that are in all respects just variables can
> also feel awkward.  A good example are the forwarding variables of
> Emacs.  It shouldn't really be visible to Elisp code that the
> variables are forwarded to C variables (although they don't allow
> non-integer values, thus making them different from other Elisp
> variables, hmm).

Hmm, my initial reaction is that this kind of "transparency" always
makes me nervous.  In fact I'd probably be happier if emacs made some
of the operations *more* explicit.  i.e. I'd rather see

  (set-customized-var! some-foo value)

rather than have to remeber that

  (set! some-foo value)

may be doing all kinds of fancy operations I'm not aware of, depending
on a definitions that may not be visible at the scheme level.  Also,
sticking with functions rather than raw variables for important
"globals" makes your life far less unpleasant if/when you decide you
want or need to function in the presence of (preemtive) threads.

However, I understand the reasoning, so I wonder whether or not we
might be able to come up with a broader solution (as you alluded to)
to start with.  We already have goops and procedures with setters --
can we come up with something along those lines that can still be
optimized (even if we can't do that optimization right now)?  If so,
those optimizations might help elsewhere too.  Questions: how bad
would the overhead for "raw variables" be if we moved in this
direction, and is our current bottleneck really raw variable accesses?

Overall, I guess I just have a reflexive nervousness wrt "magic
variables".  If nothing else, they make code that much more mysterious
to anyone coming to a project/language from the outside, but all that
said -- I'm already strongly opposed or anything, just wary.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Hmm, my initial reaction is that this kind of "transparency" always
> makes me nervous.

Yep, me too.  However, I don't think that we should categorically deny
people this opportunity because we think it might be abused.

> [...]
> However, I understand the reasoning, so I wonder whether or not we
> might be able to come up with a broader solution (as you alluded to)
> to start with.

What I'm interested in right now is to have a way to force all
variable access thru a common point.  Whatever we do at that point is
still open.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Rob Browning]

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

> A future execution model (that is slowly forming in my head) will
> make it so that most variable flags can be tested at compile time.
> Thus, a compiler can emit more efficient code for dumb variables.

Are you thinking about testing the flags on the C side or on the
Scheme side, and if you have more thoughts (even preliminary ones)
about how the compile time tests would work, could you elaborate?  I'm
trying to get a picture in my head of how all this might work
internally, and how it might look in the external API so I can think
about it.  I was also trying to imagine any potential interactions
with the various potential forms of compilation we might consider in
the future (i.e. Scheme -> C, for example).

(only marginally-relevant aside: anyone know the status of C inline
 functions these days -- do other non-gcc compilers support them, do
 we compile under non-gcc compilers, etc.?)

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > A future execution model (that is slowly forming in my head) will
> > make it so that most variable flags can be tested at compile time.
> > Thus, a compiler can emit more efficient code for dumb variables.
> 
> Are you thinking about testing the flags on the C side or on the
> Scheme side, and if you have more thoughts (even preliminary ones)
> about how the compile time tests would work, could you elaborate?

I'm currently writing up a proposal for a compilation/execution model.
It's coming along nicely, but I don't want to show it until I have
written down all the pieces.  Should be finished in a few days or so.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Lynn Winebarger]

On Thursday 15 August 2002 03:06, rm@fabula.de wrote:
> 
> In the presence of a generic method system (i.e. function dispatch on
> the type signature of the arguments) this seems to be rather non-trivial,
> or do you want to propose to make guile a strongly typed language ?

   Scheme is strongly typed.  It's just not statically typed.  Two different
things.

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[rm]

On Wed, Aug 14, 2002 at 11:09:36PM +0200, Marius Vollmer wrote:
> rm@fabula.de writes:
> 
> > > I had in mind that the compiler could use the bit to decide if it is
> > > allowed to inline some functions (such as '+', 'car', ...) but I no
> > > longer think that would be the right way.
> > 
> > Wouldn't that imply that certain functions will never be 'generic' ?
> 
> What do you mean with generic?

oops, i forgot to mention goops. I was thinking of GOOPS generic 
metods:
|  
|  (define-generic +)
|  (define-method (+ (a <string>) (b <string>))
|    (string-append a b))
|  
|  (+ 41 1)
|  => 42
|  
|  (+ "Foo" "bar")
|  => "Foobar"
|  

> The way I imagine it, is that you can put declarations on variables
> that the compiler is allowed to trust at compile-time, and one such
> declaration could be "this variable holds the R5RS primitive procedure
> '+' and will always hold it."  

In the presence of a generic method system (i.e. function dispatch on
the type signature of the arguments) this seems to be rather non-trivial,
or do you want to propose to make guile a strongly typed language ?

> This is a reasonable declaration to
> make.  The compiler could then inline the fixnum part of '+' and call
> out-of-line code for the rest.
> 
> So my next proposal is to add declarations to variables... :-)

And a type system ;-)

  Ralf 
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[rm]

On Thu, Aug 15, 2002 at 03:01:57AM -0500, Lynn Winebarger wrote:
>    Scheme is strongly typed.  It's just not statically typed.  Two different
> things.

I stand corrected. 'Statically' is what i meant.

  Thanks
      ralf
> Lynn
> 
> 
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[tomas]

On Wed, Aug 14, 2002 at 10:48:32PM +0200, Marius Vollmer wrote:
> tomas@fabula.de writes:
> 
> > On Wed, Aug 14, 2002 at 09:35:29PM +0200, Marius Vollmer wrote:
> >
> > > Read-onlyness should be a property of a variable that can be detected
> > > by the compiler so we wouldn't want to bury it only in the setter, I'd
> > > say.
> > 
> > For some kind of static integrity checking?
> 
> I had in mind that the compiler could use the bit to decide if it is
> allowed to inline some functions (such as '+', 'car', ...) but I no
> longer think that would be the right way.

It sure makes sense, but at another point (see also all the other
followups).  Those decisions are compile-time, and whether the
compiler gets its info from promises the user makes (kind of
type declarations) or from static code analysis -- it'd have
to have a richer per-variable data structure than just those two
bits.

The two bits you have envisioned seem to me a run-time thing (maybe
something the compiler might set after reaching its conclusions).

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Rob Browning]

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

> I'm currently writing up a proposal for a compilation/execution model.
> It's coming along nicely, but I don't want to show it until I have
> written down all the pieces.  Should be finished in a few days or so.

OK.  That's great.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Rob Browning]

rm@fabula.de writes:

> oops, i forgot to mention goops. I was thinking of GOOPS generic 
> metods:
> |  
> |  (define-generic +)
> |  (define-method (+ (a <string>) (b <string>))
> |    (string-append a b))
> |  
> |  (+ 41 1)
> |  => 42
> |  
> |  (+ "Foo" "bar")
> |  => "Foobar"
> |  

[...]

> In the presence of a generic method system (i.e. function dispatch on
> the type signature of the arguments) this seems to be rather non-trivial

Though I believe some languages (Dylan?, and perhaps also RScheme),
allow you to declare some functions/methods as "sealed".  Doing so
means that it should be an error for them to change values, or
"specialized", and the compiler can perform agressive optimizations on
them in the relevant code regions.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

rm@fabula.de writes:

> oops, i forgot to mention goops. I was thinking of GOOPS generic 
> metods:
> |  
> |  (define-generic +)
> |  (define-method (+ (a <string>) (b <string>))
> |    (string-append a b))
> |  
> |  (+ 41 1)
> |  => 42
> |  
> |  (+ "Foo" "bar")
> |  => "Foobar"
> |  

In this example you are creating a new variable with the name "+" and
store a new generic in it.  That variable would not carry the
declarations that the variable named "+" in the guile-core module
carries.  So the compiler would treat your variable "+" like any other
and wont perform wrong optimizations on it.

Actually, the builtin '+' function is already a generic; you can add
methods to it.  The compiler can not go ahead and inline all of '+',
but it might inline the first type dispatch for fixnums, which should
be by far the most frequent type to occur.

Guile-lightning can do a bit in this direction:

    (define-asm-macro (scm-add res a b)
      (let ((l0 (gensym "ll"))
            (l1 (gensym "ll")))
        `(  (bmc ,l0 ,a (scm 0))
            (bmc ,l0 ,b (scm 0))
            (sub ,res ,a (scm 0))
            (boadd ,l0 ,res ,b)
            (b ,l1)
          ,l0
            (prepare 2)
            (pusharg ,b)
            (pusharg ,a)
            (finish (subr "scm_sum"))
            (retval ,res)
          ,l1)))

This code will check whether the arguments are fixnums , and when both
are, perform the addition inline, checking for overflow.  When one is
not a fixnum, or the addition overflows, we call scm_sum to do it
right.  scm_sum does also include the Goops method dispatch.

This is way faster than having to fetch a value from a variable and
invoke the machinery to call arbitrary functions.

> In the presence of a generic method system (i.e. function dispatch
> on the type signature of the arguments) this seems to be rather
> non-trivial, or do you want to propose to make guile a [statically]
> typed language ?

No, no, no. :-) As you can see above, types are still checked at
run-time, but without having to call out-of-line functions all the
time.

> > So my next proposal is to add declarations to variables... :-)
> 
> And a type system ;-)

No, that would be fun, sure, but not in this life...

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

tomas@fabula.de writes:

> It sure makes sense, but at another point (see also all the other
> followups).  Those decisions are compile-time, and whether the
> compiler gets its info from promises the user makes (kind of
> type declarations) or from static code analysis -- it'd have
> to have a richer per-variable data structure than just those two
> bits.

Yes, but some parts of that data structure could be moved into the
variable cell, especially those that would be used right from the
start by our current memoizer.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[rm]

On Thu, Aug 15, 2002 at 06:34:28PM +0200, Marius Vollmer wrote:
> rm@fabula.de writes:
> 
> > oops, i forgot to mention goops. I was thinking of GOOPS generic 
> > metods:
> > |  
> > |  (define-generic +)
> > |  (define-method (+ (a <string>) (b <string>))
> > |    (string-append a b))
> > |  
> > |  (+ 41 1)
> > |  => 42
> > |  
> > |  (+ "Foo" "bar")
> > |  => "Foobar"
> > |  
> 
> In this example you are creating a new variable with the name "+" and
> store a new generic in it.  That variable would not carry the
> declarations that the variable named "+" in the guile-core module
> carries.  So the compiler would treat your variable "+" like any other
> and wont perform wrong optimizations on it.

Symbolic code, so to say -- i wasn't shure about whether '+' was all-
ready a "generic". Couldn't test my code due to guile segfaulting (see
my bugreport :)
BTW, i'm not really happy with guiles current behavior regarding declaring
a generic that's allready existing. I'd expect that a (define-generic foo)
on a function that's allready will be a no-opt.  The call (and syntax)
of define-generic "feels" like a compiler makro and not like something
that creates a new binding for its only parameter. I just tried my own
code and was astonished to see that after my declaration the primitive
'+' wasn't  reachable anymore :-/ Now, i could (perhaps, i'm an inpatient
person) live with that iff there was an easy way to test whether something
is allready declared generic, but:

 (use-modules (oop goops))
 +
 =>  #<primitive-procedure +>
 (define-method (+ (a <string>) (b <string>)) (string-append a b))
 +
 => #<primitive-generic +>

Humpf! I know, this is actually a nice optimisation in this code, but
it shouldn't be so visible.


[...]
> 
> > In the presence of a generic method system (i.e. function dispatch
> > on the type signature of the arguments) this seems to be rather
> > non-trivial, or do you want to propose to make guile a [statically]
> > typed language ?
> 
> No, no, no. :-) As you can see above, types are still checked at
> run-time, but without having to call out-of-line functions all the
> time.

So, if i understand you right, the compiler would generate code
that contains _two_ branches, one for the fast numeric code 
(inlined) and one for the normal generic  method dispatch?

> > > So my next proposal is to add declarations to variables... :-)
> > 
> > And a type system ;-)
> 
> No, that would be fun, sure, but not in this life...

As long as guile1.6 get's out in time ;-)

 Ralf


> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

rm@fabula.de writes:

> BTW, i'm not really happy with guiles current behavior regarding declaring
> a generic that's allready existing. I'd expect that a (define-generic foo)
> on a function that's allready will be a no-opt.

Me neither.

>  (use-modules (oop goops))
>  +
>  =>  #<primitive-procedure +>
>  (define-method (+ (a <string>) (b <string>)) (string-append a b))
>  +
>  => #<primitive-generic +>
> 
> Humpf! I know, this is actually a nice optimisation in this code, but
> it shouldn't be so visible.

Should it print #<primitive-generic +> from the start?

> So, if i understand you right, the compiler would generate code that
> contains _two_ branches, one for the fast numeric code (inlined) and
> one for the normal generic method dispatch?

Yes.
 
-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

rm@fabula.de writes:

> > Should it print #<primitive-generic +> from the start?
> 
> Since it actually _is_ a generic from the start, yes, i think it should.

Ok, agreed.  Objections?

> Of course, what i'm really after is a test like 'generic? foo' so that
> i can write a macro that does what i think guile should do. Make 'foo'
> a generic iff it's not one allready.

You can't really do that I think.  You can't change a procedure into a
generic function.  What you can do is change the value of a variable
to point to a new function, which is generic.  But maybe that is what
you want.

There is no 'generic?' but you can maybe define it like so

  (define (generic? obj)
    (or (is-a? obj <generic>)
        (is-a? obj <primitive-generic>)))

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[rm]

On Thu, Aug 15, 2002 at 09:43:00PM +0200, Marius Vollmer wrote:
> rm@fabula.de writes:
> 
> > BTW, i'm not really happy with guiles current behavior regarding declaring
> > a generic that's allready existing. I'd expect that a (define-generic foo)
> > on a function that's allready will be a no-opt.
> 
> Me neither.

I recall a discussion about that topic a while ago. I know i felt
uneasy back then ....

> >  (use-modules (oop goops))
> >  +
> >  =>  #<primitive-procedure +>
> >  (define-method (+ (a <string>) (b <string>)) (string-append a b))
> >  +
> >  => #<primitive-generic +>
> > 
> > Humpf! I know, this is actually a nice optimisation in this code, but
> > it shouldn't be so visible.
> 
> Should it print #<primitive-generic +> from the start?

Since it actually _is_ a generic from the start, yes, i think it should.
Of course, what i'm really after is a test like 'generic? foo' so that
i can write a macro that does what i think guile should do. Make 'foo'
a generic iff it's not one allready.

> > So, if i understand you right, the compiler would generate code that
> > contains _two_ branches, one for the fast numeric code (inlined) and
> > one for the normal generic method dispatch?
> 
> Yes.

Ah, thank's for the clarification.

  Ralf

> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[rm]

On Thu, Aug 15, 2002 at 10:02:09PM +0200, Marius Vollmer wrote:
> rm@fabula.de writes:
> 
> > > Should it print #<primitive-generic +> from the start?
> > 
> > Since it actually _is_ a generic from the start, yes, i think it should.
> 
> Ok, agreed.  Objections?
> 
> > Of course, what i'm really after is a test like 'generic? foo' so that
> > i can write a macro that does what i think guile should do. Make 'foo'
> > a generic iff it's not one allready.
> 
> You can't really do that I think.  You can't change a procedure into a
> generic function.  What you can do is change the value of a variable
> to point to a new function, which is generic.  But maybe that is what
> you want.

Excuse my slopy language - i was thinking more of the net result.
So i guess my macro would have to save the original value (the one
pointing to the procedure) and then, after a define-generic, issue
a define method that rebinds the value to a generic method with 
a parameter signature of '<object>'. Kind of clumsy.

> There is no 'generic?' but you can maybe define it like so

I couldn't find one (which i found astonishing as well).

>   (define (generic? obj)
>     (or (is-a? obj <generic>)
>         (is-a? obj <primitive-generic>)))

Yes, i guess that would do the trick.

  Ralf

 :
> 
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Neil Jerram]

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

    Marius> rm@fabula.de writes:
    >> > Should it print #<primitive-generic +> from the start?
    >> 
    >> Since it actually _is_ a generic from the start, yes, i think it should.

    Marius> Ok, agreed.  Objections?

Sounds OK.  Eventually, though, I presume what we _really_ want is for
_all_ Guile procedures to be generic.  Once we achieve this, it will
no longer signify anything to say #<primitive-generic> rather than
#<primitive-procedure>, because there won't be any non-generic
procedures left.

    >> Of course, what i'm really after is a test like 'generic? foo' so that
    >> i can write a macro that does what i think guile should do. Make 'foo'
    >> a generic iff it's not one allready.

    Marius> You can't really do that I think.  You can't change a procedure into a
    Marius> generic function.  What you can do is change the value of a variable
    Marius> to point to a new function, which is generic.  But maybe that is what
    Marius> you want.

Sure?  I think that subrs at least are made generic by filling in a
preexisting slot in the subr structure; variable binding doesn't need
to change.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

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

> rm@fabula.de writes:
> 
> > > Should it print #<primitive-generic +> from the start?
> > 
> > Since it actually _is_ a generic from the start, yes, i think it should.
> 
> Ok, agreed.  Objections?

Done.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[rm]

On Tue, Aug 20, 2002 at 01:29:16AM +0200, Marius Vollmer wrote:
> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > rm@fabula.de writes:
> > 
> > > > Should it print #<primitive-generic +> from the start?
> > > 
> > > Since it actually _is_ a generic from the start, yes, i think it should.
> > 
> > Ok, agreed.  Objections?
> 
> Done.

Allmost, if i might say so ;-)

*---------------------------------------------------------------------------
|  
|  ralf@calvin:~$ guile
|  guile> (use-modules (oop goops))
|  guile> (class-of +)
|  #<<procedure-class> <procedure> 808f6f0>
|  guile> (define-method (+ (a <string>) (b <string>)) (string-append a b))
|  guile> (class-of +)guile> (class-of +)
|  #<<procedure-class> <primitive-generic> 808f690>
|  guile> ralf@calvin:~$ exit
|  

I don't know how easy this is to fix but this is the kind of code 
one might want to use to test whether '(define-generic foo)' has to
be called. If the class of 'foo' only changes to 'primitve-generic'
after a call to 'define-method' that doesn't really help, or?

 Ralf

But thank's anyway.
> 
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
> 
> 
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Smart variables, dumb variables

[Marius Vollmer]

rm@fabula.de writes:

> Allmost, if i might say so ;-)
> 
> *---------------------------------------------------------------------------
> |  
> |  ralf@calvin:~$ guile
> |  guile> (use-modules (oop goops))
> |  guile> (class-of +)
> |  #<<procedure-class> <procedure> 808f6f0>
> |  guile> (define-method (+ (a <string>) (b <string>)) (string-append a b))
> |  guile> (class-of +)guile> (class-of +)
> |  #<<procedure-class> <primitive-generic> 808f690>
> |  guile> ralf@calvin:~$ exit
> |  
> 
> I don't know how easy this is to fix

It's non-trivial, due to bootstrap issues with Goops.  If anyone wants
to work on this, that would be great. I don't think I will be getting
around to this any time soon.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel