[cdr-discuss] [cdr-announce] CDR 12 accepted

[Ingvar Mattsson]

On Mon, Dec 10, 2012 at 10:49 AM, Marco Antoniotti <marcoxa at cs.nyu.edu>wrote:

>
> On Dec 9, 2012, at 21:31 , Nick Levine <ndl at ravenbrook.com> wrote:
>
> > 1. Typo "devbelopers" for "developers".
> >
> > 2. Maybe I'm just dim, but I really don't understand what this is
> > about. The functional interface looks like that of a queue (or a
> > stack, depending on whether insert and remove work on the same end as
> > each other or not). Can you explain? give a couple of examples?
>
>
> A "Heap" is also known as a "Priority Queue".  So the interface must be
> similar.
>
> I have nothing against this (*), although the spec leaves out a few corner
> cases.  E.g., what happens when the keys are equal, but the values/content
> associated are not?
>

That is unclear in the specification. The example implementations would do
different things depending on if you use something that is (essentially)
"less than" or "less than or equal" (in the former case, they'd not
re-order the equal values whenever there's an operation on the queue, in
the latter case, they would).

Apart from that, I do not understand the use of DECLARE-HEAP and I believe
> that there should be no provisions to define a package for these sort of
> data structures.  Or better: I believe a discussion about how to structure
> packages and libraries should be started.  But this is an old pet peeve of
> mine.
>

That is definitely something that is worth discussing. The main reason fro
submitting GENHEAP is that I didn't see anything similar and, well, I did
submit GENHASH back in the early days of CDRs. If people are, generally,
hesitant, I am more than happy to withdraw the submission.

The main reason for DECLARE-HEAP is to allow for the example implementation
that defines all underlying operations in terms of methods on a specialized
class to be easily created on "this is the type of heap I want" rather than
on the first creation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cdr-discuss/attachments/20121214/74a7e4c5/attachment.html>