[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Documentation
From: |
Michael Livshin |
Subject: |
Re: Documentation |
Date: |
03 Mar 2001 23:39:48 +0200 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Crater Lake) |
Neil Jerram <address@hidden> writes:
> moi> (with-waving-hands [...]
>
> OK, thanks, I see now how it can be done.
note that my hand-waving was *extremely*, er, wavy. in practice, the
binding "handles" don't have to retain their identity across
re-exports, for example. so primitive support in the module system is
needed anyway. but it surely can be done.
> moi> upon seeng the #{ prefix, the reader gets all excited,
> moi> reads the text up to }# and does this:
>
> moi> (%store-string " foo: do stuff ")
>
> This looks very nice! I see now how we could read docstrings without
> continuously increasing Guile's memory usage. But I have two
> concerns.
>
> 1. How much would the reading of #{ ... }# forms and the %store-string
> operation affect the time taken to load a module? Is this time
> significant in comparison with reading in the code? (Perhaps not,
> if most of the current read time is attributable to slow module
> lookup closures for variable references.)
>
> (Note that the %store-string operations could be done
> asynchronously w.r.t. the module loading, as long as they completed
> quickly enough to avoid the possibility of a backlog building up
> and so doing all the allocation that we're trying to avoid.)
>
> 2. Shouldn't we generalize this to cover storage of any arbitrary
> object in a database, using Keisuke's binary read/write to marshal
> objects into a flat format?
I've chewed on the subject some more...
* generally, when thinking up such things, it would be wise (IMHO) to
pretend that Guile already has a compiler. this is because, despite
the mounting evidence to the contrary ;), I still believe that we
are going to have one. so introducing hairy stuff that helps the
current interpreter-only situation but is useless with a compiler
should be done with extreme caution or not done at all.
* so let's see again what problems with docstrings we want to solve:
0) Emacs is not cooperative enough.
a different string syntax should solve that.
1) docstrings take up memory.
I don't believe this to be a serious problem, actually. and it is
trivially solved by a compiler. if it turns out to be a real
problem, it *can* be solved with that read-macro/database trick.
so, while the trick can be employed, I don't think it nesessarily
should be employed. and anyway it shouldn't be *mandated*.
* now, to address your points:
1. no, I don't think the load time should be affected very much, at
least I don't see any reason to be afraid of that. especially if
the #{...}# things (or whatever syntax is decided on) are just
read in as strings.
2. what problems do you have in mind that such general read-time
database functionality would solve?
--
A computer, to print out a fact,
Will divide, multiply, and subtract.
But this output can be
No more than debris,
If the input was short of exact.
-- Gigo
Re: Documentation, Jorgen 'forcer' Schaefer, 2001/03/01