Pisin Bootvong wrote:
> Joe Marshall wrote:
>
>>Alex Martelli wrote:
>>Most languages allow `unnamed numbers'. The `VAT_MULTIPLIER' argument
>>is a
>>strawman. Would you want to have to use a special syntax to name the
>>increment
>>in loop?
>>
>> defnumber zero 0
>> defnumber one { successor (zero); }
>>
>> for (int i = zero; i < limit; i += one) { ...}
>>
>>If you language allows unnamed integers, unnamed strings, unnamed
>>characters, unnamed arrays or aggregates, unnamed floats, unnamed
>>expressions, unnamed statements, unnamed argument lists, etc. why
>>*require* a name for trivial functions?
>>Wouldn't all the other constructs benefit by having a required name as
>>well?
>>
>
>
> Is this a Slippery Slope fallacious argument?
> (http://c2.com/cgi/wiki?SlipperySlope)
>
> "if python required you to name every function then soon it will
> require you to name every number, every string, every immediate result,
> etc. And we know that is bad. Therefore requiring you to name your
> function is bad!!!! So Python is bad!!!!"
>
>
> How about:
>
> If Common Lisp lets you use unnamed function, then soon everyone will
> start not naming their function. Then soon they will start not naming
> their variable, not naming their magic number, not naming any of their
> class, not naming any function, and then all Common Lisp program will
> become one big mess. And we know that is bad. So allowing unnamed
> function is bad!!!! So Common Lisp is bad!!!!!
Funny you should mention that. Cells (obviously) have turned out to be a
gold mine for me in terms of development. And they have exactly one
non-limiting limitation: once you start using them, you have to use them
almost everywhere, because they create a different dataflow, or better
put, the dataflow replaces the control flow of imperative programming,
so there is no way to add a little subsection of functionality with
imperative code because all the action is over in dataflow-land.
I call it non-limiting because it is more like a healthy discipline: as
a consequence, all application semantics end up expressed as so many
discrete little cell rules. Which brings me to the punch line...
try to debug an app where all the code is in anonymous functions!!!
well, it was not a complete disaster because by hook or by crook one
could figure out which rule was at fault even in the worst case, and
most of the time there was not much question. But still...
well, it took me embarrasingly long to notice something. I never
actually coded (lambda (self) yada yada) for a rule. I always used a
macro: (c? yada yada)
This was great because it is more succinct and because once I had a
couple hundred of these i had little problem making serious overhauls to
the implementation. And of course if you know Lisp and macros...
duhhhhh! They operate on the code! So in two seconds I added a new slot
to a Cell called "code", and part of the macro expansion was to stuff
the source code into the code slot. ie...
The code: (c? (yada yada yada))
Becomes:
(make-c-dependent
:code '((yada yada yada))
:value-state :unevaluated
:rule (c-lambda (yada yada yada)))
c-lambda? I have a few of those c? macros, so I "submacro" the necessary
lambda form:
(lambda (slot-c &aux (self (c-model slot-c)) (.cache (c-value slot-c)))
(declare (ignorable .cache self))
(yada yada yada))
I almost never have to look at that code slot (as I said, most of the
time I can tell from the instance class and the slot name which rule I
screwed up) but when I am stumped, I just inspect the source code. :)
Oh, wait, this is not the "Should Python have macros" thread, is it?
:)
kenny
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
--
http://mail.python.org/mailman/listinfo/python-list
