In article <·················@setf.de>,
james anderson <··············@setf.de> writes:
>
> is there an active newsgroup or mailing list for CLIM users?
> i've found the one at bbn, but it seems uninhabited.
Well, since CLIM stands for Common Lisp Interface Manager and this is
primarily a Common Lisp newsgroup, you could always ask here. I know there are
several other people interested in CLIM who readthis group regularly.
Mike McDonald
·······@mikemac.com
From: james anderson
Subject: Re: ? a forum for CLIM questions
Date:
Message-ID: <3CB33330.E05891DF@setf.de>
Mike McDonald wrote:
>
> In article <·················@setf.de>,
> james anderson <··············@setf.de> writes:
> >
> > is there an active newsgroup or mailing list for CLIM users?
> > i've found the one at bbn, but it seems uninhabited.
>
> Well, since CLIM stands for Common Lisp Interface Manager and this is
> primarily a Common Lisp newsgroup, you could always ask here.
ok.
1. where is the appropriate place to bind properties which characterise
the presentation of a datum, as opposed to the domain of the datum. i
gather that properties of the latter sort are best described with
presentation parameters. properties of the former sort might be
described with presentation options. the problem is, the interface
appears to intend that these options be re-evaluated each time a
presentation type is referenced. whereby the evaluation takes place in
the reference environment. this makes them ill suited for values which
are either expensive to compute or available only in the environment in
which the presentation type was either defined or generated. i am
considering specializing the view arguments to accommodate such properties.
2. the interaction model for dialogs / forms seems very synchronous.
where one seeks to support alternative stream forms and/or interaction
models, accepting-values itself offers no standard programming interface
and has an exceedingly terse description for its processing protocol. it
is not clear which of the methods among stream-accept,
accept-present-default, accept, present, etc are the intended domain for specialization.
3. how does one specialize methods for presentation type parameters when
the functions are not presentation functions? one example is stream
accept. my present clim implementation uses what appear to be very
implementation-specific names for presentation type classes. it would be
inappropriate to use them directly. even if one were to use #.forms in
defmethod specializer, one would need a general method to generate the
presentation type class name from lisp class names.
questions of that sort.
...
On Tue, 09 Apr 2002 20:30:26 +0200, james anderson <··············@setf.de>
wrote:
>Mike McDonald wrote:
>>
>> In article <·················@setf.de>,
>> james anderson <··············@setf.de> writes:
>> >
>> > is there an active newsgroup or mailing list for CLIM users?
>> > i've found the one at bbn, but it seems uninhabited.
>>
>> Well, since CLIM stands for Common Lisp Interface Manager and this is
>> primarily a Common Lisp newsgroup, you could always ask here.
>
>ok.
I'd like to see these questions here, if the c.l.l. regulars don't
mind. Here's my best shot, as a newbie CLIM user and implementor :) :
>1. where is the appropriate place to bind properties which characterise
>the presentation of a datum, as opposed to the domain of the datum. i
>gather that properties of the latter sort are best described with
>presentation parameters. properties of the former sort might be
>described with presentation options. the problem is, the interface
>appears to intend that these options be re-evaluated each time a
>presentation type is referenced. whereby the evaluation takes place in
I'm not sure what you mean by "evaluated". An options argument can
be any value, e.g. a list or instance or whatever. You can store
whatever you like there.
>the reference environment. this makes them ill suited for values which
>are either expensive to compute or available only in the environment in
>which the presentation type was either defined or generated. i am
>considering specializing the view arguments to accommodate such properties.
A specialized view might be appropriate if you can't do what you want
using options arguments in a presentation method written on PRESENT.
>2. the interaction model for dialogs / forms seems very synchronous.
>where one seeks to support alternative stream forms and/or interaction
>models, accepting-values itself offers no standard programming interface
>and has an exceedingly terse description for its processing protocol. it
>is not clear which of the methods among stream-accept,
>accept-present-default, accept, present, etc are the intended domain for
> specialization.
Modifying the behavior of accepting-values is probably a lose,
although accept-present-default seems like the most productive hook
in. You'd probably do better writing your own command loop.
>3. how does one specialize methods for presentation type parameters when
>the functions are not presentation functions? one example is stream
>accept. my present clim implementation uses what appear to be very
>implementation-specific names for presentation type classes. it would be
>inappropriate to use them directly. even if one were to use #.forms in
>defmethod specializer, one would need a general method to generate the
>presentation type class name from lisp class names.
The short answer is: you don't :) If your implementation specializes
on the type argument of stream-accept, it's using the classes that are
the proxies for presentation types in presentation method dispatch,
and that's implementation specific.
You specialize presentation generic functions such as ACCEPT by
writing presentation generic methods. If you need to hook in before
the ACCEPT presentation method is called, I guess you'd do this:
Define a presentation generic function that does what you want;
Define your own stream subclass;
Write a method on stream-accept or accept-1 specialized on that class
that calls your presentation generic function instead of or in
addition to the other machinery of accept;
Write presentation method on your new function.
>
>questions of that sort.
>
Again, I'd love to see questions and answers about CLIM here to get
more exposure for it and to answer my own questions as well :)
Tim
From: james anderson
Subject: Re: ? a forum for CLIM questions
Date:
Message-ID: <3CB35FE7.422C2A64@setf.de>
Tim Moore wrote:
>
>
> >1. where is the appropriate place to bind properties which characterise
> >the presentation of a datum, as opposed to the domain of the datum. i
> >gather that properties of the latter sort are best described with
> >presentation parameters. properties of the former sort might be
> >described with presentation options. the problem is, the interface
> >appears to intend that these options be re-evaluated each time a
> >presentation type is referenced. whereby the evaluation takes place in
>
> I'm not sure what you mean by "evaluated". An options argument can
> be any value, e.g. a list or instance or whatever. You can store
> whatever you like there.
i have observed two implementation. both record the forms which appeared
in the presentation type definition and arrange that those forms
reappear as default values for a keyword argument list at the point
where the presentation type is referenced. this causes the definition
forms to be evaluated there.
>
> >the reference environment. this makes them ill suited for values which
> >are either expensive to compute or available only in the environment in
> >which the presentation type was either defined or generated. i am
> >considering specializing the view arguments to accommodate such properties.
>
> A specialized view might be appropriate if you can't do what you want
> using options arguments in a presentation method written on PRESENT.
my goal is to encapsulate information which is derived automatically
from meta-object or other declarative information without requiring that
the application manage it explicitly. this argues against requiring that
it appear as one of the other presentation method keyword arguments.
>
> >2. the interaction model for dialogs / forms seems very synchronous.
> >where one seeks to support alternative stream forms and/or interaction
> >models, accepting-values itself offers no standard programming interface
> >and has an exceedingly terse description for its processing protocol. it
> >is not clear which of the methods among stream-accept,
> >accept-present-default, accept, present, etc are the intended domain for
> > specialization.
>
> Modifying the behavior of accepting-values is probably a lose,
> although accept-present-default seems like the most productive hook
> in. You'd probably do better writing your own command loop.
>
ok. something which gave one a clearer view of the protocol would be
nice. the source from one of the implementations helps. as do the
occasional remarks in the spec and the documentation. in the end,
however, this lacks the clarity of something like the descriptions of
instance initialization in the mop.
> >3. how does one specialize methods for presentation type parameters when
> >the functions are not presentation functions? one example is stream
> >accept. my present clim implementation uses what appear to be very
> >implementation-specific names for presentation type classes. it would be
> >inappropriate to use them directly. even if one were to use #.forms in
> >defmethod specializer, one would need a general method to generate the
> >presentation type class name from lisp class names.
>
> The short answer is: you don't :) If your implementation specializes
> on the type argument of stream-accept, it's using the classes that are
> the proxies for presentation types in presentation method dispatch,
> and that's implementation specific.
why?
i don't understand this distinction. isn't this the same as the type
argument in presentation methods?
>
> You specialize presentation generic functions such as ACCEPT by
> writing presentation generic methods. If you need to hook in before
> the ACCEPT presentation method is called, I guess you'd do this:
>
one of the descriptions suggested that the purpose of stream-accept was
to afford an avenue for specialization. why on the first argument only?
> Define a presentation generic function that does what you want;
> Define your own stream subclass;
> Write a method on stream-accept or accept-1 specialized on that class
> that calls your presentation generic function instead of or in
> addition to the other machinery of accept;
> Write presentation method on your new function.
that's what i was contemplating. possessed by the feeling that i must be
missing something.
>
> >
> >questions of that sort.
> >
>
> Again, I'd love to see questions and answers about CLIM here to get
> more exposure for it and to answer my own questions as well :)
>
> Tim
On Tue, 09 Apr 2002 23:41:18 +0200, james anderson <··············@setf.de>
wrote:
>>
>>
>> >1. where is the appropriate place to bind properties which characterise
>> >the presentation of a datum, as opposed to the domain of the datum. i
>> >gather that properties of the latter sort are best described with
>> >presentation parameters. properties of the former sort might be
>> >described with presentation options. the problem is, the interface
>> >appears to intend that these options be re-evaluated each time a
>> >presentation type is referenced. whereby the evaluation takes place in
>>
>Tim Moore wrote:
>> I'm not sure what you mean by "evaluated". An options argument can
>> be any value, e.g. a list or instance or whatever. You can store
>> whatever you like there.
>
>i have observed two implementation. both record the forms which appeared
>in the presentation type definition and arrange that those forms
>reappear as default values for a keyword argument list at the point
>where the presentation type is referenced. this causes the definition
>forms to be evaluated there.
You're talking about the default values for presentation type options,
but that's a different story from options argument values in a
presentation type specifier; those are not "re-evaluated." It
shouldn't be a problem to do e.g.
(define-presentation-type my-type () :options (presentation-properties))
(present my-object
`((my-type)
:presentation-properties ,(make-instance 'hairy-properties)))
>> A specialized view might be appropriate if you can't do what you want
>> using options arguments in a presentation method written on PRESENT.
>
>my goal is to encapsulate information which is derived automatically
>from meta-object or other declarative information without requiring that
>the application manage it explicitly. this argues against requiring that
>it appear as one of the other presentation method keyword arguments.
Not presentation method arguments, presentation type options.
>ok. something which gave one a clearer view of the protocol would be
>nice. the source from one of the implementations helps. as do the
>occasional remarks in the spec and the documentation. in the end,
>however, this lacks the clarity of something like the descriptions of
>instance initialization in the mop.
Yes, that'd be nice :)
>> >3. how does one specialize methods for presentation type parameters when
>> >the functions are not presentation functions? one example is stream
>> >accept. my present clim implementation uses what appear to be very
>> >implementation-specific names for presentation type classes. it would be
>> >inappropriate to use them directly. even if one were to use #.forms in
>> >defmethod specializer, one would need a general method to generate the
>> >presentation type class name from lisp class names.
>>
>> The short answer is: you don't :) If your implementation specializes
>> on the type argument of stream-accept, it's using the classes that are
>> the proxies for presentation types in presentation method dispatch,
>> and that's implementation specific.
>
>why?
>i don't understand this distinction. isn't this the same as the type
>argument in presentation methods?
The presentation type specifier argument that you pass to a
presentation function like ACCEPT is a symbol or list. Presentation
method dispatch behaves like CLOS method dispatch, so an
implementation typically uses CLOS objects as proxies for presentation
types in order to get inheritance and method dispatch mostly right.
However, there is additional hair in presentation method dispatch:
expanding the parameters and options for supertype methods. So, the
exact implementation of the proxy mechanism is left unspecified,
although hints of it do slip into the spec.
>one of the descriptions suggested that the purpose of stream-accept was
>to afford an avenue for specialization. why on the first argument
>only?
Because stream-accept is a generic function, not a presentation
generic function.
Tim
From: james anderson
Subject: Re: ? a forum for CLIM questions
Date:
Message-ID: <3CB389A3.8CDD1E47@setf.de>
Tim Moore wrote:
>
> >
> >i have observed two implementation. both record the forms which appeared
> >in the presentation type definition and arrange that those forms
> >reappear as default values for a keyword argument list at the point
> >where the presentation type is referenced. this causes the definition
> >forms to be evaluated there.
>
> You're talking about the default values for presentation type options,
which is what i would compute. as in generally applicable to all of that
class of presentation.
> but that's a different story from options argument values in a
> presentation type specifier; those are not "re-evaluated." It
> shouldn't be a problem to do e.g.
>
> (define-presentation-type my-type () :options (presentation-properties))
> (present my-object
> `((my-type)
> :presentation-properties ,(make-instance 'hairy-properties)))
>
> >> A specialized view might be appropriate if you can't do what you want
> >> using options arguments in a presentation method written on PRESENT.
> >
> >my goal is to encapsulate information which is derived automatically
> >from meta-object or other declarative information without requiring that
> >the application manage it explicitly. this argues against requiring that
> >it appear as one of the other presentation method keyword arguments.
>
> Not presentation method arguments, presentation type options.
presentation type option arguments? with the ensuing problem with the
evaluation environment.
>
> ...
>
> The presentation type specifier argument that you pass to a
> presentation function like ACCEPT is a symbol or list. Presentation
> method dispatch behaves like CLOS method dispatch, so an
> implementation typically uses CLOS objects as proxies for presentation
> types in order to get inheritance and method dispatch mostly right.
> However, there is additional hair in presentation method dispatch:
> expanding the parameters and options for supertype methods. So, the
> exact implementation of the proxy mechanism is left unspecified,
> although hints of it do slip into the spec.
>
> ..
ok. that second argument is the presentation type instance, not the
proxy instance.
>
> Tim
On Wed, 10 Apr 2002 02:39:27 +0200, james anderson <··············@setf.de>
wrote:
>
>
>Tim Moore wrote:
>>
>> >
>> >i have observed two implementation. both record the forms which appeared
>> >in the presentation type definition and arrange that those forms
>> >reappear as default values for a keyword argument list at the point
>> >where the presentation type is referenced. this causes the definition
>> >forms to be evaluated there.
>>
>> You're talking about the default values for presentation type options,
>
>which is what i would compute. as in generally applicable to all of that
>class of presentation.
I think I see where you're going with this. Even though the default argument
may be evaluated, it can still be a constant, which can be as simple
or complex as you want. Furthermore, if you want to avoid a compile
time dependence on the type options in your dynamically created
presentation types, you can write the presentation methods on a
supertype that has simple options. Here's a quick sketch:
(define-presentation-type my-super-ptype () :options (presentation-properties))
(define-presentation-method present (object (type my-type) stream view
&allow-other-keys)
(display-with-properties object presentation-properties))
(defmacro defptype (class)
(let ((properties (make-presentation-properties class))
(supers (get-superclasses class)))
`(define-presentation-type ,class ()
:options ((presentation-properties ',properties))
:inherits-from '(and ,@supers
((my-ptype)
:presentation-properties ,properties)))))
The last could be something eval'ed if you wanted to do it completely
dynamically.
If make-presentation-properties return a list you're done. If you want
make-presentation-properties to return a CLOS instance, then you have to write
a make-load-form method so it can be dumped as a constant.
>> >my goal is to encapsulate information which is derived automatically
>> >from meta-object or other declarative information without requiring that
>> >the application manage it explicitly. this argues against requiring that
>> >it appear as one of the other presentation method keyword arguments.
>>
>> Not presentation method arguments, presentation type options.
>
>presentation type option arguments? with the ensuing problem with the
>evaluation environment.
>
See above.
Tim
From: james anderson
Subject: Re: ? a forum for CLIM questions
Date:
Message-ID: <3CB3EC93.D83B212D@setf.de>
Tim Moore wrote:
>
> ...
>
> I think I see where you're going with this. Even though the default argument
> may be evaluated, it can still be a constant, which can be as simple
> or complex as you want. Furthermore, if you want to avoid a compile
> time dependence on the type options in your dynamically created
> presentation types, you can write the presentation methods on a
> supertype that has simple options. Here's a quick sketch:
>
> (define-presentation-type my-super-ptype () :options (presentation-properties))
>
> (define-presentation-method present (object (type my-type) stream view
> &allow-other-keys)
> (display-with-properties object presentation-properties))
>
> (defmacro defptype (class)
> (let ((properties (make-presentation-properties class))
> (supers (get-superclasses class)))
> `(define-presentation-type ,class ()
> :options ((presentation-properties ',properties))
> :inherits-from '(and ,@supers
> ((my-ptype)
> :presentation-properties ,properties)))))
>
> The last could be something eval'ed if you wanted to do it completely
> dynamically.
>
i still see only two alternatives here. evaluation in the compile time
environment and evaluation in the reference environment. if that's
really the intended way to accomplish such things, i suppose i could
live with the former, but it's still not evaluation at the point of definition.
...
james anderson <··············@setf.de> writes:
> i still see only two alternatives here. evaluation in the compile
> time environment and evaluation in the reference environment. if
> that's really the intended way to accomplish such things, i suppose
> i could live with the former, but it's still not evaluation at the
> point of definition.
I don't understand what the "point of definition" is other than
compile (macroexpand) time. Do you mean read-time? if so, use
#.(make-instance ...). No idea what you'd gain from that in this
situation, tho.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: james anderson
Subject: Re: ? a forum for CLIM questions
Date:
Message-ID: <3CB36123.D1E87B16@setf.de>
james anderson wrote:
>
> Tim Moore wrote:
>
> >
> > >2. the interaction model for dialogs / forms seems very synchronous.
> > >where one seeks to support alternative stream forms and/or interaction
> > >models, accepting-values itself offers no standard programming interface
> > >and has an exceedingly terse description for its processing protocol. it
> > >is not clear which of the methods among stream-accept,
> > >accept-present-default, accept, present, etc are the intended domain for
> > > specialization.
> >
> > Modifying the behavior of accepting-values is probably a lose,
> > although accept-present-default seems like the most productive hook
> > in. You'd probably do better writing your own command loop.
> >
>
> ok. something which gave one a clearer view of the protocol would be
> nice. the source from one of the implementations helps. as do the
> occasional remarks in the spec and the documentation. in the end,
> however, this lacks the clarity of something like the descriptions of
> instance initialization in the mop.
>
which makes it hard to write an alternative command loop, beacuse it's
not clear what it need to do in order that things like accept,
accept-present-default, present, ... interact correctly.
...