Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

first, second, ... counterparts for vector - help to give a good name

18 views
Skip to first unread message

budden

unread,
Apr 26, 2012, 4:37:42 AM4/26/12
to
Hi list!
Is it ok to name it
(defun svfirst (x) (svref x 0))?
(defun svsixth (x) (svref x 5))
etc.
Is there any popular library which contains similar functions
already?

Barry Margolin

unread,
Apr 26, 2012, 7:05:03 AM4/26/12
to
In article
<b7317194-54ed-4ebf...@c28g2000vbu.googlegroups.com>,
If you're using a vector, it's usually because the element to access
will be computed. So functions that access specific elements are not
needed very often.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

budden

unread,
Apr 26, 2012, 7:23:39 AM4/26/12
to
> If you're using a vector, it's usually because the element to access
> will be computed.  So functions that access specific elements are not
> needed very often.
Vector is a good model for "anonymous structure with unknown, but
fixed, number of
anonymous slots". Sometimes better than list. At least, if you have a
list
of vectors, you can hardly mix both levels up.

Pascal J. Bourguignon

unread,
Apr 26, 2012, 8:27:11 AM4/26/12
to
Yes. COMMON-LISP provides similar functions already.
For lists, they're named FIRST, SECOND, THIRD, etc.

If you insist on vectors, then you have in the COMMON-LISP library:

(defstruct (person (:type vector))
first-name
surname
birthdate
sex
height)

(person-first-name #("Clark" "Kent" "1920-02-29" :male 1.90))
--> "Clark"

(person-height #("Clark" "Kent" "1920-02-29" :male 1.90))
--> 1.9

or, for an anonymous vector:

(defstruct (anonymous (:type vector) (:conc-name sv))
first
second
third
fourth
fifth
sixth)

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Barry Margolin

unread,
Apr 26, 2012, 8:42:41 AM4/26/12
to
In article
<471021ea-1d9e-4df3...@d20g2000vbh.googlegroups.com>,
I'm having a hard time thinking of many such uses. The common patterns
are:

Structure with arbitrary number of items: Use a list if the primary use
will be sequential access rather than random access, or you need to do
lots of inserts/deletes; use an array for lots of random access.

Structure with fixed number of items: If they're fixed, they're usually
not anonymous, so a structure or CLOS object is usually appropriate.

Yes, there are exceptions. If you have an object representing cars, you
might have a slot containing wheels, and it would always have 4 elements
that could be treated equivalently. But I still can't imagine accessing
them using fixed accessors like vfirst, vsecond, etc.; what application
would need to operate specifically on the second wheel? If the position
in the vector has a special meaning, you should be using a structure
instead, so that you can name it properly (e.g. front-passenger-wheel).

budden

unread,
Apr 26, 2012, 1:55:23 PM4/26/12
to
I'm translating from other very popular language which
has a concept of "table" with fixed number of anonymous
columns indexed by numbers.

It is safe to represent such table as a list of vectors as:
i) (seventh '(1 2 3)) is not a error while (svref #(1 2 3) 6) is.
ii) it is harder to mix up levels of nesting by omission when
you have different types of objects.

When I'm looking for value, I use something like

(find item table :key 'svfirst)

which is just shorter, much more readable and maybe
faster than

(find item table :key (lambda (row) (svref row 0)))

Note also that table columns are counted from one
in original language, not from zero.

After all, I believe names like svfirst, svsecond, etc
are ok and I have written seven functions and setf
expanders for some of them.

Pascal J. Bourguignon

unread,
Apr 26, 2012, 2:06:11 PM4/26/12
to
budden <budde...@mail.ru> writes:

> After all, I believe names like svfirst, svsecond, etc
> are ok and I have written seven functions and setf
> expanders for some of them.

You're not lazy enough.
0 new messages