My mind wanders around a lot and I find that I have something more to say about function nesting and how it turned out to be involved with boolean statements. To see the relation takes a while but please bear with me.
If we have a nested statement such as (sin (cos 0.5)) we instinctively want to simplify it to (sin cos 0.5) but are frustrated in that the current syntax doesn't allow us to do that. So the good lisper can write himself a function that we will call NEST and then be able to write something like (nest sin cos 0.5). This may be elegant but in most cases does not satisfy because we must type another five characters (don't forget the space). Often the nesting you actually run across only goes for two levels and it is just easier to type the two parentheses, this approach only starts to have value at three levels of nesting. We can't get rid of that desire to type (sin cos 0.5)! A lisper always wants to do the least typing possible. For fun I wrote this function
(define-macro (nest)
(setq op (args 0) rargs (rest (args)))
(op (eval (if (symbol? (rargs 0))
(begin
(setq r (rest (rargs))
lst (rargs -1)
r (if (symbol? lst)
(setf (r -1)(list lst))
r
)
)
(apply (rargs 0)(map eval r))
)
(rargs 0)
))))
I hope someone writes a better version of this because I am pretty sure I didn't take the best approach. This function takes advantage of the fact that all functions that are capable of nesting only have a single argument. And we can use this frame to redefine all of the existing single argument functions if we wish. Here is a demonstration example with the SIN and COS functions:
(define-macro (sn) (nest sin ))
(define-macro (cs) (nest cos ))
Using these new functions you can now write (sn cs 0.5) and get the desired result. If you redefine all of NewLisp's single argument functions and your own this way you can have built-in nesting the way God intended!
However I ran across a case where making all single argument functions act this way is undesirable. I found that boolean functions that take single arguments should be treated in a different manner. I came up with this fun little piece of code:
(define (bool-if func x A B)
(if (or A B)
(eval (if (func x) A B))
(func x)))
What this function does is allow any boolean function to double as its own if/then/else conditional statement. How does this work? Suppose we define a new version of the INTEGER? function as
(define (new-integer? x A B)
(bool-if integer? x A B))
Now if we write (new-integer? 3) this behaves the same way as integer? does. But if we were to write (new-integer? 3 "A" "B") it now behaves like (if (integer? 3) "A" "B"). We now don't have to write the IF statement!
So we have two conflicting desires here, we can't make all single argument functions have nesting behavior and be able to have built-in conditionals at the same time. I have concluded that this is not a problem in practice because almost all nested statements that I have run across do not tend to have conditionals in them or at least rarely. Therefore I propose that all boolean functions (functions that return true or nil) have built-in conditional capability and that all other single argument functions have built-in nesting. This could be further advanced by having two new functions DEFINE-BOOL and DEFINE-NEST so that users could define such functions right from the beginning. How would this work? Let us say that we want to define a new boolean function that determines whether a number is even or odd. We will call this function EVEN?. I envisage writing something like
(define-bool (even?)
(zero? (% $X 2))
)
The user only has to supply the name of the function and the code for the logical test. $X represents an internal variable that stands for the single argument that the function takes for the default case. All of the rest of the overhead is taken care of by DEFINE-BOOL. A similar technique would be used for a DEFINE-NEST function.
I believe that there cumulative advantages to implementing both of these approaches to NewLisp. It doesn't break previous code but adds a great enhancement. Wouldn't it be nice to get rid of a lot of IF statements? Anyone have any thoughts on the matter?
I think it's cool, but I'm not sure this would result in very clear code (for others reading it). People coming to newLISP from other Lisps would be baffled by this. Does the advantage of not having to write an 'if' make it worth it? I'm not sure...
BTW, Clojure has a builtin function called 'comp' (for composition) that is essentially your 'nest' macro. I think explicitly calling nest/comp is the better way of doing it, as that's more "idiomatic".
Some bugs I noticed: new-integer? and bool-if should be macros so that they don't evaluate their arguments (and you might want to use define-smacro, see below), there are missing calls to parameters in the sn/cs functions, and your nest macro is polluting its calling context by not using 'let' to set 'op', rargs, r, and lst.
(let (_temp1 (append (fn-macro) (cons (1 (args 0)) (rest $args))) _temp2 (args 0 0))
(def-new '_temp1 (sym _temp2 _temp2))
)
)
I can't find the original thread where define-smacro was discussed....
Only thing I've been able to find that discusses the hygenic macro issue is here:
http://newlispfanclub.ryon.webfactional.com/forum/viewtopic.php?f=5&t=1080
I should elaborate that beyond being non-idiomatic, it would make it difficult to tell whether the code you're seeing is function composition, or a call to a function that's accepting several arguments, which is why it's probably better to be explicit.
(define-macro (make-pass)
(doargs (arg)
(letex ((Old arg)
(New (sym (append (string arg) "&"))))
(define-macro (New)
(Old (eval (args)))))))
(catch& while (read-line)
(setq line (current-line))
(if (not& empty? line)
(print& format "%sn" line)
(throw 'empty)))
I also Code Select Expand ; The composition of the functions is one of the basic mathematical
; operations. In this post, I'll try to define composition of
; functions and macros (Newlisp macros=fexprs) in Newlisp.
;
; Such composition should satisfy the following:
;
; ((composition 'f1 ... 'fn) _ _ _) = (f1 (f2 ... (fn _ _ _)))
;
; for all functions and macros.
;
; It wasn't that easy as I thought. First, I limited myself on the
; case of the composition of two functions. After some experimentation
; I came to that:
(set 'compose2 (lambda(f g)
(expand (lambda-macro()(letex((L (cons 'g (args))))(f L)))
'f 'g)))
; I tested it on simple example:
(println (compose2 'sin 'cos))
; (lambda-macro ()
; (letex ((L (cons 'cos (args)))) (sin L)))
(println ((compose2 'sin 'cos) 3) (sin (cos 3))) ; OK, it works.
; Then I tested it on two special, well, entities, i.e. identity
; function and identity macro:
(set 'I (lambda(x)x))
(set 'IM (lambda-macro(x)x))
(println ((compose2 'I 'sin) 3)) ; 0.1411200081, as it should be, i.e. (I (sin 3))
(println ((compose2 'sin 'I) 3)) ; 0.1411200081, as it should be, i.e. (sin (I 3))
(println ((compose2 'IM 'sin) 3)) ; (sin 3), as it should be, i.e. (IM (sin 3))
(println ((compose2 'sin 'IM) 3)) ; 0.1411200081, as it should be (sin (IM 3))
; OK; it appears it worked. Now I'll have to solve multi-version,
; I.e. composition of many functions or macros
(set 'compose (lambda()
(case (length (args))
(0 I) ; because (I (S x)) <=> (S x),
; no matter if S is function or macro
; so I can be always added from the left.
(1 (first (args)))
(2 (apply compose2 (args)))
(true (compose2 (first (args)) (apply compose (rest (args))))))))
(println ((compose sqrt) 65536)) ; 256
(println ((compose sqrt sqrt) 65536)) ; 16
(println ((compose sqrt sqrt sqrt) 65536)) ; 4
; OK, it works as well. However, result of the composing is
; rather complicated because of recursive definition
(println (compose 'f1 'f2 'f3 'f4))
; (lambda-macro ()
; (letex ((L (cons '(lambda-macro ()(letex ((L (cons '(lambda-macro ()(letex ((L (cons 'f4 (args))))
; (f3 L)))
; (args))))
; (f2 L)))
; (args))))
; (f1 L)))
;
;
; If iteration is used for definition of compose, then composition
; can be both shorter and faster - but not more elegant.