headers
raffaelcavallaro | 1 Aug 2002 05:53
Picon

Re: Lisp and Ruby


On Wednesday, July 31, 2002, at 04:44  PM, Louis Theran wrote:

> Dylan seems to have just as many of the mapping and folding functions 
> as Lisp does.  It also has this notion of an iteration protocol for 
> collections.

I've always thought (though others should chime in to correct me) that 
the mapping functions in lisp are for working with lists as one's only 
or primary data representation - a common practice of lispers, 
especially in the early stages of exploratory programming.

The iteration protocols of Dylan are more general, since <collection> 
has many subclasses, many of which will end up being used in the final 
version (whereas list representations may be gone at that point) As long 
as you specify an iteration protocol for your subclass of <collection>, 
you can use all the built in collection functions. By contrast, you 
can't use mapcar with  arrays. This is what I should have expressed more 
clearly when I wrote "look at the DRM."

Raffael Cavallaro, Ph.D.
raffaelcavallaro@...
Permalink | Reply | 6 comments |
headers
Glen Foy | 1 Aug 2002 15:15
Favicon

Re: Lisp and Ruby

on 7/31/02 11:53 PM, raffaelcavallaro@... at raffaelcavallaro <at> mac.com
wrote:

> I've always thought (though others should chime in to correct me) that
> the mapping functions in lisp are for working with lists as one's only
> or primary data representation - a common practice of lispers,
> especially in the early stages of exploratory programming.
> 
> The iteration protocols of Dylan are more general, since <collection>
> has many subclasses, many of which will end up being used in the final
> version (whereas list representations may be gone at that point) As long
> as you specify an iteration protocol for your subclass of <collection>,
> you can use all the built in collection functions. By contrast, you
> can't use mapcar with  arrays.

Right,

If we design a new Lisp, we need to remember that Lisp is really two
languages - an inefficient language for rapid prototyping and a language for
writing fast, efficient code.

This is a great strength.  You don't want to waste your time crafting highly
efficient code in the early stages of a project; the design may change.  In
fact, the design will almost surely change.  Paul Grahman has really nailed
this in his writings.  He feels that top-down design is a bogus paradigm; it
just doesn't work.  Consequently, all projects are to some extent
"exploratory."  Rapid prototyping is the right approach.

Perhaps our new Lisp should *emphasis* this dual nature.  Rather than making
the iteration protocol general enough to include efficient and inefficient
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Danish | 1 Aug 2002 17:27
Picon

Re: Lisp and Ruby

On Wed, Jul 31, 2002 at 11:53:03PM -0400, raffaelcavallaro@... wrote:
> 
> On Wednesday, July 31, 2002, at 04:44  PM, Louis Theran wrote:
> 
> > Dylan seems to have just as many of the mapping and folding functions 
> > as Lisp does.  It also has this notion of an iteration protocol for 
> > collections.
> 
> I've always thought (though others should chime in to correct me) that 
> the mapping functions in lisp are for working with lists as one's only 
> or primary data representation - a common practice of lispers, 
> especially in the early stages of exploratory programming.
> 
> The iteration protocols of Dylan are more general, since <collection> 
> has many subclasses, many of which will end up being used in the final 
> version (whereas list representations may be gone at that point) As long 
> as you specify an iteration protocol for your subclass of <collection>, 
> you can use all the built in collection functions. By contrast, you 
> can't use mapcar with  arrays. This is what I should have expressed more 
> clearly when I wrote "look at the DRM."

While Common Lisp doesn't have an iteration protocol as general as
Dylan's, it does have the concept of sequences which include vectors,
strings, and lists.  The MAP function can operate on any of them.  See
the Hyperspec chapter on Sequences.

--

-- 
; Matthew Danish <mdanish@...>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Szolovits | 1 Aug 2002 20:57
Picon
Favicon

Re: Lisp and Ruby

At 09:15 AM 8/1/2002 -0400, Glen Foy wrote:
>I think I will modify my styling utility so that list operators, non-tail
>recursive functions, etc. etc. are all colored red.  Then just by glancing
>at the code you could tell the stage of development.  The idea would be to
>"get the red out."

Can't resist a quick response.  Lists are not, by their fundamental nature, 
inefficient!  They make insertion and deletion very efficient at the cost 
of getting to the k-th element expensive (compared with vectors).  I think 
the reason that operations on "collections" are complex and multi-faceted 
in many languages is that there is no single best way to implement these, 
so different applications call for different engineering tradeoffs among 
the characteristics of different methods.  As an example, look at all the 
hair in Java's approach.

