From: Mike Thyer
Subject: Lazy scheme
Date: 
Message-ID: <364C7856.CE28E33D@cs.york.ac.uk>
I'm interested to know if anyone has produced a lazy version of Scheme
or Lisp,
or if there has been any work on non-statically typed checked lazy
languages
since SASL and KRC.  I would be especially facinated by any language
combining
laziness, no static type enforcement and impure features.

The argument that you cannot freely mix laziness with impure featured
often seems to
go unsupported and unchallenged, the current fashion being to enforce
side effects are performed
linearly by use of a static type system (eg with monads in Haskell or
uniqness typing in Clean).

I find the concept of an untyped, non-strict, impure language very
appealing.

Mike Thyer

From: Craig Dickson
Subject: Re: Lazy scheme
Date: 
Message-ID: <72i352$lj7$1@shell3.ba.best.com>
Mike Thyer <···@cs.york.ac.uk> wrote:

>The argument that you cannot freely mix laziness with impure featured
>often seems to go unsupported and unchallenged, the current fashion
>being to enforce side effects are performed linearly by use of a static
>type system (eg with monads in Haskell or uniqness typing in Clean).

Well, if your code has side effects, you need some way of knowing what
order the side effects will occur in. Eager evaluation is one way; lazy
languages, as you say, typically control side effects by typing or
strictness annotations. It seems to me that an untyped, non-strict, impure
language will need some solution to this problem, or its programs will tend
to behave chaotically as the side effects (which may affect each other!)
evaluate in a non-guaranteed order.

>I find the concept of an untyped, non-strict, impure language very
>appealing.

Why?

Craig
From: Mike Thyer
Subject: Re: Lazy scheme
Date: 
Message-ID: <364DD597.13E7484E@cs.york.ac.uk>
You can control the evaluation order by the style of programmingused, eg
continuation-passing-style or monadic or some arbitrarily
more complicated system, in some situations though you will not
care about evaluation order.Static type enforcement, strict semantics and
statically enforced state-linearity (purity) all hinder abstract programming.

 - Typeless languages let you program in a way you know is safe
even though a type-checker may not be clever enough to see it.
 - Lazy languages let you abstract over control structures.
 - Non-statically enforced state linearity (impure) lets the
   programmer take responsibility over whether the parts of the
   state they wish to use non-linearly will interfere with each
   other or not.

There are many choices to be made when designing a language, but three
of the big ones are:

  strict or non-strict
  typed  or untyped
  pure   or impure

Pure equates to statically ensured state linearity.
Non-pure equates to non-statically ensured state linearity.

I think non-strict, untyped and impure go together very well,
although I'm having difficulty finding any languages that have
tried this combination.  (someone pointed me towards "Help",
but I'm having problems finding any more info on it, or
contacting the author).

The reason I want impurity is so that the programmer can take
responsibility for state-manipulating functions interfering
with each other or not.  Eg if one part of a program access
files in one directory and one part of a program access
files in another, there is no need to thread the state through
both parts of the program sequentially.  The Lazy State Threads
in Haskell enable multiple state threads but only in a statically-
determinably safe way.  Whenever you insist on statically "ensuring"
things are safe, you remove responsibility from the programmer,
and reduce the extent to which you can abstract over things in
the language, thus reducing the power of the language.

A non-strict, untyped, impure language would provide a very flexible
framework within which many styles of programming could be used,
more than if you left any of those out.  I like the assistance
a type-checker gives during program development, but I would
argue a type-checker should be seen as a tool much like a
spell-checker/grammar-checker, whose use is optional. The choice of
language, and choice to type-system should be decoupled.  Often when
I get type errors it's because I've made a small mistake, often it's
because the type-checker is unable to verify my program is correct, at
this point I would like to just run it even if it doesn't type-check,
but the language and the type-system are too closely coupled.

Anyway that's my view of the world, I'm surprised this combination
of semantics doesn't appear to have been pursued very far before,
It would be interesting to see what it leads to.

Mike Thyer



Craig Dickson wrote:

> Mike Thyer <···@cs.york.ac.uk> wrote:
>
> >The argument that you cannot freely mix laziness with impure featured
> >often seems to go unsupported and unchallenged, the current fashion
> >being to enforce side effects are performed linearly by use of a static
> >type system (eg with monads in Haskell or uniqness typing in Clean).
>
> Well, if your code has side effects, you need some way of knowing what
> order the side effects will occur in. Eager evaluation is one way; lazy
> languages, as you say, typically control side effects by typing or
> strictness annotations. It seems to me that an untyped, non-strict, impure
> language will need some solution to this problem, or its programs will tend
> to behave chaotically as the side effects (which may affect each other!)
> evaluate in a non-guaranteed order.

> >I find the concept of an untyped, non-strict, impure language very
> >appealing.
>
> Why?
>
From: Darius Bacon
Subject: Re: Lazy scheme
Date: 
Message-ID: <72iqb0$4oh$1@its.hooked.net>
Mike Thyer <···@cs.york.ac.uk> writes:

>I'm interested to know if anyone has produced a lazy version of Scheme
>or Lisp,

From the comp.lang.scheme FAQ:

   HELP (a lazy Scheme) is available by anonymous ftp from
   sumex-aim.stanford.edu:/info-mac/lang/lazy-scheme.hqx.  Written by
   Thomas Schiex (······@cert.fr, ······@irit.fr). Help is a complete and
   efficient Scheme-like functional lazy Lisp interpreter.  It works only
   on 68020 (or more) based Macintoshes. It has a 'friendly' interface
   (parenthesis matcher, auto-indent), uses a full call-by-need semantics
   and includes many examples, including a symbolic compiler for the
   680x0. Efficiency is good and lazyness is fully parametrizable (you
   may turn Help into a strict Scheme-like language if you like). French
   AND English updated docs are included in Word4 and plain text formats.

(I have not looked at it or checked if the URL still works.)

-- 
Darius Bacon    http://www.well.com/~djello