From: Ray Dillinger
Subject: Lispy design question
Date: 
Message-ID: <3FAC426F.F68F5573@sonic.net>
Warning: This article is posted to both c.l.s and c.l.l.  If you 
feel that you need to say anything that could start a fight, please 
trim followups from your thread.  Thank you. 

It seems that as Common Lisp and Scheme both gain maturity, and 
other LISPs fade into the mists of memory, there is an impulse in 
the air to build new LISPs, experiment with new design decisions, 
and try new things.  Paul Graham is working on something called 
ARC, Gnu is working in fits and starts on transforming elisp into 
a lexically scoped Lisp, newbies are coming to Lispy languages in 
numbers not seen since the crazy days of the early-80's AI bubble, 
and changes are in the air.  

Some years ago, I started on a scheme implementation, not realizing
that such a time of change and renewal in the Lisp community would 
be the case when it started nearing its completion. At this point 
I've implemented most of what I really like about Scheme, and I'm 
debating with myself whether to finish the things that will make 
it fully conform to the scheme standard (mainly dynamic-wind and 
multiple return values, which I'm not convinced are good ideas as 
currently spec'd in scheme), and beginning to experiment with some 
things that would definitely take away any pretense at being Scheme 
and make it, finally, some completely different Lisp. 

One of the things I'm experimenting with is "special functions." 
Special functions are executable code, but inherit all scope 
dynamically rather than lexically, and their arguments are 
evaluated lazily rather than eagerly.   They are not macros, 
but it is possible to use special functions to do things that 
macros are traditionally required to do.  The crucial difference
is that special functions are first-class objects just like any
function, and they can be stored in data structures, returned 
from functions, passed as arguments, mutated at runtime, etc, 
just like any other value.  

Now, I'm aware of the dangers of dynamic inadvertent capture 
that motivated both Common Lisp and Scheme to go to a default 
of Lexical scoping.  There are various refinements and modifications
this feature could go through to make variable capture more 
explicit and/or harder to do unintentionally. 

My intuition is that where lexical scoping isn't the "right 
thing", special functions are in some ways "cleaner" than 
special variables, and it allows some kinds of things that would 
normally be macrology to be handled in ways that are more 
amenable to higher-order functions and functional programming. 
I think that there is some important correlation or invariant
that's preserved by switching from eager to lazy at the same 
instant as switching from lexical to dynamic scope, but I can't
really find appropriate words to express what it is. 

I know they're not useful for some of the things that a 
general macrology is good for, and I don't really know if 
they're as generally useful as special variables, because I 
don't really have all that much experience with problems that 
special variables are the right thing for.  

So, what I'd really like, if it exists, is for someone to 
point me at any serious analysis that's been done on systems 
that mix dynamic and lexical scope - especially opinions from 
engineers who've used such systems for a longish time.  


				Bear
From: cr88192
Subject: Re: Lispy design question
Date: 
Message-ID: <vqoq1cnl5noaff@corp.supernews.com>
well, I have talked to you before, but new stuff might show up in this one
(given that it is a different context...).

"Ray Dillinger" <····@sonic.net> wrote in message
······················@sonic.net...
>
> Warning: This article is posted to both c.l.s and c.l.l.  If you
> feel that you need to say anything that could start a fight, please
> trim followups from your thread.  Thank you.
>
don't know.

> It seems that as Common Lisp and Scheme both gain maturity, and
> other LISPs fade into the mists of memory, there is an impulse in
> the air to build new LISPs, experiment with new design decisions,
> and try new things.  Paul Graham is working on something called
> ARC, Gnu is working in fits and starts on transforming elisp into
> a lexically scoped Lisp, newbies are coming to Lispy languages in
> numbers not seen since the crazy days of the early-80's AI bubble,
> and changes are in the air.
>
maybe...
I liked trying to be creative, but I don't know if that has accomplished
much.
really what I had discovered was that a lot of the most "radical" things I
had tried had turned out to not work that great, but other things have
worked better.

eg:
damn near every time I try using a whitespace sensitive syntax (be it lines
or indentation), cases pop up where the syntax feels like it is getting in
the way, albeit the code comes out at least decently readable...
using patterns instead of slot names for objects made an ugly mess of the
semantics, I changed to using slot names and then realized that "magically"
my semantics cleared up...
...

my oppinion of s-expressions vs. other syntax's goes:
s-expressions seem pretty useful in most cases, and do not really give the
"syntax is getting in the way of coding" feel, however, they also give the
feeling that they would scare off newbies, and they are a lot less fun when
emacs is not available...

my "odd" attempts at net stuff have typically turned out ok; but of course,
it appears that the design is showing up elsewhere as well so I am probably
not that original...
if one says: hide the existance of the network as much as possible, well, it
is working well if it is not noticed...

but what really has this done besides cutting my use of explicitly
destructive operations (instead replacing them by implicitly
destructive/message passing approaches)?...

> Some years ago, I started on a scheme implementation, not realizing
> that such a time of change and renewal in the Lisp community would
> be the case when it started nearing its completion. At this point
> I've implemented most of what I really like about Scheme, and I'm
> debating with myself whether to finish the things that will make
> it fully conform to the scheme standard (mainly dynamic-wind and
> multiple return values, which I'm not convinced are good ideas as
> currently spec'd in scheme), and beginning to experiment with some
> things that would definitely take away any pretense at being Scheme
> and make it, finally, some completely different Lisp.
>
I am similar, I started somewhere between 1 year 6 months and 2 years ago...

I agree, I have never really liked dynamic wind...
for multiple return values I had typically just returned lists, which as far
as I know is ok by the spec...

I have ways of decomposing lists, so this is not a big deal (I am still
keeping the "if you bind a list to a pattern then the list is decomposed
binding to vars in the pattern" rule...).

> One of the things I'm experimenting with is "special functions."
> Special functions are executable code, but inherit all scope
> dynamically rather than lexically, and their arguments are
> evaluated lazily rather than eagerly.   They are not macros,
> but it is possible to use special functions to do things that
> macros are traditionally required to do.  The crucial difference
> is that special functions are first-class objects just like any
> function, and they can be stored in data structures, returned
> from functions, passed as arguments, mutated at runtime, etc,
> just like any other value.
>
I am more leary of this, it has fairly strong evaluation model
implications...

determining whether or not one of said functions will show up would be
important, because in one case you want args evaluated and in another you
don't. one could delay evaluation, either to application time or more (eg:
arguments contain "unevaluated" expressions that are evaluated when you try
to use them, eg: like lazy languages or such).
one concern is that delaying evaluation to application time (this will have
the most minor impact) could somewhat impact performance (this depends on
the implementation though).

of course, lazy evaluation is outside my realm.

> Now, I'm aware of the dangers of dynamic inadvertent capture
> that motivated both Common Lisp and Scheme to go to a default
> of Lexical scoping.  There are various refinements and modifications
> this feature could go through to make variable capture more
> explicit and/or harder to do unintentionally.
>
maybe.

I default to lexical scoping with dynamic variables as a side option (they
*are* really useful in some cases).

> My intuition is that where lexical scoping isn't the "right
> thing", special functions are in some ways "cleaner" than
> special variables, and it allows some kinds of things that would
> normally be macrology to be handled in ways that are more
> amenable to higher-order functions and functional programming.
> I think that there is some important correlation or invariant
> that's preserved by switching from eager to lazy at the same
> instant as switching from lexical to dynamic scope, but I can't
> really find appropriate words to express what it is.
>
ok.

> I know they're not useful for some of the things that a
> general macrology is good for, and I don't really know if
> they're as generally useful as special variables, because I
> don't really have all that much experience with problems that
> special variables are the right thing for.
>
my object system, message passing, and controlling io were some examples.

what is "self", in my case it was a dynamic variable referring to the
current object. other ways could have been used, but this makes the most
sense...

> So, what I'd really like, if it exists, is for someone to
> point me at any serious analysis that's been done on systems
> that mix dynamic and lexical scope - especially opinions from
> engineers who've used such systems for a longish time.
>
I don't know. I can say from my experience that lexical scope works pretty
well, but there are cases where dynamic scope is quite useful...

I would have really liked to say something more interesting, but I lack
stronger comments.

all for now, in this great lameness of a response...