Common Lisp tries to paper over the distinction between some of these 
methods of implementation in the "sequence" functions, which generalize 
over lists and vectors (to oversimplify a bit), but if you're trying to 
build very efficient code, you need to understand the design choices you make.

--Pete Szolovits

P.S.  I agree with the sentiment that almost all programming is 
exploratory, and should be supported.  This is my main reason for 
continuing to hack lisp.
Permalink | Reply | 3 comments |
headers
Glen Foy | 2 Aug 2002 01:04
Favicon

Re: Lisp and Ruby

on 8/1/02 2:57 PM, Peter Szolovits at psz@... wrote:

> Can't resist a quick response.  Lists are not, by their fundamental nature,
> inefficient!  They make insertion and deletion very efficient at the cost
> of getting to the k-th element expensive (compared with vectors).

Oh sure.  But in general optimized code tends to rely less on lists than
prototype code.  This is as it should be.

-Glen

P.S. Is anyone aware of a package that will analyze code in terms of style?
For example, given the function below, it would spit out the comment, "Don't
you really want to use MAPCAN instead of reinventing it?"

(defun collect-eggs (chickens)
    (if (null chickens)
       nil
       (nconc (lay-eggs (car chickens))
              (collect-eggs (cdr chickens)))))

It might also identify a host of other things ...
Permalink | Reply | 2 comments |
headers
Ian Bruce | 2 Aug 2002 02:25
Picon

Re: Lisp and Ruby

Namespace and the fact that Lisp syntax is so regular and Eval, make 
Lisp unique. The mathematical nature of the language as contrasted to 
the machine basis of most languages makes Lisp very special and powerful.

In the small the difference is not so noticeable, but in the large when 
systems get complex and you have to do very clever things, it just can't 
be beat not only for development effort but ALSO performance. It's easy 
to make C++ into a real dog while on the other hand its almost as easy 
to tweek up some Lisp system to get some real performance.
Permalink | Reply | 1 comment |
headers
Glen Foy | 2 Aug 2002 13:45
Favicon

Re: Lisp and Ruby

on 8/1/02 8:25 PM, Ian Bruce at ianbruce2@... wrote:

> Namespace and the fact that Lisp syntax is so regular and Eval, make
> Lisp unique. The mathematical nature of the language as contrasted to
> the machine basis of most languages makes Lisp very special and powerful.

A quote from McCarthy:

"We shall first define a class of symbolic expressions in terms of ordered
pairs and lists.  Then we shall define five elementary functions and
predicates, and build from them by composition, conditional expressions, and
recursive definitions an extensive class of functions of which we shall give
a number of examples.  We shall then show how these functions themselves can
be expressed as symbolic expressions, and we shall define a universal
function APPLY that allows us to compute from the expression for a given
function its value for given arguments."

Clearly this is a theoretician talking, not a language designer.  It would
be interesting to contrast an equivalent early description of FORTRAN.

-Glen
Permalink | Reply | 0 comments |
headers
Thomas Russ | 3 Aug 2002 01:33
Picon
Favicon

Re: hash table question


On Saturday, July 27, 2002, at 12:07  PM, Jud Leonard wrote:

> So I was blithely hacking away, when I realized that my (loop for x 
> being each hash-value of ht...) was adding items to the hash table, and 
> likely even growing the hash table during the loop.  And it occurred to 
> me that doing this might not be reliable, even though it seems to have 
> worked ok so far.

Working off the top of my head, I believe that the only safe operation 
(according to
the standard) on a hash table during a traversal (via maphash or loop) 
is to remove
the current item from the hash table.  Any other operations are not 
guaranteed to
produce any particular results.

What I've done in the past when I needed to do more general iterations 
over
hash tables is to first make a pass through the table and then use the 
resulting
list of key values to manipulate the information.  Of course, 
consdiering some of
the questions below, this might entail some additional bookkeeping.

>
> Can anybody tell me, if I do this, whether:
>   a) the loop is guaranteed to finish?
Probably.   I would imagine this would actually terminate.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Joswig | 3 Aug 2002 11:57
Picon

Re: Processors

>There has been some discussion in the newsgroups lately about the
>possibility (probablity?) of Apple switching processors.  Motorola is
>lagging.  Jobs recently stated that this may happen, once the transition to
>OSX is complete.

Don't forget the Power4 processor from IBM. A switch from
PowerPC to the "Power" processor family would not be *that*
costly...

--

--
Permalink | Reply | 0 comments |
headers
Harald Schmidt | 3 Aug 2002 19:02
Picon

Current Status of MCL for MacOSX

...could anyone be so kind telling me the current status of the MacOSX
version of MCL. Looks like it takes some more time until we get this
version.

Harald
Permalink | Reply | 0 comments |

Gmane