Re: Signatures and matching (was Re: XPath grammars (Was: Re: globs and trees in Perl6))
HaloO,
David Green wrote:
On 2008-Oct-22, at 10:03 am, TSa wrote:
Note that types have a fundamentally different task in a signature
than name and position have. The latter are for binding arguments to
parameters. The types however are for selection of dispatch target.
Names do that too; I think both names and types should be available for
both binding and dispatching, depending on what's more natural in a
given context. Sometimes we think in terms of names (I'm going to
Fred's place), sometimes in terms of types (I'm going to the grocery
store). (And some types are names (Dad)!)
I meant that only types are checked for specificity. In the first
stage of the dispatch when applicability is checked the named params
play a role, of course. But I've no idea how a named binding compares
to a typed positional one.
multi sub action (Hammer $hammer, Nail $nail) {...}
multi sub action (SledgeHammer $hammer;; Any :$object) {...}
How would these compare if we assume that SledgeHammer is more specific
than Hammer? Would the named param of the second sub be silently
promoted to positional?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Signatures and matching (was Re: XPath grammars (Was: Re: globs and trees in Perl6))
On 2008-Oct-22, at 10:03 am, TSa wrote: David Green wrote: One thing I would like signatures to be able to do, though, is assign parameters by type. Much like a rule can look for identifiable objects like a block or ident, it would be very useful to look for parameters by their type or class rather than by name (or position). Note that types have a fundamentally different task in a signature than name and position have. The latter are for binding arguments to parameters. The types however are for selection of dispatch target. Names do that too; I think both names and types should be available for both binding and dispatching, depending on what's more natural in a given context. Sometimes we think in terms of names (I'm going to Fred's place), sometimes in terms of types (I'm going to the grocery store). (And some types are names (Dad)!) In single dispatch it is very important if your dispatch is handled in the Nail or Hammer class. In multi dispatch one can still distinguish action:(Hammer,Nail) from action:(Nail,Hammer). There is the following syntax to define two sigs for the same body multi method action (Hammer $hammer, Nail $nail) |(Nail $nail, Hammer $hammer) Sneaky, I hadn't thought of doing it that way. Of course, a mere five objects give you an unwieldy 120 possibilities, so some syntactic relief is called for. Perhaps something like an to indicate that the parameters are not sequential: sub foo ($posn0, $posn1, Bar $type1 Baz $type2 Bat $type3, : $named1, :$named2) -David
Re: Signatures and matching (was Re: XPath grammars (Was: Re: globs and trees in Perl6))
The scrap your boilerplate scheme for generics in Haskell addresses traversals, queries, transformations, parallel zipping and the like. I've only briefly felt like I understood it, so I was going to revise before trying to adapt it to Perl 6. (Any lambdacamels out there that do understand this stuff?) There's a paper called Scrap your boilerplate with XPath-like combinators http://homepages.cwi.nl/~ralf/popl07/ which ties nicely into this thread. It and other SYB papers provide a useful perspective on this traversal and matching domain, even if the Haskell details are tricky. SYB home: http://www.cs.vu.nl/boilerplate/ Brad -- ... One should think well then speak. ... -- Hagakure
Signatures and matching (was Re: XPath grammars (Was: Re: globs and trees in Perl6))
On 2008-Oct-2, at 6:15 pm, Timothy S. Nelson wrote: The guys on IRC convinced me that the way to go might be something like a grammar, but that does trees and tree transformations instead of a text input stream. See the IRC log for details :). [...] TimToady note to treematching folks: it is envisaged that signatures in a rule will match nodes in a tree There does seem to be a clever idea waiting to happen here, although I expect signatures will be somewhat simpler since they are intended for a more specific purpose. One thing I would like signatures to be able to do, though, is assign parameters by type. Much like a rule can look for identifiable objects like a block or ident, it would be very useful to look for parameters by their type or class rather than by name (or position). For example, if I ask you to hand me a hammer and a nail, I don't need you to hand them to me in a specific order, or with labels attached like a Dick Tracy comic, in order to know which is which. That's obvious, because, well, one is a hammer and one is a nail. If I'm writing OO-code, then Perl also knows what's a Tool::Hammer and what's a Fastener::Nail -- if I know that my $tool is a hammer, and Perl knows, then I shouldn't have to spell it out. The :$foo shortcut for :foo($foo) addresses the same problem, but in terms of naming; it is reasonable that a Foo object would be named $foo in both the caller and the sub, but not necessary. Being able to use class info that's already there would make it easy to grab params when I know the type of object I'm looking for, but not what it's called. -David
Re: Signatures and matching (was Re: XPath grammars (Was: Re: globs and trees in Perl6))
On Tue, 21 Oct 2008, David Green wrote: On 2008-Oct-2, at 6:15 pm, Timothy S. Nelson wrote: The guys on IRC convinced me that the way to go might be something like a grammar, but that does trees and tree transformations instead of a text input stream. See the IRC log for details :). [...] TimToady note to treematching folks: it is envisaged that signatures in a rule will match nodes in a tree There does seem to be a clever idea waiting to happen here, although I expect signatures will be somewhat simpler since they are intended for a more specific purpose. One thing I would like signatures to be able to do, though, is assign parameters by type. Much like a rule can look for identifiable objects like a block or ident, it would be very useful to look for parameters by their type or class rather than by name (or position). For example, if I ask you to hand me a hammer and a nail, I don't need you to hand them to me in a specific order, or with labels attached like a Dick Tracy comic, in order to know which is which. That's obvious, because, well, one is a hammer and one is a nail. If I'm writing OO-code, then Perl also knows what's a Tool::Hammer and what's a Fastener::Nail -- if I know that my $tool is a hammer, and Perl knows, then I shouldn't have to spell it out. XPath does this by default, and XPath is what I'd want to model any tree-based stuff on, because it has a pretty comprehensive tree model. But having said that, I'm not sure that I want to do it by default. It'd certainly be an option, though. The :$foo shortcut for :foo($foo) addresses the same problem, but in terms of naming; it is reasonable that a Foo object would be named $foo in both the caller and the sub, but not necessary. Being able to use class info that's already there would make it easy to grab params when I know the type of object I'm looking for, but not what it's called. I admit to not understanding enough Perl6 to be able to understand what you're getting at here, but no doubt I will. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: [EMAIL PROTECTED]| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
