copy or not? (style question)

On Aug 26, 3:36*am, Marcus Breiing <use...@2008w34.mail.breiing.com>
wrote:
> * Scott Burson
>
> > Gack! *Thank you
>
> While we're at it... I noticed that
>
> * (fset:compare (make-symbol "FOO") (make-symbol "FOO"))
> * --> :EQUAL

Well... What should (FSET:COMPARE (+ 2.0 40) (* 2.0 21)) return?
I'd
bet it returns :EQUAL as well (I have not tried it and I am just
reading Scott's mind here )


Cheers
--
Marco

On Aug 26, 12:36 am, Marcus Breiing <use...@2008w34.mail.breiing.com>
wrote:
> * Scott Burson
>
> > Gack! Thank you
>
> While we're at it... I noticed that
>
> (fset:compare (make-symbol "FOO") (make-symbol "FOO"))
> --> :EQUAL

Yes, I already have a fix for that one that I haven't released yet.

I'll try to release some of these bug fixes this weekend.

-- Scott

On Aug 26, 8:24 am, Marco Antoniotti <marc...@gmail.com> wrote:
> On Aug 26, 3:36 am, Marcus Breiing <use...@2008w34.mail.breiing.com>
> wrote:
>
> > * Scott Burson
>
> > > Gack! Thank you
>
> > While we're at it... I noticed that
>
> > (fset:compare (make-symbol "FOO") (make-symbol "FOO"))
> > --> :EQUAL
>
> Well... What should (FSET:COMPARE (+ 2.0 40) (* 2.0 21)) return?
> I'd
> bet it returns :EQUAL as well (I have not tried it and I am just
> reading Scott's mind here )

Yes, but (compare (+ 2.0 40) (* 2 21)) returns :UNEQUAL, as the
numbers are of equal value but different types. This is also what
Marco's example should return.

-- Scott

Kenny wrote:
>
>>> Scott Burson <FSet....@gmail.com> writes:
>>>
>>>> To be honest, I don't think anyone is using FSet but me.
>
>
> I have added it to my toolbox. No current requirement, but I am sure
> there will be. I think it is a solid hack and all round Good Thing to
> have at one's disposal.

Ah, hello requirement! for maps, specifically.

But I need ISAM (start with an indexed read (equal, >, or >=), then
continue sequentially from there) and all I can find are do-map and
iterator that traverse the whole collection. And no lookup with the comp
(gt, ge, lt, le, eq) specifiable.

Did I miss these? I can see how I would create them given the existing
code but will not bother until I am sure they do not already exist.

I agree, btw, that more doc will not help spread the word, but my
attempts to surf the code -- boy, there is a lot of it! One thing that
might have helped was having all code specific to a collection type in
its own source.

kt

On Aug 27, 1:00 pm, Kenny <kentil...@gmail.com> wrote:
> Ah, hello requirement! for maps, specifically.
>
> But I need ISAM (start with an indexed read (equal, >, or >=), then
> continue sequentially from there) and all I can find are do-map and
> iterator that traverse the whole collection. And no lookup with the comp
> (gt, ge, lt, le, eq) specifiable.

You're right -- things like this are needed. Here's how I think about
them. In unreleased code I have a class called `interval-set', which
implements sets of intervals; each interval can be open or closed at
either end. One of these could be intersected with an ordinary set to
yield the set of those members of the ordinary set that are within one
of the intervals. Similarly the `restrict' operation (q.v.) on a map
and an interval set would give you the portion of the map with keys
within one of the intervals. (Am I correctly understanding that this
is what you want?)

I don't think the interval-set code is really ready to release, but I
could make it more of a priority and have something out in a month or
two, I guess. If you need anything like this before then, there are
certainly simpler ways to do it -- maybe you can undertake one of
them.

> I agree, btw, that more doc will not help spread the word, but my
> attempts to surf the code -- boy, there is a lot of it! One thing that
> might have helped was having all code specific to a collection type in
> its own source.

Okay, maybe I'll break it up a little. (In general, I like large
source files.)

-- Scott

Scott Burson wrote:
> On Aug 27, 1:00 pm, Kenny <kentil...@gmail.com> wrote:
>
>>Ah, hello requirement! for maps, specifically.
>>
>>But I need ISAM (start with an indexed read (equal, >, or >=), then
>>continue sequentially from there) and all I can find are do-map and
>>iterator that traverse the whole collection. And no lookup with the comp
>>(gt, ge, lt, le, eq) specifiable.
>
>
> You're right -- things like this are needed. Here's how I think about
> them. In unreleased code I have a class called `interval-set', which
> implements sets of intervals; each interval can be open or closed at
> either end. One of these could be intersected with an ordinary set to
> yield the set of those members of the ordinary set that are within one
> of the intervals. Similarly the `restrict' operation (q.v.) on a map
> and an interval set would give you the portion of the map with keys
> within one of the intervals. (Am I correctly understanding that this
> is what you want?)

That sounds super-powerful and expressive. I like it. But all we need is
a lookup on a map that returns a new map that is a subset of the
original containing only keys optionally GE or GT the lookup value. ie,
we want to do ISAM (index-sequential access) on a map: start with a
lookup GE or GT that returns a map, not a member, and then do-map the
result. Application code would decide when to stop, but a nice touch
would be to optionally specify a count or end value, or in the case of
strings to return a submap of those keys starting with that string --
what we used to call generic keys back in my DEC RMS days where the
keywords were FIND to set a cursor and GET to read one record and
advance the cursor.

I started on hacking this out of the existing code and it looked like a
couple hours work (just a matter of finding the node in the btree GE or
GT the lookup value and returning a map with the node or roght branch as
the root I am guessing) so I thought I would make sure it was not
already there.

>
> I don't think the interval-set code is really ready to release, but I
> could make it more of a priority and have something out in a month or
> two, I guess. If you need anything like this before then, there are
> certainly simpler ways to do it -- maybe you can undertake one of
> them.

I'll give it a shot if the existing mechanism used by the project for
such browsing comes up short.

>
>
>>I agree, btw, that more doc will not help spread the word, but my
>>attempts to surf the code -- boy, there is a lot of it! One thing that
>>might have helped was having all code specific to a collection type in
>>its own source.
>
>
> Okay, maybe I'll break it up a little. (In general, I like large
> source files.)

Oh, then don't mind me. Until you have a few contributors your
productivity is all that matters. My2.

thx, ken