Remove and delete on an array...

Hi,

Here is a problem with lisp generally, I don't thing LW specifically, 
that I can't quite believe isn't built into CL... I hope this isn't too 
off-topic for this group.

I've look through all the documentation I have available and I've not 
been able to find anything appropriate. Here is the problem:

I use many many arrays that are built like:

(make-array *default-capacity* :fill-pointer 0 :adjustable t)

I happily am able to put things into the array. The trouble is when 
taking them out of the array.

If I use remove to do this, the resulting array does not have a fill 
pointer. This causes an exception sometime down the road when I try to 
add another element.

If I use delete to delete 1 element say, then the last element remains 
in the array, is obtainable with aref, but with an index that is past 
the fill pointer. So there are two references to the last thing in the 
array (and a memory leak).

How is this done in CL? Should I use delete and stomp on the extra 
thing using aref? Should I create a new array and loop?

Thanks,
Bob


----
Bob Hutchison          -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc.  -- <http://www.recursive.ca/>


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Remove and delete on an array...

Unable to parse email body. Email id is 3698

Re: Remove and delete on an array...

Hello.

Can I draw nicely antialiased bezier curves using CAPI in a 
platform-agnostic way?
If not with CAPI, then with someting else maybe. If not beziers, than some 
other kind of curve.
If not in a platform agnostic way, then on osx or on windows.
But I would definitely like them antialiased.

I tried to look around, and my current understanding is that I'll have to go
with one of the gaming engines. If this is indeed the case, which one
of them in your experience plays nicely with CAPI on OS X and Windows?

Thank you for any suggestions, Denis. 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Remove and delete on an array...

* Bob Hutchison wrote:

> So I guess there is another way of asking my question: are there any 
> delete/remove/whatever-it-may-be-called functions/macros that have a 
> post condition that it leaves no inactive element not null?

I think this sort of thing (while I agree it would be useful) is
slightly hard to arrange in a language with Lisp's type system. In
particular, what is null?  Perhaps it is NIL, but NIL is not an
instance of all types.  So somehow you have to specify what particular
null you want, possibly at array creation time.

Java of course has been designed so that null *is* an instance of any
type, or, well, any of the boxed types, and so doesn't have this
problem, although it can have other issues as a result.

I expect people interested in programming language type systems rant
at each other endlessly about this sort of thing.  Personally I think
Lisp's approach is more coherent, although sometimes it makes you
think harder.

--tim

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Remove and delete on an array...

On Mon, 11 Apr 2005 09:35:42 -0400, Bob Hutchison <hutch@recursive.ca> wrote:

> But isn't nil a sub-type of all types, or am I misinterpreting the
> hyper spec?

Yes, but the /type/ NIL is the empty set.  See the CLHS entry for the
type NIL where you'll find the following note:

  "The type containing the object NIL is the type NULL, not the type
   NIL."

Cheers,
Edi.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Remove and delete on an array...

* Bob Hutchison wrote:

> But isn't nil a sub-type of all types, or am I misinterpreting the 
> hyper spec? Why can't nil be put into the array after a delete? That is 
> what I do in the functions I now use instead of delete/remove (BTW, 
> what I meant by 'null' is something that allows the 'null' function to 
> return true).

yes, you are.  The *type* NIL is a subtype of all types, but there are
no objects which are of that type.  NIL is of type NULL, which is not
a sub-type of all types (in fact it's a subtype of LIST and SYMBOL or
something).

I guess it would be possible to make a special object (possibly even
NIL) which was the only instance of a type which was a sub-type of all
types, but the consequences would be bad I think.  Type checks would
be worse since you'd always have to check for this type, and it would
become hard to implement arrays of immediate types. For instance
consider an array of (UNSIGNED-BYTE 8)s: if you use a compact
representation (byte-aligned in other words) then, other than the
header, all bit patterns in the array are legal values.  So you can't
use such a representation if you want to  be able to have a special
null value.

Java cops out on this by distinguishing in the language between
immediate types and non-immediate ones, and having null be an instance
of only non-immediate types.  Until very recently this has meant user
code has had to explicitly box and unbox things all over the place,
which is a horror.  They've got away from that now (at least mostly)
but the type system is still really ugly.

Of course, in CL you can still arrange to have arrays which can
contain NIL by making their element type (OR FOO NULL).  And you could
argue that in 99% of cases where you want to do this the upgraded
array element type will be T anyway, so there is no cost.  But there
is a cost, since now any implementation which wants to do serious type
inference has to emit checks for NIL all over the place. 

> And in my case, leaves me in a situation where I can't use the built in 
> functions.

Yes, it does.  The same way it does in Java (say) of course - you
can't use arrays of things to do what you want, you have to use some
bit of library code. such as ArrayList or something (which has a
syntax which is radically different than real arrays).  Java's
advantage is really that they've standardised the library.  The
disadvantage is that nothing you can do is going to make ArrayLists
look like arrays - foo.get(n) is not really like foo[n], and
assignment is worse - foo.set(n, o) vs foo[n] = o.  Yuck!  In CL at
least you can dress up your ARRAY-LIST objects with a proper accessor
so (say) (ref x i) works and (setf (ref x i) n) does what you think,
even when x is a real array not an ARRAY-LIST.

Anyway, this isn't anything to do with LW really, it should be on cll
or something (which I don't read any more, so, well...)

--tim

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________