9:34 a.m.
Eric Marsden <emarsden(a)mail.dotcom.fr> writes:
[Yet another message marked for "Rereading when there is a non-zero
amount of free time]
EIEIO is at <URL:http://www.ultranet.com/~zappo/eieio.shtml>
(with
stuff like this I occasionally manage to forget I'm programming in a
crummy imitation of a Lisp :-).
Now that we have your attention. I have been wanting to look into this
for some time, but still haven't come around to it. Are there any
bottlenecks or imperfections with EIEIO that could be solved with a
little help from the C core?
For instance I am thinking of
opaque-cons (car cdr)
Internal function. Like cons, but the return value is an opaque type
and will signal an error unless passed to opaque-*
opaque-car (ocons)
opaque-cdr (ocons)
opaque-to-cons (ocons)
opaque-cons-p (ocons)
Then you would have in usertype.el
(defun deftype (type operations)
(put type 'type-operations operations)
(define-function
(make-symbol (cons "make-" (symbol-name type))) '(value)
`(opaque-cons ,type value))
(define-function
(make-symbol (cons (symbol-name type))) "-value" '(t)
`((let ((c (opaque-to-cons t)))
(if (eq (car c) ,type)
(cdr c)
(error 'type-error "....")))))
(define-function
(make-symbol (cons (symbol-name type))) "-p" '(t)
`(and (opaque-cons-p t) (eq (opaque-car t) ,type))))
etc
Jan
5:29 a.m.
New subject: database functionality (was Re: [21.2] LDAP add and delete functions + interrupt fixes)
I had absolutely no idea about the existence of EIEIO.
Why isn't this an XEmacs package? Or even better, why isn't it
distributed as a *standard* part of the distribution?
Eric (Ludlam): Please read what Jan has to say below. If there is any
change to the C code of XEmacs that would make EIEIO work significantly
better, faster, or more reliably, I can guarantee that it will go into the
XEmacs core. Even if you are not familiar with the C core, let me know
generally what you are looking for and I can design it.
ben
Jan Vroonhof wrote:
Eric Marsden <emarsden(a)mail.dotcom.fr> writes:
[Yet another message marked for "Rereading when there is a non-zero
amount of free time]
> EIEIO is at <URL:http://www.ultranet.com/~zappo/eieio.shtml> (with
> stuff like this I occasionally manage to forget I'm programming in a
> crummy imitation of a Lisp :-).
Now that we have your attention. I have been wanting to look into this
for some time, but still haven't come around to it. Are there any
bottlenecks or imperfections with EIEIO that could be solved with a
little help from the C core?
For instance I am thinking of
opaque-cons (car cdr)
Internal function. Like cons, but the return value is an opaque type
and will signal an error unless passed to opaque-*
opaque-car (ocons)
opaque-cdr (ocons)
opaque-to-cons (ocons)
opaque-cons-p (ocons)
Then you would have in usertype.el
(defun deftype (type operations)
(put type 'type-operations operations)
(define-function
(make-symbol (cons "make-" (symbol-name type))) '(value)
`(opaque-cons ,type value))
(define-function
(make-symbol (cons (symbol-name type))) "-value" '(t)
`((let ((c (opaque-to-cons t)))
(if (eq (car c) ,type)
(cdr c)
(error 'type-error "....")))))
(define-function
(make-symbol (cons (symbol-name type))) "-p" '(t)
`(and (opaque-cons-p t) (eq (opaque-car t) ,type))))
etc
Jan
2:11 p.m.
New subject: Re[1]: database functionality (was Re: [21.2] LDAP add and delete functions + interrupt fixes)
Hello everyone on this thread:
>> Ben Wing <ben(a)666.com> seems to think that:
I had absolutely no idea about the existence of EIEIO.
Why isn't this an XEmacs package? Or even better, why isn't it
distributed as a *standard* part of the distribution?
Eric (Ludlam): Please read what Jan has to say below. If there is any
change to the C code of XEmacs that would make EIEIO work significantly
better, faster, or more reliably, I can guarantee that it will go into the
XEmacs core. Even if you are not familiar with the C core, let me know
generally what you are looking for and I can design it.
[ ... ]
These are the following "problems" that I have had trouble with in
that are directly related to Emacs. Most probably require no action
other than information.
* EIEIO objects are vectors, and display as vectors. I hacked edebug
to print them in an object like notation
* Whenever byte compilers get tweaked, I have to figure out the new
nuances and fix `eieio-comp.el'. In particular I had trouble
dumping byte-code streams.
* Doc strings for classes and methods are rebuilt from their component
parts. It would be nice if the eieio function `describe-class'
could be used from `describe-variable' automatically.
* CLOS uses fset to set fields while I wrote special oset,oref
functions. I think I still correctly interface with cl.el for that
though. A side affect is that you can't fset in `with-slots', and a
few other strange things.
Jan Vroonhof wrote:
> Eric Marsden <emarsden(a)mail.dotcom.fr> writes:
>
> [Yet another message marked for "Rereading when there is a non-zero
> amount of free time]
>
> > EIEIO is at <URL:http://www.ultranet.com/~zappo/eieio.shtml> (with
> > stuff like this I occasionally manage to forget I'm programming in a
> > crummy imitation of a Lisp :-).
>
> Now that we have your attention. I have been wanting to look into this
> for some time, but still haven't come around to it. Are there any
> bottlenecks or imperfections with EIEIO that could be solved with a
> little help from the C core?
>
> For instance I am thinking of
>
> opaque-cons (car cdr)
>
> Internal function. Like cons, but the return value is an opaque type
> and will signal an error unless passed to opaque-*
>
> opaque-car (ocons)
> opaque-cdr (ocons)
> opaque-to-cons (ocons)
> opaque-cons-p (ocons)
>
> Then you would have in usertype.el
>
> (defun deftype (type operations)
> (put type 'type-operations operations)
> (define-function
> (make-symbol (cons "make-" (symbol-name type))) '(value)
> `(opaque-cons ,type value))
> (define-function
> (make-symbol (cons (symbol-name type))) "-value" '(t)
> `((let ((c (opaque-to-cons t)))
> (if (eq (car c) ,type)
> (cdr c)
> (error 'type-error "....")))))
> (define-function
> (make-symbol (cons (symbol-name type))) "-p" '(t)
> `(and (opaque-cons-p t) (eq (opaque-car t) ,type))))
[ ... ]
In my case, I use vectors instead of lists for everything for purposes
of speed. The first versions of EIEIO made things practically
unusable when it used all lists, so I spent a bunch of time doing
this. Unfortunately my lack of lispy knowledge at the time had me
choose a rather convoluted technique. (I still debate between object
obarrays and my existing single occurance obarray with array
indices.)
While storing a vector in an opaque cons cell is certainly a
possibility, it just adds one more layer to dereference, and would
make it tough to track versions of Emacs with the above change against
those without. I would also hazard a guess that individuals trying to
hack new types will also want to use vectors instead of lists.
(though I may be missing something...)
If instead I could do this in my code:
(if (fboundp 'make-normal-vector-special)
(make-normal-vector-special V PREDICATE PRINTER WHATEVER))
Then in a ref/set function I could do this:
(let ((some-variable-with-special-meaning 'eieio-object))
(do normal stuff))
or have this in eieio:
(if (fboundp 'reference-special-vector)
(defalias eieio-....)
...)
then maintenance would be much easier. I know deep down this will
probably be considered an evil hack, but my main concern is
compatibility with as many Emacses as possible. I still get bug
reports from very old versions of Emacs and XEmacs (and sometimes from
versions of [X]Emacs I never thought were released).
Anyway, to add to your typing function above, a -print type function
would also be useful. It can take emacs a long time to print a 20
element vector with deep lists in it when only 80 characters will be
displayed. A nice short #<object foo> is usually plenty.
Anyway, those are my thoughts of the day. You happened to write
during a week when I was trying to make multiple-inheritance work
so I didn't have to make a big context-switch. Thanks. :)
Enjoy
Eric (Ludlam)
9138
days inactive
9139
days old
2 comments
3 participants
participants (3)
-
Ben Wing -
Eric M. Ludlam -
Jan Vroonhof