Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!netcom20!vanmeule
From: vanmeule@netcom20.netcom.com (Andre van Meulebrouck)
Subject: implicit BEGIN in LAMBDA (was Re: R4RS...round) LONG!
In-Reply-To: smcl@sytex.com's message of Wed, 12 Oct 1994 02:57:40 GMT
Message-ID: <VANMEULE.94Oct13231046@netcom20.netcom.com>
Sender: vanmeule@netcom.com (Andre van Meulebrouck)
Organization: NETCOM On-line services
References: <VANMEULE.94Oct8164647@netcom12.netcom.com> <TeB3Tc1w165w@sytex.com>
Date: Fri, 14 Oct 1994 06:10:45 GMT
Lines: 123

smcl@sytex.com (Scott McLoughlin) writes:

>vanmeule@netcom12.netcom.com (Andre van Meulebrouck) writes:
>
>> smcl@sytex.com (Scott McLoughlin) writes:
>> >
>> >nweaver@madrone.CS.Berkeley.EDU (Nicholas C. Weaver) writes:
>> >
>> >> <smcl@sytex.com> wrote:
>> >> }it compiles a "Stupid Lisp", not necessarily a that it is a 
>> >> }"Stupid Compiler". It's sort of a "Lisp Meets the Dragon Book" project -
>> >> }much fun.
>> >> 
>> Would your lambda sequence, or not (I'm just curious if it's easier to
>> provide automatic sequencing in lambdas or not).
>> 
>> I.e., would the body of your lambda sequence as if there was an
>> implicit begin in them?
>
>Howdy,
>        Yea, lambda's sequence. Never really thought about it. Guess
>I could macroexpand begin's to ((lambda ()...)) and thus "simplify"
>the thing even more.  Might confuse non Lisp/Schemer's though.

Not what I had in mind--that would slow execution and introduce
lambdas rather than removing them (probably wouldn't be welcomed by
those doing lambda lifting either).

But worse yet, the bottom line for me is that I don't think lambda
should do implicit sequencing.  I'd like to see Scheme be as close to
lambda calculus as possible--why deviate in this case?

As a reader of Scheme code I think doing implicit sequencing makes
lambda forms harder to read.

Like others I have seen, I actually put in an explicit begin into a
lambda if I want to sequence, just to draw attention to the fact that
I'm sequencing (since normally I avoid it).

However I take advantage of implicit sequencing when debugging (though
I could live without it if this feature was removed from LAMBDA).

Specifically, I like to put (break) and (print ....) statements into
lambda forms without having to stick a (begin ...) inside the body of
the lambda first.  Especially if you have a really complicated
expression--you probably have enough to deal with, without making
substantial tweaks to it (i.e. putting a begin in) that could cause
yet more confusions if you inadvertently closed a newly inserted BEGIN
incorrectly!

I just feel free to put gratuitous BEGINs in, hoping the compiler will
take them out for me when optimizing: perhaps that should be a
widely accepted convention for compilers to do this.

That way everyone can be happy!

I am ambivalent to the fact that MIT's scheme in scheme (in "Structure
and Interpretation...") gets implicit sequencing as a coincidental by
product of the way they implemented their metacircular interpreter
(i.e. it would probably be more effort to *not* allow implicit
sequencing).  

**********************************************************************

Subject change:  miniLISP.

My reason for asking my original question was that I wanted to know if
your implementation of your miniLISP (a project I applaud) is such
that it is easier to allow or disallow implicit sequencing.

If any peculiarities of your implementation would make it relatively
universally easier to allow or disallow implicit sequencing, I would
be inclined to say go with what your implementation would like!

I think it's wonderful that you want to come up with a tiny
LISP--almost a sort of minimalist calculus for LISP.  

This would have 2 payoffs:  alleviating people from using C (i.e. you
could implement a tiny core in Assembly, then bootstrap all else with
LISP), and, it would make LISP small and scalable (a problem that
slows LISP acceptance).

Let's face it:  a business man doesn't need/want complex numbers most
likely while a scientific programmer doesn't want B trees and other
data processing file structures.  

It would be nice if the core of LISP was whatever your minimalist
calculus for LISP dictates the smallest set needs to be, then have the
rest of functionality provided a la C style libraries so people could
pick and choose what they want (hence keeping core images as small as
possible).

The testbed for me would be:  can you get a LISP so small it will blow
the doors of those cheesy BASICs that the old Apple //e used to be
programmed in for both speed and practicality?  If not, time to apply
more technology to the problem and go on a weight reduction campaign
(i.e. go back to the minimalist calculus drawing board).

If you succeed in this aim, you could meet the sword-in-the-stone
challenge to make LISP the lingua franca of all computerdom to spare
us of those horrible conventional languages!

There is no reason why LISP/Scheme shouldn't be the language of choice
for business programming (a large cash cow indeed)--it's just a matter
of the business world discovering ancient wheels invented long ago.

By producing a good miniLISP, with libraries of interest to the
business world, LISP could be pull off a coup d'etat and replace BASIC
in the business world!  

Then instead of getting acronymed to death when reading the "jobs
offered" and instead of having a LISP jobs mailing list, it will ALL
be LISP!!!

"Imagine there is no BASIC...it's easy if you try...no C below
us...above us only S.K.Y. combinators!"  

(with apologies to John Lennon =:0)

-- 
+------------------------------------------------------------------------+
| Andre van Meulebrouck.  For personal data:  finger vanmeule@netcom.com |
+------------------------------------------------------------------------+
