rfc: (ice-9 accumulate)

rfc: (ice-9 accumulate)

[Thien-Thi Nguyen]

Would there be any interest in adding (ice-9 accumulate) to Guile?

- http://www.gnuvola.org/software/guile/doc/Efficient-Accumulation.html

I can see several arguments against doing so:

- It is a thin layer around (ice-9 q) functionality; possible to
  reimplement using (ice-9 q), in fact.  When the layer is thin, i
  wonder if the usefulness is more personal (a matter of taste) than
  general.  (See e.g., ttn-do macro `FE'.)

- The interface is procedural, possibly defeating compiler optimization.
  When i wrote it, it was an exercise for hobbit.  The hope was that
  hobbit could eventually learn to optimize usage of (ice-9 accumulate)
  calls to (strength-, complexity-)reduce them to (ice-9 q) calls, where
  other data-oriented optimizations can come into play.  Perhaps that
  hope was only a non-compiler-geek dream (sounds nice but unfeasible).
  Perhaps Andy can either revive this hope or kindly kill it off now?

- There is already something in Guile.  [If so, where?  Thanks.]

Of course, the primary argument *for* adding it would be to make porting
my stuff to Guile easier.  That's a selfish argument, so take it FWIW.

thi

Re: rfc: (ice-9 accumulate)

[Andy Wingo]

Greets,

On Sat 09 Jan 2010 11:44, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> Would there be any interest in adding (ice-9 accumulate) to Guile?
>
> -
> http://www.gnuvola.org/software/guile/doc/Efficient-Accumulation.html

Speaking only for myself, I would be unlikely to use it; but OTOH I am
not against having it.

> I can see several arguments against doing so:

You are not selling your idea very well here. But I'm still OK with it :)

> - The interface is procedural, possibly defeating compiler optimization.
>   When i wrote it, it was an exercise for hobbit.  The hope was that
>   hobbit could eventually learn to optimize usage of (ice-9 accumulate)
>   calls to (strength-, complexity-)reduce them to (ice-9 q) calls, where
>   other data-oriented optimizations can come into play.  Perhaps that
>   hope was only a non-compiler-geek dream (sounds nice but unfeasible).
>   Perhaps Andy can either revive this hope or kindly kill it off now?

So, here's the deal, as far as I understand inlining... (And your
question is about inlining, afaics, in the sense that the Waddell paper
treats inlining)

(1) Inlining across module boundaries: personally I have no intention of
hacking on this, beyond approaches like define-integrable (see the end
of http://www.scheme.com/tspl3/syntax.html).

The fundamental issue is that our modules are first-class rather than
syntactic. Define-integrable allows you to make a step towards the
syntactic, a very useful step.

(2) Inlining of procedures defined within one file/module: We will
probably do this, probably by treating private bindings from a module as
being letrec-bound within the module.

(3) Inlining of let or letrec-bound procedures: We will do this at some
point, and do it fairly well.

But, in this case, we still wouldn't be able to inline very well,
because it's an side-effecting interface. Once you have side effects, it
gets hard to reason about, especially in the presence of
continuations -- and you usually don't know when a continuation may be
captured.

So this particular construct is unlikely to be inlined nicely. However,
it's useful to you, and might be useful to someone else.

> - There is already something in Guile.  [If so, where?  Thanks.]

There's lots of stuff in ice-9 that noone knows about, but I don't think
there's something like this. Hopefully we can document more of it using
the new (texinfo reflection) infrastructure.

> Of course, the primary argument *for* adding it would be to make porting
> my stuff to Guile easier.  That's a selfish argument, so take it FWIW.

Well, we'd like your energy as well, so selfishness on all sides...

Cheers,

Andy
-- 
http://wingolog.org/

Re: rfc: (ice-9 accumulate)

[Ludovic Courtès]

Hello!

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> Would there be any interest in adding (ice-9 accumulate) to Guile?
>
> - http://www.gnuvola.org/software/guile/doc/Efficient-Accumulation.html

I’m currently unconvinced.

> I can see several arguments against doing so:
>
> - It is a thin layer around (ice-9 q) functionality;

FWIW I’m personally not fond of ‘(ice-9 q)’ because it’s undocumented it
provides an imperative interface.  I have a functional implementation of
purely functional FIFO queues (F. W. Burton, "An Efficient
Implementation of FIFO Queues"), which I’d rather push instead of an
imperative one.

Besides, the first idiom at [0] is about as concise as the one that uses
this API; in addition, it is likely to be more widely understood than
the latter.  This makes this API unappealing to me.

  [0] http://www.gnuvola.org/software/guile/doc/Efficient-Accumulation.html

[...]

> Of course, the primary argument *for* adding it would be to make porting
> my stuff to Guile easier.  That's a selfish argument, so take it FWIW.

Heh, although I’m unconvinced about this one module I hope we can find
ways to help port your software!

Thanks,
Ludo’.

Re: rfc: (ice-9 accumulate)

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Mon, 11 Jan 2010 01:48:19 +0100

   FWIW I’m personally not fond of ‘(ice-9 q)’ because it’s undocumented
   it provides an imperative interface.

I infer an "although" in that sentence.  Re (ice-9 foo) documentation, i
took some pains to fill in the gaps w/ Guile 1.4.x:

- http://www.gnuvola.org/software/guile/doc/Module-Index.html

Shall i submit those (the relevant ones) as doc patches?

   I have a functional implementation of purely functional FIFO queues
   (F. W. Burton, "An Efficient Implementation of FIFO Queues"), which
   I’d rather push instead of an imperative one.

Note that (ice-9 q) can add to the head of the queue, too.  A quick scan
of <http://www.cl.cam.ac.uk/teaching/2000/FoundsCS/queues.ML> doesn't
seem to show similar functionality.

   Besides, the first idiom at [0] is about as concise as the one that uses
   this API; in addition, it is likely to be more widely understood than
   the latter.  This makes this API unappealing to me.

I'm sorry, i don't follow.  What are you referring to as "the latter"?

   Heh, although I’m unconvinced about this one module I hope we can find
   ways to help port your software!

OK.  I'll look for other ways to be lazy...

Hmmm, would it be possible to install (ice-9 accumulate) as is, w/o
changes, somewhere under ${prefix}/share/guile (perhaps a site/ dir)?
Would Guile be able to locate and load it?

thi

Re: rfc: (ice-9 accumulate)

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Sat, 09 Jan 2010 22:55:58 +0100

   You are not selling your idea very well here.
   But I'm still OK with it :)

Well, spewing all manner of code is breathing in, dropping thin
interfaces is breathing out...

   So, here's the deal, as far as I understand inlining... (And your
   question is about inlining, afaics, in the sense that the Waddell
   paper treats inlining)

I'm not sure what my dreaming was about, exactly...

   [inlining opportunities / plans]

   So this particular construct is unlikely to be inlined nicely.

OK, i'll go mull on that for a bit.  Thanks for the overview.

   There's lots of stuff in ice-9 that noone knows about, but I don't
   think there's something like this. Hopefully we can document more of
   it using the new (texinfo reflection) infrastructure.

In reply to a similar comment from Ludovic, i offered to submit patches
for missing (ice-9 foo) documentation.  I hereby revise that offer to
submit patches using this infrastructure, once i get around to playing
with it.  I imagine it can't be much different from Guile 1.4.x's.

thi

Re: rfc: (ice-9 accumulate)

[Ludovic Courtès]

Hello,

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>    There's lots of stuff in ice-9 that noone knows about, but I don't
>    think there's something like this. Hopefully we can document more of
>    it using the new (texinfo reflection) infrastructure.
>
> In reply to a similar comment from Ludovic, i offered to submit patches
> for missing (ice-9 foo) documentation.  I hereby revise that offer to
> submit patches using this infrastructure, once i get around to playing
> with it.  I imagine it can't be much different from Guile 1.4.x's.

I’d prefer if it were used only for non-ice-9 modules.  I really
sympathize with what the GCS says (info "(standards) Doc Strings and
Manuals"):

  Some programming systems, such as Emacs, provide a documentation
  string for each function, command or variable.  You may be tempted to
  write a reference manual by compiling the documentation strings and
  writing a little additional text to go around them--but you must not
  do it.  That approach is a fundamental mistake.  The text of
  well-written documentation strings will be entirely wrong for a
  manual.

Thanks,
Ludo’.

Re: rfc: (ice-9 accumulate)

[Ludovic Courtès]

Hi,

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> Re (ice-9 foo) documentation, i took some pains to fill in the gaps w/
> Guile 1.4.x:
>
> - http://www.gnuvola.org/software/guile/doc/Module-Index.html
>
> Shall i submit those (the relevant ones) as doc patches?

Would be nice, though I think it should be decided on a per-module
basis.  There are some modules that it may be worth deprecating and
leaving undocumented, perhaps.

>    I have a functional implementation of purely functional FIFO queues
>    (F. W. Burton, "An Efficient Implementation of FIFO Queues"), which
>    I’d rather push instead of an imperative one.
>
> Note that (ice-9 q) can add to the head of the queue, too.  A quick scan
> of <http://www.cl.cam.ac.uk/teaching/2000/FoundsCS/queues.ML> doesn't
> seem to show similar functionality.

Yes, because it’s a FIFO.  ;-)

>    Besides, the first idiom at [0] is about as concise as the one that uses
>    this API; in addition, it is likely to be more widely understood than
>    the latter.  This makes this API unappealing to me.
>
> I'm sorry, i don't follow.  What are you referring to as "the latter"?

The ‘accumulate’ API doesn’t lead to more concise code, but it leads to
“non-standard” code, which makes it unappealing to me.

> Hmmm, would it be possible to install (ice-9 accumulate) as is, w/o
> changes, somewhere under ${prefix}/share/guile (perhaps a site/ dir)?
> Would Guile be able to locate and load it?

Setting $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH appropriately
should be enough.

Thanks,
Ludo’.

Re: rfc: (ice-9 accumulate)

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Mon, 11 Jan 2010 14:21:15 +0100

   I’d prefer if it were used only for non-ice-9 modules.

OK, i'll just take the .texi (output of Guile 1.4.x extraction),
clean it up for 1.9, and post them for review.

thi

Re: rfc: (ice-9 accumulate)

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Mon, 11 Jan 2010 14:26:46 +0100

   Would be nice, though I think it should be decided on a per-module
   basis.  There are some modules that it may be worth deprecating and
   leaving undocumented, perhaps.

Certainly each module will have it's own doc patch.

However, i strongly discourage leaving things undocumented.  For some,
undocumented might mean "don't use".  For others (who peruse source
code), it might mean "implementation so stable, it's self-documenting".

Better to be explicit: If you want to deprecate something, the
documentation is ALSO a good place to make that clear.

Another benefit to documenting stuff that you want to deprecate is that
the sifting process may reveal bits or techniques you want to keep.

   >    Besides, the first idiom at [0] is about as concise as the one
   >    that uses this API; in addition, it is likely to be more widely
   >    understood than the latter.  This makes this API unappealing to
   >    me.
   >
   > I'm sorry, i don't follow.  What are you referring to as "the latter"?

   The ‘accumulate’ API doesn’t lead to more concise code, but it leads to
   “non-standard” code, which makes it unappealing to me.

I can understand this point somewhat (what is unfamiliar often seems
non-standard).  However, i still fail to understand your sentence above;
do you mean "the latter" == "(ice-9 accumulate)"?

In any case, the API does indeed lead to more concise code, if the
original code that it replaces is `cons' plus `reverse!'.  But that's
neither here nor there...

   > Hmmm, would it be possible to install (ice-9 accumulate) as is, w/o
   > changes, somewhere under ${prefix}/share/guile (perhaps a site/ dir)?
   > Would Guile be able to locate and load it?

   Setting $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH appropriately
   should be enough.

OK, i'll give moving the module to ttn-do a try.

thi

Re: rfc: (ice-9 accumulate)

[Andy Wingo]

On Mon 11 Jan 2010 14:26, ludo@gnu.org (Ludovic Courtès) writes:

> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>
>> Hmmm, would it be possible to install (ice-9 accumulate) as is, w/o
>> changes, somewhere under ${prefix}/share/guile (perhaps a site/ dir)?
>> Would Guile be able to locate and load it?
>
> Setting $GUILE_LOAD_PATH and $GUILE_LOAD_COMPILED_PATH appropriately
> should be enough.

Setting $GUILE_LOAD_PATH is enough if you are fine with autocompilation
and caching in your ~/.cache directory, as is the default.

Andy
-- 
http://wingolog.org/

Re: rfc: (ice-9 accumulate)

[Andy Wingo]

On Mon 11 Jan 2010 14:21, ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>
>>    There's lots of stuff in ice-9 that noone knows about, but I don't
>>    think there's something like this. Hopefully we can document more of
>>    it using the new (texinfo reflection) infrastructure.
>>
>> In reply to a similar comment from Ludovic, i offered to submit patches
>> for missing (ice-9 foo) documentation.  I hereby revise that offer to
>> submit patches using this infrastructure, once i get around to playing
>> with it.  I imagine it can't be much different from Guile 1.4.x's.
>
> I’d prefer if it were used only for non-ice-9 modules.  I really
> sympathize with what the GCS says (info "(standards) Doc Strings and
> Manuals"):
>
>   Some programming systems, such as Emacs, provide a documentation
>   string for each function, command or variable.  You may be tempted to
>   write a reference manual by compiling the documentation strings and
>   writing a little additional text to go around them--but you must not
>   do it.  That approach is a fundamental mistake.  The text of
>   well-written documentation strings will be entirely wrong for a
>   manual.

I agree with this, largely; but of course texi documentation has the
disadvantage that it can (and does) grow out-of-sync with source.

For small modules, a nicely written commentary plus an expository (i.e.,
in-order) layout of exported procedures, along with their docstrings,
can get you 80% of the way there, very easily. And at least that way you
know it's accurate.

Also we could hack up other in-source documentary mechanisms that
approach manual-style documentation more closely. For example a Manual
block, like we now have Commentary.

Andy
-- 
http://wingolog.org/