RE: [stack] Nonstrict Language in Terms of Strict Language

Billy Tanksley — 2001-07-27 18:45:46

From: Jack Waugh [mailto:waugh@...]

>Is Joy a suitable notation in which to demonstrate how to
>implement/simulate/model a functional programming language where the
>functions are nonstrict in their arguments, on top of a functional
>programming language where the functions are strict in thier
>arguments (which Joy is, under either interpretation)?

I'm not sure what 'strict' means here. Assuming it has something to do with
typechecking, then I don't think Joy is an example of what you're looking
for, because Joy isn't strict in its type checking, nor is it implemented in
a functional language.

To the best of my knowledge, there's only one strictly typechecked
concatenative language, strongForth.

>This is a trick question, because actually I don't know how to
>demonstrate this in applicative notation (although I know it can be
>done).

If you're willing to consider either Python or Java to be similar to
functional languages, then Jython is a good example of this. Jython uses
techniques which would unmistakably work for implementing a nonstrict
language in a strict one, whether functional or not.

-Billy

John Cowan — 2001-07-27 18:48:29

Billy Tanksley wrote:

> From: Jack Waugh [mailto:waugh@...]
>
>>Is Joy a suitable notation in which to demonstrate how to
>>implement/simulate/model a functional programming language where the
>>functions are nonstrict in their arguments, on top of a functional
>>programming language where the functions are strict in their
>>arguments (which Joy is, under either interpretation)?
>
> I'm not sure what 'strict' means here. Assuming it has something to do with
> typechecking,

Not at all.

A strict functional language is one that insists on evaluating the
arguments to functions before invoking the functions themselves.
Most commonly used languages are strict.

A nonstrict, or lazy, functional language passes along the arguments
as expressions (really as small functions called "thunks") until
it is absolutely necessary to evaluate them.

--
There is / one art || John Cowan <jcowan@...>
no more / no less || http://www.reutershealth.com
to do / all things || http://www.ccil.org/~cowan
with art- / lessness \\ -- Piet Hein

Billy Tanksley — 2001-07-27 19:49:18

From: John Cowan [mailto:cowan@...]
>Billy Tanksley wrote:
>> From: Jack Waugh [mailto:waugh@...]

>>>Is Joy a suitable notation in which to demonstrate how to
>>>implement/simulate/model a functional programming language where the
>>>functions are nonstrict in their arguments, on top of a functional
>>>programming language where the functions are strict in their
>>>arguments (which Joy is, under either interpretation)?

>> I'm not sure what 'strict' means here. Assuming it has
>> something to do with typechecking,

>Not at all.

Ah. He means strict evaluation rather than checking, then. He didn't give
any context from which to decide (and my English parser is strict, in his
sense :-).

In general, concatenative languages work poorly with non-strictness.
Concat languages treat everything as a function, so they have to treat
everything equally. This gives no opportunity to delay execution of some
things, unless you allow your compiler to delay execution of everything.
This is hard, and the benefits are unclear, since the compiler has to make
choices which are better left to the programmer.

In contrast, with a non-strict applicative language, the programmer's
already written everything in a tree format (where the branches are function
calls), so the compiler doesn't have to make the hard choices.

I'm skipping over some interesting options in this discussion. In
particular, someone here has designed a concatenative language which is
superstrict: it executes operations as soon as possible (as soon as all of
the details for them are known and constant). This turns out to be a little
easier with a concatenative language than it is with an applicative one,
because in a concatenative language all of the details come BEFORE the
function, so they're already all known. This turns out to have many of the
same benefits as lazy evaluation; perhaps, in fact, it's actually the
concatenative version of laziness. (And perhaps I should call it "diligent
evaluation", to fit my worldview. :-)

>There is / one art || John Cowan <jcowan@...>

-Billy