Roy Smith wrote: > "Kay Schluehr" <[EMAIL PROTECTED]> wrote: > > > Roy Smith wrote: > > > > > foo->bar ==> foo.__arrrow__(bar) > > > foo$bar ==> foo.__dollar__(bar) > > > foo#bar ==> foo.__hash__(bar) > > > foo::bar ==> foo.__scope__(bar) > > > > I'm strongly in favor for the arrow ( but with two "r" only ). The > > question is simply: for what? > > I'm confused. You're strongly in favor of a piece of punctuation even > though you don't have any idea what it might be used for?
Shurely I was joking. I could imagine a few purposes most likely arrows of some category. That's what You depicted using the "==>" arrow, that translates some infix operator expression into it's method description. Arrows are some kind of 2-tuples that express a transition and which are "left-exact" i.e. there must be at most a right value to some left value. Example: (foo->bar) -> foo.__arrow__(bar) This is a recursive definition of the arrow which could be further expanded: ((foo->bar) -> foo.__arrow__(bar)) -> foo.__arrow__(bar).__arrow__(foo.__arrow__(bar)) etc. But something intrigues me and that is the prevalence of "foo" above "bar" i.e. the preimage above the image. I would like to see that one starts with the binary relation as the primary concept. A relation should be instantiated by two classes. Let be Rel(A,B) some relation created from classes A and B. The instances of Rel(A,B) would be arrows from A to B depicted as arrow diagrams: foo->bar -> rel.__arrow__(foo,bar) There is no absolute meaning of the arrow foo->bar, because it reflects only the particular relation instance rel. Besides this I guess Guido wants to use the arrow in the context of "optional static type declarations" for declaring the return type. I don't like this optional static stuff but the arrow is playing a role also in this proposal. Ciao, Kay -- http://mail.python.org/mailman/listinfo/python-list