merits of Lisp vs Python

[William James]

André Thieme wrote:
> William James schrieb:
> > André Thieme wrote:
> >> William James schrieb:
> >>
> >>> def nif num, pos, zero, neg
> >>>   send( num>0 ? pos : (num==0 ? zero : neg) )
> >>> end
> >> btw, your nif body is built out of 13 tokens, so more
> >> complicated than the Python version.
> >>
> >>
> >> André
> >> --
> >
> > def nif num, *args
> >   send args[ 1 + (0 <=> num) ]
> > end
>
>
>                   send
>                     |
>                     |
>                    [ ]
>                   /   \
>                 /       \
>               /           \
>             args           +
>                          /  \
>                        /     \
>                       1      ()
>                               |
>                               |
>                              <=>
>                              / \
>                            /     \
>                           0      num
>
> Okay, 9. Now it is at the complexity level of the Lisp
> and Python example.
> But how would a call to nif look like?

A call is unchanged:

[0, 2.5, -8].map{|x| nif x, :p, :z, :n}


> I hope it doesn't involve an extra operator to group the
> args into a list or tuple. That would add more complexity to
> each call - so one should better have a slightly more complex
> nif because that exists only one time.
>
> And can this nif now handle any input values, such as strings
> or function objects?

It handles only symbols.
I suppose this can handle anything ...

p = proc {
  puts "very positive"
  "positive" }
z = proc {
  puts "no no"
  "zero" }
n = proc {
  puts "very negative"
  "negative" }
def nif num, *args
  args[ 1 + (0 <=> num) ].call
end

[0, 2.5, -8].map{|x| nif x, p, z, n}
puts [0, 2.5, -8].map{|x| nif x,
  proc{'zero'}, proc{'plus'}, proc{'minus'}}

... if you wrap everything in a proc (lambda).