Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!rutgers!rochester!pt.cs.cmu.edu!LINDENTHAL.CAE.RI.CMU.EDU!jwb
From: jwb@LINDENTHAL.CAE.RI.CMU.EDU (John Baugh)
Newsgroups: comp.lang.misc
Subject: Re: Expressive Power - What is it ?
Message-ID: <5115@pt.cs.cmu.edu>
Date: 4 Jun 89 15:19:25 GMT
References: <11318@megaron.arizona.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 46

In article <11318@megaron.arizona.edu> gudeman@arizona.edu
(David Gudeman) writes:
> [stuff deleted]
>pretty much the same way.  However these next two show an
>expressiveness advantage in C:
>
>Lisp:  (setq a (1+ a))
>C:     a += 1;
>C:     ++a;
>
>In both languages you can express the concept of "add 1" as a seperate
>idea from "add two numbers".  But in C, you can also express the
>notion of "increment location by one" as an atomic notion itself.
>However, you can _define_ an "increment location" macro in Lisp.  On

No.  It's already there, at least in Common Lisp.  The macro "incf"
takes an optional argument "delta", which defaults to 1.  So (from
CLtL):
  (setq n 0) => 0    and now n => 0
  (incf n) => 1      and now n => 1
  (incf n 3) => 4    and now n => 4

The same macro can be used to destuctively increment a "place", e.g.,
  (setq l '(1 2 3)) => (1 2 3)   and now l => (1 2 3)
  (incf (cadr l) 3) => (1 5 3)   and now l => (1 5 3)

The decrement macro "decf" is also provided.

>the other hand Lisp is more expressive than C in areas such as
>defining functions at run time.  There is no way to simulate this in

What about treating functions as values?  Doesn't this add to the
expressive power of a language?  Modern functional languages provide
this plus many other "expressive" features: currying, so that the
application of "add" to 1 returns a unary function that adds 1 to
its argument, (e.g., add1 = add 1); pattern matching; defining types
via recursion equations, ...  If having an increment function makes
a language more expressive, doesn't the above have to fit in somewhere?

>  [stuff deleted]
>					David Gudeman
>Department of Computer Science
>The University of Arizona        gudeman@arizona.edu
>Tucson, AZ 85721                 {allegra,cmcl2,ihnp4,noao}!arizona!gudeman

John Baugh
--