* Smart variables, dumb variables @ 2002-08-13 20:06 Marius Vollmer 2002-08-14 8:07 ` tomas ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Marius Vollmer @ 2002-08-13 20:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-13 20:06 Smart variables, dumb variables Marius Vollmer @ 2002-08-14 8:07 ` tomas 2002-08-14 19:35 ` Marius Vollmer 2002-08-14 21:31 ` Rob Browning 2002-08-15 2:43 ` Rob Browning 2 siblings, 1 reply; 28+ messages in thread From: tomas @ 2002-08-14 8:07 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 8:07 ` tomas @ 2002-08-14 19:35 ` Marius Vollmer 2002-08-14 20:28 ` tomas 0 siblings, 1 reply; 28+ messages in thread From: Marius Vollmer @ 2002-08-14 19:35 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 19:35 ` Marius Vollmer @ 2002-08-14 20:28 ` tomas 2002-08-14 20:48 ` Marius Vollmer 0 siblings, 1 reply; 28+ messages in thread From: tomas @ 2002-08-14 20:28 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 20:28 ` tomas @ 2002-08-14 20:48 ` Marius Vollmer 2002-08-14 21:06 ` rm 2002-08-15 10:52 ` tomas 0 siblings, 2 replies; 28+ messages in thread From: Marius Vollmer @ 2002-08-14 20:48 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 20:48 ` Marius Vollmer @ 2002-08-14 21:06 ` rm 2002-08-14 21:09 ` Marius Vollmer 2002-08-15 10:52 ` tomas 1 sibling, 1 reply; 28+ messages in thread From: rm @ 2002-08-14 21:06 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 21:06 ` rm @ 2002-08-14 21:09 ` Marius Vollmer 2002-08-15 8:06 ` rm 0 siblings, 1 reply; 28+ messages in thread From: Marius Vollmer @ 2002-08-14 21:09 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 21:09 ` Marius Vollmer @ 2002-08-15 8:06 ` rm 2002-08-15 8:01 ` Lynn Winebarger ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: rm @ 2002-08-15 8:06 UTC (permalink / raw) Cc: rm, tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 8:06 ` rm @ 2002-08-15 8:01 ` Lynn Winebarger 2002-08-15 9:51 ` rm 2002-08-15 14:44 ` Rob Browning 2002-08-15 16:34 ` Marius Vollmer 2 siblings, 1 reply; 28+ messages in thread From: Lynn Winebarger @ 2002-08-15 8:01 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 8:01 ` Lynn Winebarger @ 2002-08-15 9:51 ` rm 0 siblings, 0 replies; 28+ messages in thread From: rm @ 2002-08-15 9:51 UTC (permalink / raw) Cc: rm, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 8:06 ` rm 2002-08-15 8:01 ` Lynn Winebarger @ 2002-08-15 14:44 ` Rob Browning 2002-08-15 16:34 ` Marius Vollmer 2 siblings, 0 replies; 28+ messages in thread From: Rob Browning @ 2002-08-15 14:44 UTC (permalink / raw) Cc: Marius Vollmer, tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 8:06 ` rm 2002-08-15 8:01 ` Lynn Winebarger 2002-08-15 14:44 ` Rob Browning @ 2002-08-15 16:34 ` Marius Vollmer 2002-08-15 17:27 ` rm 2 siblings, 1 reply; 28+ messages in thread From: Marius Vollmer @ 2002-08-15 16:34 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 16:34 ` Marius Vollmer @ 2002-08-15 17:27 ` rm 2002-08-15 19:43 ` Marius Vollmer 0 siblings, 1 reply; 28+ messages in thread From: rm @ 2002-08-15 17:27 UTC (permalink / raw) Cc: rm, tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 17:27 ` rm @ 2002-08-15 19:43 ` Marius Vollmer 2002-08-15 20:02 ` rm 0 siblings, 1 reply; 28+ messages in thread From: Marius Vollmer @ 2002-08-15 19:43 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 19:43 ` Marius Vollmer @ 2002-08-15 20:02 ` rm 2002-08-15 20:02 ` Marius Vollmer 0 siblings, 1 reply; 28+ messages in thread From: rm @ 2002-08-15 20:02 UTC (permalink / raw) Cc: rm, tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 20:02 ` rm @ 2002-08-15 20:02 ` Marius Vollmer 2002-08-15 20:25 ` rm ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Marius Vollmer @ 2002-08-15 20:02 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 20:02 ` Marius Vollmer @ 2002-08-15 20:25 ` rm 2002-08-17 11:59 ` Neil Jerram 2002-08-19 23:29 ` Marius Vollmer 2 siblings, 0 replies; 28+ messages in thread From: rm @ 2002-08-15 20:25 UTC (permalink / raw) Cc: rm, tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 20:02 ` Marius Vollmer 2002-08-15 20:25 ` rm @ 2002-08-17 11:59 ` Neil Jerram 2002-08-19 23:29 ` Marius Vollmer 2 siblings, 0 replies; 28+ messages in thread From: Neil Jerram @ 2002-08-17 11:59 UTC (permalink / raw) Cc: rm, tomas, guile-devel >>>>> "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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 20:02 ` Marius Vollmer 2002-08-15 20:25 ` rm 2002-08-17 11:59 ` Neil Jerram @ 2002-08-19 23:29 ` Marius Vollmer 2002-08-20 12:01 ` rm 2 siblings, 1 reply; 28+ messages in thread From: Marius Vollmer @ 2002-08-19 23:29 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-19 23:29 ` Marius Vollmer @ 2002-08-20 12:01 ` rm 2002-08-26 22:06 ` Marius Vollmer 0 siblings, 1 reply; 28+ messages in thread From: rm @ 2002-08-20 12:01 UTC (permalink / raw) Cc: rm, tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-20 12:01 ` rm @ 2002-08-26 22:06 ` Marius Vollmer 0 siblings, 0 replies; 28+ messages in thread From: Marius Vollmer @ 2002-08-26 22:06 UTC (permalink / raw) Cc: tomas, guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 20:48 ` Marius Vollmer 2002-08-14 21:06 ` rm @ 2002-08-15 10:52 ` tomas 2002-08-15 16:36 ` Marius Vollmer 1 sibling, 1 reply; 28+ messages in thread From: tomas @ 2002-08-15 10:52 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 10:52 ` tomas @ 2002-08-15 16:36 ` Marius Vollmer 0 siblings, 0 replies; 28+ messages in thread From: Marius Vollmer @ 2002-08-15 16:36 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-13 20:06 Smart variables, dumb variables Marius Vollmer 2002-08-14 8:07 ` tomas @ 2002-08-14 21:31 ` Rob Browning 2002-08-14 21:45 ` Marius Vollmer 2002-08-15 2:43 ` Rob Browning 2 siblings, 1 reply; 28+ messages in thread From: Rob Browning @ 2002-08-14 21:31 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-14 21:31 ` Rob Browning @ 2002-08-14 21:45 ` Marius Vollmer 0 siblings, 0 replies; 28+ messages in thread From: Marius Vollmer @ 2002-08-14 21:45 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-13 20:06 Smart variables, dumb variables Marius Vollmer 2002-08-14 8:07 ` tomas 2002-08-14 21:31 ` Rob Browning @ 2002-08-15 2:43 ` Rob Browning 2002-08-15 6:29 ` Marius Vollmer 2 siblings, 1 reply; 28+ messages in thread From: Rob Browning @ 2002-08-15 2:43 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 2:43 ` Rob Browning @ 2002-08-15 6:29 ` Marius Vollmer 2002-08-15 14:38 ` Rob Browning 0 siblings, 1 reply; 28+ messages in thread From: Marius Vollmer @ 2002-08-15 6:29 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Smart variables, dumb variables 2002-08-15 6:29 ` Marius Vollmer @ 2002-08-15 14:38 ` Rob Browning 0 siblings, 0 replies; 28+ messages in thread From: Rob Browning @ 2002-08-15 14:38 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2002-08-26 22:06 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-08-13 20:06 Smart variables, dumb variables Marius Vollmer 2002-08-14 8:07 ` tomas 2002-08-14 19:35 ` Marius Vollmer 2002-08-14 20:28 ` tomas 2002-08-14 20:48 ` Marius Vollmer 2002-08-14 21:06 ` rm 2002-08-14 21:09 ` Marius Vollmer 2002-08-15 8:06 ` rm 2002-08-15 8:01 ` Lynn Winebarger 2002-08-15 9:51 ` rm 2002-08-15 14:44 ` Rob Browning 2002-08-15 16:34 ` Marius Vollmer 2002-08-15 17:27 ` rm 2002-08-15 19:43 ` Marius Vollmer 2002-08-15 20:02 ` rm 2002-08-15 20:02 ` Marius Vollmer 2002-08-15 20:25 ` rm 2002-08-17 11:59 ` Neil Jerram 2002-08-19 23:29 ` Marius Vollmer 2002-08-20 12:01 ` rm 2002-08-26 22:06 ` Marius Vollmer 2002-08-15 10:52 ` tomas 2002-08-15 16:36 ` Marius Vollmer 2002-08-14 21:31 ` Rob Browning 2002-08-14 21:45 ` Marius Vollmer 2002-08-15 2:43 ` Rob Browning 2002-08-15 6:29 ` Marius Vollmer 2002-08-15 14:38 ` Rob Browning
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).