[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile Binary Format 0.1

From: Michael Livshin
Subject: Re: Guile Binary Format 0.1
Date: 07 Feb 2001 12:44:55 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Crater Lake)

Keisuke Nishida <address@hidden> writes:

> At 06 Feb 2001 12:38:29 +0200,
> Michael Livshin wrote:
> > 
> > > I thought SCM_SETCAR/CDR are doing something special, but looking
> > > at their definitions again, I realized they aren't.  Okay, I'll
> > > remove the redundant functions.
> > 
> > just to clarify (or maybe further obfuscate, we'll see): theoretically
> > SCM_SETCAR/CDR might do something special.  in a generational GC, for
> > instance.  however, I think we should always provide non-special
> > counterparts which will be used, for instance, in bulk initializations
> > and undumping.
> I don't understand what you mean by the last sentence.  Are you for or
> against using the address of SCM_CAR/CDR?

absolutely for, whenever it simplifies things.  it's just that in the
future it might become nesessary to surround any code that modifies
parts of objects in such low-level manner with some magical
incantations.  don't worry about it now, anyway, and feel free to
ignore my rambling.

> > I just thought that the fact that the smob type name *must* always
> > be unique is not currently apparent enough to users.
> In the future, I guess smobs and classes should be defined in
> association with specific modules.  That way, we can determine
> each smob and class by a name like "guile::core::type::keyword".

hmm.  Guile is, more or less, a Scheme implementation ;).  the
Schemey way is to have names only for _bindings_, not objects.

that is, class and smob type names are perceived as a documentation
nicety, no more.  a module discipline won't change that, unless Guile
stops being Schemey.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]