Re: Documentation

[Michael Livshin]

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