[clean-list] Wish list, part 3

[Marco Kesseler]

Hi John,

>1.  I wish that the command line option "-con" were settable
>from within an application so that the application can decide
>whether or not to request that the user hit any key to continue.

Good point. I think however, that the actual problem is that the 
Clean runtime does not behave in a standard way. I think it would be 
better if the Clean runtime NEVER inserts 'hit any key to continue 
code'. Such behaviour is not for a runtime system to decide and 
should always be specified explicitly in the program itself (it is 
almost trivial for a Clean programmer to insert such code at the end 
of a program).

Do you agree?

>2. I wish we had something I call aggressive evaluation.
>Suppose we have something like:
>
>    add x y = x + y
>
>    inc y = add 1 y
>
>If we could instead have:
>
>    inc = add 1 _
>
>then "add 1 _" could under go aggressive evaluation instead of being
>a mere functional closure.  The "_" in this case doesn't mean don't care
>but instead means don't know yet.  Thus after aggressive evaluation, i.e.
>logical rewrite at compile time reducing everything except what we don't
>know yet, we would end up with essentially
>
>    inc = \y -> 1 + y

You can also define 'inc = add 1' (i.e. without the underscore), 
which is equivalent to 'inc = \y -> 1 + y'.

>Once dynamics are fully implemented it would seem this would be
>plausible albeit painful to implement.
>
>Now suppose we have
>
>    sum x y z = x + y + z
>
>    foo = sum 1 _
>
>which would reduce to
>
>    foo = \ y z -> 1 + y + z

Again, 'foo = sum 1' is equivalent to 'foo = \ y z -> 1 + y + z'

>It would even be possible to write
>
>    foobar = sum 1 _ 2
>
>which would reduce to
>
>    foobar = \ y -> 1 + y + 2

Well, that's something that currently takes an auxiliary function 
that shuffles some arguments. I must say that a short notation for 
this kind of thing would come in handy sometimes.

>Or course this is essentially a functional closure but with one
>important distinction, i.e. any optimizing rewrites have been
>taken advantage of  at compile time.
>
>I think aggressive evaluation is similar to multistage programming
>in a way.  Reasoning about types would become fascinating as
>well especially when aggressive evaluation is thought to bridge
>embedded domain languages and their implicit types.  Perhaps
>dynamic types could then be thought of in terms of transforms
>between languages which could than be fed back to reason about
>"implicit types."

I am not sure what you mean. Can you tell some more about this?

regards,
Marco