André Thieme wrote:
> Paul Rubin schrieb:
> > André Thieme <[EMAIL PROTECTED]> writes:
> >> and the Lisp version has only 9:
> >> nth, 1+, truncate, signum, num, list, pos, zero, neg
> >
> > Oh come on, you have to count the parentheses too.
>
> We could define hundreds of way how to count tokens.
> But see the program as a tree:
>
> nth
> / \
> / \
> / \
> 1+ list
> | / | \
> | / | \
> truncate pos zero neg
> |
> |
> signum
> |
> |
> num
>
> And I didn't count the indentation level and \n in Python code.
> Why should I? They are editor commands.
>
>
> > Anyway, token count doesn't mean much, you have to instead go by the
> > user's cognitive effort in dealing with the prefix notation etc.,
>
> How complicated ss it to say "cmp(a, b)" compared to "a cmp b"?
> After a few days writing Lisp code your brain specializes on that
> style. Arabian countries write from right to left. They seem to have
> no problem to use what they know.
> I admit that I am used to write +, -, * and / infix, because I were
> trained in that thinking since day 1 in school.
> In our example program there was only 1+ compared to ".. + 1" which
> looks "alien" to untrained people.
> If a program uses extensive math we can get syntax for Lisp that is
> even more pleasant to read than Pythons:
> 17a + x³-x²
>
>
>
> > which isn't purely a matter of token count. And if (+ 2 3) were
> > really as easy to read as 2+3, mathematics would have been written
> > that way all along.
>
> Mathmaticians invented prefix notation and they use it regularily.
> They inventey operators that wrap around their arguments, as one can
> see here: http://www.mathe-trainer.com/formel/?SN=&t=1
>
> Or think of indices, etc.
>
>
>
> >> TypeError: 'str' object is not callable
> >> I don't know how I can fix that. Maybe you could tell me.
> >
> >>>> lazy_nif(0, lambda: "p", lambda: "z", lambda: "n")
>
> Yes, that works. And that's why I wanted to make it a macro.
> Now you are essentially doing what I did in my first Lisp version.
> While this works it is farer away from what we think.
>
> (nif 0 "p" "z" "n")
> (nif 0 #'p #'z #'n)
> are exactly what one thinks.
> For this reason "if" is implemented as a keyword in Python.
> It allows you to give code as a block instead of embedding it into
> a lambda or a def (which even needs a name).
>
>
> And we might go further (again with an easy Graham example).
> See this typical pattern:
>
> result = timeConsumingCalculation()
> if result:
> use(result)
>
> We need this ugly temporary variable result to refer to it.
> If we could use the anaphor[1] "it" that could make situations like
> these more clean.
>
> Imagine Python would have an "anaphoric if", "aif". Then:
>
> aif timeConsumingCalculation():
> use(it)
>
> Many Lispers might have this as a macro in their toolbox after some
> time of coding or after reading Graham.
> A short three-liner in Lisp and I can really say:
>
> (aif (timeConsumingCalculation)
> (use it))
>
> How would you solve this in Python?
> You could embed it inside a lambda and must somehow make the
> variable "it" visible in it, because in the context of aif this
> "it" gets bound to the result.
In Ruby:
def aif val
yield val if val
end
def complex_calc n
if n % 2 == 1
n**n
else
nil
end
end
aif( complex_calc( 9 ) ) {|x| puts "hello, #{x}"}
aif( complex_calc( 8 ) ) {|x| puts "hello, #{x}"}
--- output -----
hello, 387420489
--
http://mail.python.org/mailman/listinfo/python-list
