Proposal to remove partial application for if, and, cons etc.

[deech]

Hi all,
I propose updating the spec to mandate that special forms like 'if', 'and' and 'cond' be fully saturated.

Currently the spec allows all primitive function to be partially applied. This can cause unwanted behavior when dealing with function that don't take their arguments in applicative order. For example:
(1-) ((if true) (output "don't launch missiles~%") (output "launch missiles~%"))
don't launch missiles
launch missiles
"don't launch missiles
"

Here the else-branch is evaluated even though the predicate is 'true'.

-deech

[fuzzy wozzy]

would this be partial solution? (I haven't a clue...)

(if ((if true) true false) (output "hello~%") (output "hey~%"))
hello
"hello
"
using list seems to smooth things out some...

((if true) [hello] [hey])
[hello]

[Mark Tarver]

Thx for the contribution. It's an interesting point to be sure and one I've not thought on. I don't know how important this is, practically.  I've never been bothered with this issue in programming.  If you curry stuff like that you will force the evaluation to be strict.  But even if you changed the spec you can still make this happen with fully saturated expressions.

(0-) ((/. X Y Z (if X Y Z)) true (print yes) (print no))

yesnoyes

Mark

[Neal Alexander]

This is a good idea. I'm probably going to disable support for currying on 'functions' that are handled specially as compiler transformations in my port:
 type, defun, lambda, freeze, let, if, or, and, cond, trap-error, eval-kl.

[Mark Tarver]

Ah well, this is a different point altogether - a question of ease of low level implementation.  I'm a bit more sympathetic to that.  In the CL port all these issues are handled by compiler transformation.  Well of those defun, lambda, let and cond have no arity in Shen and hence cannot be curried. This leaves freeze, if, or, and, trap-error, eval-kl etc.  However the more special cases you have, the slower the system will type check on the whole since special cases absorb cpu.

Mark

[Mark Thom]

I agree that if, and, or, cond, let, freeze, lambda and defun, defmacro, etc. should be treated as special forms, but what's wrong with currying cons?

[Bruno Deferrari]

I think the 'cons' in the subject was just a typo for 'cond'.

> --
> You received this message because you are subscribed to the Google Groups
> "Shen" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qilang+un...@googlegroups.com.
> To post to this group, send email to qil...@googlegroups.com.
> Visit this group at https://groups.google.com/group/qilang.
> For more options, visit https://groups.google.com/d/optout.



--
BD

[Mark Thom]

Ah, of course. If that's the case, I withdraw my comment..

[Mark Tarver]

You actually really cannot curry those 1-place functions (freeze, thaw) etc. within a conventional type theory any way.  You'll find CL-Shen will allow you to do it but not with type checking enabled.  Only functions whose arity > 1 are open to currying and this excludes defun, defmacro (which is not KL anyway) cond, let, ((arity defun) gives -1) and so on.  I think the original motivation is understandable but misplaced in that changing the spec does not eliminate the behaviour that is isolated.    I think it is really a function of understanding that currying forces the evaluator to evaluate arguments one at a time in applicative order.

Re low level implementation; partial applications of and if or are statically eliminable in favour of the corresponding lambda forms. Shen does this with CL all the time and gets a good performance.  

Mark