Re: expressiveness

[address@hidden (Kragen Sitaker)]

Matthias Felleisen writes:
> What is expressive power? 
> ...
>   - to add a construct to a language that you can only get 
>     by a global transformation of the program otherwise. 
> ...
>     People have illustrated with numerous examples that 
>     macros add just this abstraction power. No, not with proofs, 
>     but I conjecture that this is doable within the theory. 

Thank you for explaining this; I feebly and ambiguously grasped at
these ideas a few days ago when I wrote this:

> Do macros offer any other advantages, like better separation of
> concerns, reduction of duplication, etc.?  I have seen several
> assertions that they do reduce duplication in ways that lightweight
> lambda syntax can't, or that they do it more easily, but I haven't
> seen any convincing examples.
> 
> (Here I speak specifically of one kind of duplication: the need to
> explain one decision in two places, so that you must change both
> places if you change the decision, but the program does not
> automatically detect if you forget and change only one place.
> Programming consists largely of removing this kind of duplication.)

If you know what kind of global transformations you might want to make
in the future, you can write your program in a style contorted so that
those transformations will be local instead in almost any
Turing-complete language.  For example, if you might want
continuations later, you can write your program in explicit
continuation-passing style.  Then returning a continuation from
somewhere doesn't require a global transformation, as it would if you
had written the program in idiomatic C.

This strategy imposes a large constant factor in size and complexity
on the program, but I want to ignore those for the time being, because
we already said we don't care about making things shorter.

So what I really want is a language where, empirically, changing
things I didn't expect to change rarely requires global program
transformations.  I'd like to say "where changing my mind about
something never requires global program transformations", but I don't
think we can do that; no language can prevent a bad programmer from
spreading some assumption all over his program like a three-year-old
spreads chocolate on her face.

How do macros help here?  It seems that they could help in this way if
you changed your mind about whether some argument should be treated as
an expression to be evaluated once as soon as possible, as some data,
or as a block of code to be evaluated some varying number of times or
at some later time, but this change didn't necessitate an examination
of every call to the macro.  Can someone provide an example of such a
case?  I can't think of one, but I don't know Lisp or Scheme well
enough that I think that means none exist.

Sundar Narasimhan wrote:
> [quoting Kragen]
>    (Here I speak specifically of one kind of duplication: the need to
>    explain one decision in two places, so that you must change both
>    places if you change the decision, but the program does not
>    automatically detect if you forget and change only one place.
>    Programming consists largely of removing this kind of duplication.)
> 
> I'm confused.. are you talking about duplication or about dependency
> tracking support? Macros are no better than functions in that
> regard.. and what you are talking about is often left to "tool
> support" rather than treated as a base language capability. Personally
> speaking, I'm with you -- I've never liked the somewhat arbitrary
> separation we have in modern systems where because
> IDE's/debuggers/loaders/runtimes tend to be monolithic programs, they
> are not available to the programmer to re-use/extend/bug-fix.

I didn't mean to bring up dependency-tracking support; I meant
something different.

If I make some decision that ends up encoded in two places in my code,
I might want to change that decision later.  Then I have to change
both places.  Sometimes I'll forget one, and then the code breaks.  I
don't mind if it breaks in an immediately obvious way --- for example,
if I change the number of arguments to a function in C, I get
compile-time errors --- but if it breaks in a subtle way, I mind.

Some language features that make it possible to encode the decision in
only one place instead of two, or to link the two so that changing the
decision in only one place results in an immediately obvious error.  I
believe Matthias's post said the first part of this in a much clearer
way.

I was trying to ask this question: are macros such a language feature,
or do they just make your code shorter?  I don't mean that I don't
care about making code shorter, but I care even more about the kind of
language feature I tried to describe above.

>    If I had twelve hours to get something up and running and several
>    pages of repetitive code to write, in, say, Perl, I'd spend an hour or
>    two writing a (Unix-style, string-based) preprocessor.  I imagine a
>    Lisp wizard could do the same thing much more quickly, since Lisp has
>    READ and WRITE.
> You are talking about Lisp and Perl. In Lisp I don't have such
> problems.. I was talking about languages w/out real macros -- and when
> I sorely missed them, because had I had such facilities it would have
> meant a good night's sleep.. instead of hacking yet another
> pre-processor and debugging it :)

I meant that you still wouldn't have much of a problem in this case if
Lisp didn't have macros, because a preprocessor to help you generate
repetitive code doesn't take that much trouble in the first place, and
usually the hard part is the parsing, which Lisp has anyway.

I'll respond to the middle part of your post, which interested me the
most, in a bit --- it will take a little more thought.  :) Flavors,
eh?  Do you work on Cyc, or does someone else still use LispMs?

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Edsger Wybe Dijkstra died in August of 2002.  The world has lost a great
man.  See http://advogato.org/person/raph/diary.html?start=252 and
http://www.kode-fu.com/geek/2002_08_04_archive.shtml for details.