[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

multiple return values

I would strongly oppose the Common Lisp multiple value semantics.  I
find it to be very distasteful.  If this means that the language has no
multiple values primitively, and I have to implement semantics #1 myself
using lists or closures or whatever, that's fine with me.

If I have many sympathizers then I'd say it appears that we're
as deadlocked as we were last time this came up...

There's a deeper issue here:  I have found that I use a number of
features which can be implemented easily enough in Scheme, but for which
particular scheme implementations have efficient, low-level, nonstandard
support.  For example: multiple values, fixnum arithmetic, byte vectors,
certain string operations (like what was in the R^2 report), hash
tables, PEEK-CHAR, and bitwise logical opertions.  What I do is I have
one particular file which implements all these features portably.  I can
then replace this file for particular implementations to get better
performance.  In general I'll have N+1 versions of this file, one
portable version plus one version for each implementation for which it's
been tuned.

Does anyone else do things like this?  Or am I the only person who really
tries to write nontrivial programs that are both portable and fast?

The fact that my programs are portable, and that this "tuning file" is
small in size, is of course due to our standardization effort.  It's not
clear that implementation-dependent tuning can go away completely, but
the smaller that file is, the happier I'll be.  This is the main
argument I see for adding logically redundant features (like multiple
values #1) to the standard; I assume that's why LENGTH and MEMQ are
in the report.  Maybe we need a better way to organize these redundant
features; they don't really belong in the main part of the report.