Kaz Kylheku wrote:
The removal for the need for manual object lifetime computation does
not cause a whole class of useful programs to be rejected.
Sometimes you must be able to guarantee that a resource has been disposed
before you can continue. That is why we have finalisers in OCaml and
Kaz Kylheku [EMAIL PROTECTED] writes:
Incorrect, I believe. The above is like saying Lisp's lack of
optional manual storage allocation and machine pointers makes Lisp
less powerful.
That is true. By itself, that feature makes Lisp less poweful for
real-world software dev, which is why
Paul Rubin wrote:
[...] There are programs you can write in C
but not in Lisp, like device drivers that poke specific machine
addresses.
I should assume you meant Common Lisp, but there isn't really any
reason you couldn't
(poke destination (peek source))
in some version of Lisp
Paul Rubin http://[EMAIL PROTECTED] writes:
In fact, all previously correct programs continue to work as before,
and in addition, some hitherto incorrect programs become correct.
That's an increase in power: new programs are possible without losing
the old ones.
There's more to power than
[EMAIL PROTECTED] writes:
I should assume you meant Common Lisp, but there isn't really any
reason you couldn't
(poke destination (peek source))
That breaks the reliability of GC. I'd say you're no longer writing
in Lisp if you use something like that. Writing in this augmented
Lisp
Bill Atkins [EMAIL PROTECTED] writes:
GC also gets rid of programs. There are programs you can write in C
but not in Lisp, like device drivers that poke specific machine
addresses.
I'm sure this would be news to the people who wrote the operating
system for the Lisp machine.
That stuff
Paul Rubin http://[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
I should assume you meant Common Lisp, but there isn't really any
reason you couldn't
(poke destination (peek source))
That breaks the reliability of GC. I'd say you're no longer writing
in Lisp if you use
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
I should assume you meant Common Lisp, but there isn't really any
reason you couldn't
(poke destination (peek source))
That breaks the reliability of GC. I'd say you're no longer writing
in Lisp if you use something like that. Writing
Bill Atkins [EMAIL PROTECTED] writes:
Whatever do you mean? The portion of memory used for memory-mapped
registers is simply excluded from GC; everything else works as normal.
Well ok, if the peek and poke functions validate the addresses.
All modern Lisps (yes, *Common* Lisps) support a
[EMAIL PROTECTED] writes:
Even regarding interupts, I don't see a problem without a solution:
(with-interupts-and-garbage-collection-disabled
(poke destination (peek source))
It's not just GC or interrupts, it's the possibility of clobbering the
Lisp heap. If the peek/poke
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
Even regarding interupts, I don't see a problem without a solution:
(with-interupts-and-garbage-collection-disabled
(poke destination (peek source))
It's not just GC or interrupts, it's the possibility of clobbering the
Lisp heap.
[EMAIL PROTECTED] writes:
So don't (poke (random) value). That would be obvious to anyone
capable of writing a device driver in C or Lisp or Oberon or
Similarly in C programs, don't do
*random = 0;
Avoiding that is easier said than done. C programs suffer endless
bugs of that type.
On 11 Dec 2006 03:01:32 -0800, Ravi Teja [EMAIL PROTECTED] wrote:
Timofei Shatrov wrote:
[snip]
Of course, doctest is hardly the ultimate testing solution. But it does
an admirable job for many cases where you don't need to setup elaborate
tests.
It's not surprising that no one uses this
On Mon, 18 Dec 2006 05:19:49 +0100, //[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
So don't (poke (random) value). That would be obvious to anyone
capable of writing a device driver in C or Lisp or Oberon or
Similarly in C programs, don't do
*random = 0;
Avoiding that is
Jean-Paul Calderone wrote:
On 11 Dec 2006 03:01:32 -0800, Ravi Teja [EMAIL PROTECTED] wrote:
Timofei Shatrov wrote:
[snip]
Of course, doctest is hardly the ultimate testing solution. But it does
an admirable job for many cases where you don't need to setup elaborate
tests.
It's not
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
So don't (poke (random) value). That would be obvious to anyone
capable of writing a device driver in C or Lisp or Oberon or
Similarly in C programs, don't do
*random = 0;
Avoiding that is easier said than done. C programs suffer
greg wrote:
Ken Tilton wrote:
I did explain the last little fun bit (where reverse code miraculously
got a case-specific signed-value parameter bound to exactly the
right bit of math structure).
I didn't mention that because it was addressed by
another poster. The signature of the
Ken Tilton schrieb:
Looks promising. How does a generic engine that sees only a solution (a
list of mathematical expressions and for each the transformations,
results, and opnds logged by individual TF functions) build up this
environment such that it has named attributes such as
Paul Rubin wrote:
Kirk Sluder [EMAIL PROTECTED] writes:
Personally, I've always preferred use the imperative to describe
basic math rather than the passive. This would seem to map better to
RPN than infix.
For writing down complicated, nested expressions too? That's very
unusual. E.g.
greg ha escrito:
I don't know about the other Pythonistas in this
discussion, but personally I do have experience with
Lisp, and I understand what you're saying. I have
nothing against Lisp parentheses, I just don't agree
that the Lisp way is superior to the Python way in
all respects, based
Paul Rubin wrote:
[EMAIL PROTECTED] writes:
a = 'hello'
a[0] = 'H' # attempt to change first letter to upper case
As CLPython mirrors Python semantics, this results in a TypeError. The
internal representation of an immutable Python string is a mutable Lisp
string, but there is
greg [EMAIL PROTECTED]
I once heard mention of a system of units in use at
one time with the odd feature that capacitance came
out in units of length.
Picture the scene: Hobbyist walks into Dick Smith
store and says I'd like a 5cm capacitor, please.
This is correct - think of it as
greg schrieb:
André Thieme wrote:
(aif (timeConsumingCalculation)
(use it))
I think the answer is that you just wouldn't do
that in Python at all. Having magic variables
spring into existence in your local namespace
as a side effect of calling something is just
not Pythonic. (It is
André Thieme [EMAIL PROTECTED] writes:
Sounds like Blub to me:
http://www.paulgraham.com/avg.html
It never occurs to Lisp programmers that Lisp, too, might be a Blub.
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin schrieb:
Kirk Sluder [EMAIL PROTECTED] writes:
Personally, I've always preferred use the imperative to describe
basic math rather than the passive. This would seem to map better to
RPN than infix.
For writing down complicated, nested expressions too? That's very
unusual.
On Sat, 16 Dec 2006 14:09:11 +0100
André Thieme [EMAIL PROTECTED] wrote:
# Sounds like Blub to me:
# http://www.paulgraham.com/avg.html
Well, too bad for you...
# I will quote some parts of it:
# snip
# By induction, the only programmers in a position to see all the
# differences in power
Kay Schluehr wrote:
Ken Tilton schrieb:
Looks promising. How does a generic engine that sees only a solution (a
list of mathematical expressions and for each the transformations,
results, and opnds logged by individual TF functions) build up this
environment such that it has named
On 2006-12-16 08:21:59 -0500, Paul Rubin http://[EMAIL PROTECTED] said:
It never occurs to Lisp programmers that Lisp, too, might be a Blub.
Of course it does - Thats why we try ocaml and haskell etc. It's just
that we don't see the useful features of these languages as being
sufficiently
Raffael Cavallaro ha escrito:
This lock-in to
a particular paradigm, however powerful, is what makes any such
language strictly less expressive than one with syntactic abstraction
over a uniform syntax.
Right, but it would be also remarked that there is not reason to
ignoring the development
Using LISP-like syntax for everything would be so stupid as using
quantum mechanics for billiards.
Claiming that LISP parens are Stupid, Superfluous, or Silly just
because you do not need them in your limited field of discourse, would
be so stupid as those people thinking that just because they
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
Kirk Sluder [EMAIL PROTECTED] writes:
Personally, I've always preferred use the imperative to describe
_basic_ math rather than the passive. This would seem to map better to
RPN than infix.
(emphasis added)
Raffael Cavallaro wrote:
Of course it does - Thats why we try ocaml and haskell etc. It's just
that we don't see the useful features of these languages as being
sufficiently useful to compensate for their lack of the ability to
easily do syntactic abstractions over a uniform syntax.
That
In article
[EMAIL PROTECTED],
Kirk Sluder [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
If computer languages were to mimic natural languages on this point,
they would support
Ken Tilton wrote:
[EMAIL PROTECTED] wrote:
Code is data is code
I was hoping no one would make that mistake. :) macros are all about
code is data, but code is not data in Python* so the two words code and
data serve to differentiate them for Pythonistas.
I disagree. I frequently write
On 2006-12-16 13:58:37 -0500, Jon Harrop [EMAIL PROTECTED] said:
Why do you think that uniform syntax is necessary to provide new paradigms
when it is equivalent to infix syntax?
Because it doesn't require one to write a parser for each new syntax
for each new paradigm.
In what way is
[EMAIL PROTECTED] wrote:
Ken Tilton wrote:
[EMAIL PROTECTED] wrote:
Code is data is code
I was hoping no one would make that mistake. :) macros are all about
code is data, but code is not data in Python* so the two words code and
data serve to differentiate them for Pythonistas.
I
Raffael Cavallaro [EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com writes:
It never occurs to Lisp programmers that Lisp, too, might be a Blub.
Of course it does - Thats why we try ocaml and haskell etc. It's just
that we don't see the useful features of these languages as being
sufficiently
Ken Tilton wrote:
How does a generic engine that sees only a solution (a
list of mathematical expressions and for each the transformations,
results, and opnds logged by individual TF functions) build up this
environment such that it has named attributes such as signed-value?
How did your
On Sun, 17 Dec 2006 00:19:40 +0100, //[EMAIL PROTECTED] wrote:
Incorrect, I believe. The above is like saying Lisp's lack of
optional manual storage allocation and machine pointers makes Lisp
less powerful. It's in fact the absence of those features that lets
garbage collection work
greg [EMAIL PROTECTED] writes:
Ken Tilton wrote:
McCarthy: Is code also data in Python?
Norvig: No.
I don't think that was the right answer. He should have
said Yes, and then shown McCarthy eval() and exec.
Code isn't quite as *convenient* to work with as data
in Python as it is in
greg [EMAIL PROTECTED] writes:
André Thieme wrote:
(aif (timeConsumingCalculation)
(use it))
I think the answer is that you just wouldn't do
that in Python at all. Having magic variables
spring into existence in your local namespace
as a side effect of calling something is just
not
Ken Tilton wrote:
Andrew Reilly wrote:
That all looks like data.
No, not reverse, the part you did not understand. I do not mean what the
code was doing, I meant that it was code.
Code is data is code - even in Python:
skills_table = [
{
title: Absolute Value,
annotations: [Bleah
Ken Tilton [EMAIL PROTECTED] writes:
Steven D'Aprano wrote:
If that's the best example of what macros can be used for, frankly I'm
unimpressed.
We're shocked.
Don't anyone tell him about LOOP.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per
Wolfram Fenske [EMAIL PROTECTED] writes:
Paul Rubin http://[EMAIL PROTECTED] writes:
Wolfram Fenske [EMAIL PROTECTED] writes:
Yes, I wrote about it in another post. It was introduced in Python
2.5. And if it hadn't been I'd still have to write code like this.
You could do something
Steven D'Aprano [EMAIL PROTECTED] writes:
How am I being silly? Do you not believe that people write case blocks
with fifty tests? Okay, how about twenty? Ten? Eight?
You should check out generic functions in CLOS. Rather than writing a
ridiculously long case block, you can use EQL
Delaney, Timothy (Tim) wrote:
Ken Tilton wrote:
But this is not a case where a function can't handle the job.
Is, too.
And Ken moves one step closer towards Python ...
http://www.google.com.au/search?q=monty+python+argument+sketch
Tim Delaney
is it time to mention the storm troopers
Gabriel Genellina wrote:
You can even make S = cT (c=ligth of speed in void space).
The choice of fundamental units is rather arbitrary, and can be reduced
further to only 1 fundamental unit and even NO fundamental units.
I once heard mention of a system of units in use at
one time with the
Ken Tilton wrote:
So this:
(defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv))
,@reverser)
becomes this:
(defmethod tf-reverse ((id (eql ',sub-id)) tf drv
aux (opnds (drv-opnds tf drv)))
(loop for resx in (results drv)
Ken Tilton wrote:
The reason I post macro expansions along with examples of the macro
being applied is so that one can see what code would have to be written
if I did not have the defskill macro to write them for me.
It seems to me your brain is somewhat stuck on the use
of macros. You're
[EMAIL PROTECTED] wrote:
Neil Cerutti wrote:
On 2006-12-13, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Expressions keep the same meaning even if you have to start
breaking them across lines, etc.
Yes, it's the same way in Python. Of course, not everything is an
expression in Python, so it's
[EMAIL PROTECTED] wrote:
I wrote my first Python in a non-Python-aware editor, and somehow had
swapped tabs and spaces; when I moved it to IDLE---the indentation
*looked fine* but was invisibly weird.
That can admittedly be a problem. It would help if the
parser complained by default about
[EMAIL PROTECTED] wrote:
Neil Cerutti wrote:
The parenthesis I added means I don't have
to use the new-line escape character (\), either.
Is this so unconscious that you don't recognize you are doing it, even
though you take a sentence to explain what you had to do to work around
it?
Ken Tilton wrote:
What if it turns into an SQL lookup during refactoring?
If the macro can produce SQL code, then whatever interprets the
table can produce SQL code as well.
If you're thinking of the macro taking apart the user's reverse
function (rather than just wrapping it) and somehow
Willem Broekema wrote:
I guess in part it's because there are not that many people really into
both Python and Lisp, and those who are might not find this an
interesting project because there is nothing wow to show, yet.
Another reason (or maybe the reason for the reason) is
that people are
greg wrote:
Willem Broekema wrote:
I guess in part it's because there are not that many people really into
both Python and Lisp, and those who are might not find this an
interesting project because there is nothing wow to show, yet.
Another reason (or maybe the reason for the reason) is
greg schrieb:
Ken Tilton wrote:
The reason I post macro expansions along with examples of the macro
being applied is so that one can see what code would have to be
written if I did not have the defskill macro to write them for me.
It seems to me your brain is somewhat stuck on the use
greg wrote:
Ken Tilton wrote:
So this:
(defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv))
,@reverser)
becomes this:
(defmethod tf-reverse ((id (eql ',sub-id)) tf drv
aux (opnds (drv-opnds tf drv)))
(loop for resx in
greg wrote:
Ken Tilton wrote:
The reason I post macro expansions along with examples of the macro
being applied is so that one can see what code would have to be
written if I did not have the defskill macro to write them for me.
It seems to me your brain is somewhat stuck on the use
André Thieme [EMAIL PROTECTED] writes:
def nif(num, pos, zero, neg):
if num 0:
return pos
else:
if num == 0:
return zero
else:
return neg
def nif(num, pos, zero, neg):
return (neg, zero, pos)[cmp(num, 0)+1]
The messages were printed in each case.
Paul Rubin wrote:
André Thieme [EMAIL PROTECTED] writes:
def nif(num, pos, zero, neg):
if num 0:
return pos
else:
if num == 0:
return zero
else:
return neg
def nif(num, pos, zero, neg):
return (neg, zero, pos)[cmp(num, 0)+1]
Since we are in one
greg wrote:
Ken Tilton wrote:
The last example showed the macro inserting code to magically produce
a binding inside the reverse function.
Are you sure? It looked to me like it was adding code *around*
the reverse function, not inside it. I posted a Python function
that achieves the
Christophe Cavalaria [EMAIL PROTECTED] writes:
def nif(num, pos, zero, neg):
return (zero, pos, neg)[cmp(num, 0)]
Owwoo!!!
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
nif is even cleaner in Haskell, if I have this right:
nif x p z n | (x 0) = n
| (x == 0) = z
| (x 0) = p
All Haskell evaluation is automatically lazy, so no lambdas etc. needed.
You can use that style in CL.
(defun nif (x p z
Paul Rubin schrieb:
André Thieme [EMAIL PROTECTED] writes:
def nif(num, pos, zero, neg):
if num 0:
return pos
else:
if num == 0:
return zero
else:
return neg
def nif(num, pos, zero, neg):
return (neg, zero, pos)[cmp(num, 0)+1]
That is a nice
Christophe Cavalaria schrieb:
Paul Rubin wrote:
André Thieme [EMAIL PROTECTED] writes:
def nif(num, pos, zero, neg):
if num 0:
return pos
else:
if num == 0:
return zero
else:
return neg
def nif(num, pos, zero, neg):
return (neg, zero,
Wade Humeniuk [EMAIL PROTECTED] writes:
nif is even cleaner in Haskell, if I have this right:
nif x p z n | (x 0) = n
| (x == 0) = z
| (x 0) = p
All Haskell evaluation is automatically lazy, so no lambdas
etc. needed.
You can use that style in
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.
Anyway, token count doesn't mean much, you have to instead go by the
user's cognitive effort in dealing with the
Paul Rubin http://[EMAIL PROTECTED] writes:
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.
No. Parentheses are editor commands. They don't count anymore than
[EMAIL PROTECTED] wrote:
Ken Tilton wrote:
Andrew Reilly wrote:
That all looks like data.
No, not reverse, the part you did not understand. I do not mean what the
code was doing, I meant that it was code.
Code is data is code
I was hoping no one would make that mistake. :) macros
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:
Paul Rubin wrote:
André Thieme [EMAIL PROTECTED] writes:
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.
Maybe I am a mutant as Ken suggests but while mathematicians may
think in terms of
André Thieme wrote:
greg schrieb:
Ken Tilton wrote:
The reason I post macro expansions along with examples of the macro
being applied is so that one can see what code would have to be
written if I did not have the defskill macro to write them for me.
It seems to me your brain is
Neil Cerutti schrieb:
That's not a real difficulty, is it?
CL-USER (mapcar #'(lambda (x)
(funcall (nif x p z n)))
'(0 2.5 -8))
Didn't you forget the #' before p, z and n?
CL-USER (mapcar #'(lambda (x)
(nif x (p) (z) (n)))
William James schrieb:
I suppose that is Ruby code.
So my statement was correct when I said:
In some languages it would look a bit cleaner, for example Ruby.
This is because it has a minimal syntax for lambda.
def p
puts very positive
positive
end
def z
puts no no
zero
end
def
William James schrieb:
def nif num, pos, zero, neg
send( num0 ? pos : (num==0 ? zero : neg) )
end
btw, your nif body is built out of 13 tokens, so more
complicated than the Python version.
André
--
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
I thought it was of some interest though I'm a little surprise by the
choice of CL rather than Scheme as a target.
In many aspects Python is a subset of CL. In CLPython, exceptions are
Lisp conditions with a custom metaclass (strictly spoken not portable
CL), Python
On 2006-12-15, André Thieme
[EMAIL PROTECTED] wrote:
In Lisp it is like an IF and represents exactly what we think.
IF in Lisp:
(if expr
(then-part)
(else-part))
nif in Lisp:
(nif expr
(positive-part)
(zero-part)
(negative-part))
It looks as if it were a
greg schrieb:
[EMAIL PROTECTED] wrote:
Adding parentheses ... all this is a
burden specific to Python.
As opposed to Lisp, where all you have to do is
use parentheses... oh, er...
Lisp has no parens. An editor could support a mode where code
is displayed in written in trees. There
André Thieme wrote:
William James schrieb:
def nif num, pos, zero, neg
send( num0 ? 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
--
William James schrieb:
André Thieme wrote:
William James schrieb:
def nif num, pos, zero, neg
send( num0 ? 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
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
André Thieme wrote:
William James schrieb:
André Thieme wrote:
William James schrieb:
def nif num, pos, zero, neg
send( num0 ? 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
[EMAIL PROTECTED] schrieb:
William James schrieb:
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
On Fri, 15 Dec 2006 17:21:12 +0100
André Thieme [EMAIL PROTECTED] wrote:
# 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
André Thieme wrote:
[EMAIL PROTECTED] schrieb:
William James schrieb:
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
André Thieme [EMAIL PROTECTED] writes:
And I didn't count the indentation level and \n in Python code.
Why should I? They are editor commands.
No they're part of Python syntax. A change in indent level is
recognized by Python's lexical scanner as a token and you should count
it. You wouldn't
André Thieme [EMAIL PROTECTED] writes:
Lisp has no parens. An editor could support a mode where code
is displayed in written in trees. There wouldn't be a single paren.
But there would be even more tokens, the lines going between the nodes
in the trees, for example.
--
[EMAIL PROTECTED] writes:
a = 'hello'
a[0] = 'H' # attempt to change first letter to upper case
As CLPython mirrors Python semantics, this results in a TypeError. The
internal representation of an immutable Python string is a mutable Lisp
string, but there is no way you can actually
Paul Rubin schrieb:
André Thieme [EMAIL PROTECTED] writes:
Lisp has no parens. An editor could support a mode where code
is displayed in written in trees. There wouldn't be a single paren.
But there would be even more tokens, the lines going between the nodes
in the trees, for example.
André Thieme [EMAIL PROTECTED] writes:
But there would be even more tokens, the lines going between the
nodes
in the trees, for example.
These are painted by the editor.
If you have to tell the editor where to put them, they are tokens.
--
Paul Rubin schrieb:
André Thieme [EMAIL PROTECTED] writes:
And I didn't count the indentation level and \n in Python code.
Why should I? They are editor commands.
No they're part of Python syntax. A change in indent level is
recognized by Python's lexical scanner as a token and you should
André Thieme [EMAIL PROTECTED] writes:
How complicated ss it to say cmp(a, b) compared to a cmp b?
It gets worse when the expressions are nested.
So instead of
cmp(foo(a, b, c), bar(x, y, z)) you would prefer
foo(a, b, c) cmp bar(x, y, z) ?
Don't be silly. Some operators are more
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] wrote:
Don't be silly. Some operators are more natural as infix and others
as functions. It's just like in natural language. People have an
innate ability to make such distinctions and it's fine for a
programming language to
Kirk Sluder [EMAIL PROTECTED] writes:
Personally, I've always preferred use the imperative to describe
basic math rather than the passive. This would seem to map better to
RPN than infix.
For writing down complicated, nested expressions too? That's very
unusual. E.g.
n! = (n/e)**n *
Ken Tilton wrote:
McCarthy: Is code also data in Python?
Norvig: No.
I don't think that was the right answer. He should have
said Yes, and then shown McCarthy eval() and exec.
Code isn't quite as *convenient* to work with as data
in Python as it is in Lisp, but that doesn't mean it
can't be
greg wrote:
Ken Tilton wrote:
McCarthy: Is code also data in Python?
Norvig: No.
I don't think that was the right answer.
Norvig is a smart guy. He was talking to John McCarthy. He gave the
right answer. :)
He should have
said Yes, and then shown McCarthy eval() and exec.
No, in
Ken Tilton wrote:
I think your brain is stuck on flaming.
Sorry, I didn't mean to come across as flaming, far
from it. I'll take a deep breath before posting from
now on, I promise. :-)
I did explain the last little fun bit (where reverse code miraculously
got a case-specific signed-value
André Thieme wrote:
(aif (timeConsumingCalculation)
(use it))
I think the answer is that you just wouldn't do
that in Python at all. Having magic variables
spring into existence in your local namespace
as a side effect of calling something is just
not Pythonic. (It is very Perlish, on the
André Thieme wrote:
The thing with most (if not all) programming languages other than Lisp
is: these abstractions are leaky.
They have a low level knowledge leak. Users of aif need to know how to
pass in arguments. As you see he had do embed the code that needs execution
into a block (anon
André Thieme wrote:
So instead of
cmp(foo(a, b, c), bar(x, y, z)) you would prefer
foo(a, b, c) cmp bar(x, y, z) ?
Incidentally, someone once came up with an fiendishly
clever hack that lets you write things in Python like
foo(a, b, c) |kmp| bar(x, y, z)
i.e. effectively define your own
101 - 200 of 754 matches
Mail list logo
