[I trimmed some of the newsgroups away; this mostly concerns Python and Lisp]
Ken Tilton <[EMAIL PROTECTED]> writes:
> Lasse Rasinen wrote:
> > Ken Tilton <[EMAIL PROTECTED]> writes:
> >
> >>>if any concepts have survived to the Python version. Since Python's object
> >>>model is sufficiently different, the system is based on rules being
> >>>defined per-class...
> >>
> >>That will be a total disaster for PyCells, if true. But I do not think it
> >>is. You just need a constructor that takes some slot initializers, and
> >>initialize the slots to one of: a normal value; an InputCell itself
> >>initialized with a starting value, if only nil; or a RuledCell itself
> >>initialized with a lambda.
> > Hmm, just tried it:
> >
> > [snip example]
> >
> > So it does work out-of-the-box ;-)
>
> So why exactly did you say that the differences in the object model made
> it impossible? I was really stunned by that claim. And you sounded so
> confident. What went wrong there? It was trivial, right? How did you miss
> that?
Simple: I didn't think to try that before you asked.
I did not say the differences in the object model made it impossible, I
said the system is based on rules defined per-class. My goal was to
explore the how one would go about defining data flow in Python, which is
why I concentrated on class-level definitions first.
The situation is similar to functions in classes. Normally you'd define
them like this:
class X:
def function(self, ...):
...
However, you can just as well set them, even on per instance basis:
x = X()
x.another_function = lambda self, x: return x+2
I also think(*) that while one would have the option to define
per-instance rules, in a Python implementation one would structure the
code so that common rules would be class-related, and the per-instance
rules would be used less frequently, used only when you absolutely need
them.
(*) Unfounded Gut Feeling(TM); if your project is successful, we can
revisit this prediction in September ;-)
> >>PyCells looks like it will be a project for SoC2006, so you may as well
> >>relax.
> > You really want to start a SoC project on something that takes about two
> > weeks ...
>
> You sound so confident. :)
Indeed. Having reread the post I do think the tone was possibly a tad
arrogant. However:
> A new test suite, documentation (a first, there is none now), a full port
> of Cells in all their ten years of sophisticated evolution and variety
> (no, not your stupid pet trick), and as a demo project an entire
> cells-driven GUI, probably a port of my new Celtk (+ Cells Tk) work, all
> in a language without macros, without special variables, with a more
> modest OO system, and limited first class functions... oh, I think we'll
> keep him busy. :)
I did not know all this. The list above does sound like a full summer of
work ;)
I assumed that PyCells referred to the core dependency tracking module
which (even now) does not sound like a such huge task, especially when one
has the reference implementation ;-)
As I said above, I was mostly concerned with exploring how the data flow
system would work, so I haven't implemented the various different types of
cells in Cells. So there would obviously be a bit more work if one is
implementing all that, but still, two caffeine and youth powered student
weeks can achieve a lot ;-)
What "your stupid pet trick" would be referring to? The use of the
__getattribute__ method (which is quite close to SLOT-VALUE-USING-CLASS),
or the use of @decorator syntax to reduce typing and redundancy?
> Now since you are such a genius, maybe you can help with something. Trust
> me on this: this is one place where macros would be able to hide a ton of
> implementation wiring it does no one any good to look at, and actually
> turns into a maintenance nightmare whenever Cells might get revised.
I'd probably use decorators a lot, since they let you play around with
function objects. If they are suitably chosen and designed, the interface
should stay pretty stable even while the wiring is changed.
(Decorator background:
The regular python Python function definition would be
as follows:
def foo(x,y,z):
...
would be in CL (if CL were Lisp-1 with symbol-function-or-value) more or less:
(setf (symbol-function-or-value 'foo) (lambda (x y z) ...)
The decorated syntax would be:
@magic_decorator
def foo(x,y,z):
...
and the translation:
(setf (symbol-function-or-value 'foo)
(funcall magic-decorator #'(lambda (x y z)
...)))
)
--
Lasse Rasinen
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
