# 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