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-
Re: globs and rules and trees, oh my! (was: Re: XPath grammars (Was: Re: globs and trees in Perl6))
Timothy S. Nelson wrote:
TimToady note to treematching folks: it is envisaged that signatures in
a rule will match nodes in a tree
My question is, how is this expected to work? Can someone give an
example?
I'm assuming that this relates to Jon Lang's comment about using
rules to match non-strings.
Pretty much - although there are some patterns that one might want to
use that can't adequately be expressed in this way - at least, not
without relaxing some of the constraints on signature definition.
Some examples:
A signature always anchors its positional parameters pattern to the
first and last positional parameters (analogous to having implicit '^'
and '$' markup at the start and end of a textual pattern), and does
not provide any sort of zero or more/one or more qualifiers, other
than a single tail-end slurpy list option. Its zero or one
qualifier is likewise constrained in that once you use an optional
positional, you're limited to optionals and slurpies from that point
on. This makes it difficult to set up a pattern that matches, e.g.,
any instance within the list of a string followed immediately by a
number.
The other issue that signatures-as-patterns doesn't handle very well
is that of capturing and returning matches. I suppose that this could
be handled, to a limited extent, by breaking the signature up into
several signatures joined together by ,, and then indicating which
sub-signatures are to be returned; but that doesn't work too well
once hierarchal arrangements are introduced.
Perhaps an approach more compatible with normal rules syntax might be
to introduce a series of xml-like tags:
[ ... ] lets you denote a nested list of patterns - analogous to
what [ ... ] does outside of rules. Within its reach, '^' and '$'
refer to just before the first element and just after the last
element, respectively. Otherwise, this works just like the list of
objects and/or strings patterns currently described in S05.
{ ... } does likewise with a nested hash of values, with standard
pair notation being used within in order to link key patterns to value
patterns. Since hashes are not ordered, '^' and '$' would be
meaningless within this context. Heck, order in general is
meaningless within this context.
item replaces elem as the object-based equivalent of '.' ('elem'
is too list-oriented of a term). I'd recommend doing this even if you
don't take either of the suggestions above.
You might even do a [[ ... ]] pairing to denote a list that is
nested perhaps more than one layer down. Or perhaps that could be
handled by using '[+' or the like.
But how would it be if I wanted to search a tree for all nodes
whose readonly attribute were true, and return an array of
those nodes?
This can already be done, for the most part:
/ (.does(ro)) /
Mind you, this only searches a list; to make it search a tree, you'd
need a drill-down subrule such as I outline above:
/ [* (.does(ro)) ]* /
--
Jonathan Dataweaver Lang
Re: XPath grammars (Was: Re: globs and trees in Perl6)
On Thu, 2 Oct 2008, Daniel Ruoso wrote: One thing we realized at that time is that XPath is good enough, even if it seems to be adressing XML specifically, it has the concept of dimension that can be extended to represent arbitrary aspects of objects. Hmm. Back in March, before I discovered that perl6 was actually far enough along to start using a bit, I wrote an article which includes information about what I do and don't like about XPath: http://computerstuff.jdarx.info/content/treepath-universal-tree-navigation-language It basically recommends that there be two path dialects, Complex TreePath (which is basically XPath) and Simple TreePath (which is basically a somewhat modified version of glob). Now that Perl6 is in the mix, though, I think that the best way to do it is to make roles that model eg. Nodes, Plexes (Documents), Elements, and the like, and then have operators on them do all the work (like my idea of using a slash for a combined feed and call code operator). I could be wrong, but it seems to me that we could get something that's somewhat like XPath this way, without having to worry about defining an XPath grammar or anything. :) - | 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-
Re: XPath grammars (Was: Re: globs and trees in Perl6)
On Thu, 2 Oct 2008, Timothy S. Nelson wrote: Now that Perl6 is in the mix, though, I think that the best way to do it is to make roles that model eg. Nodes, Plexes (Documents), Elements, and the like, and then have operators on them do all the work (like my idea of using a slash for a combined feed and call code operator). I could be wrong, but it seems to me that we could get something that's somewhat like XPath this way, without having to worry about defining an XPath grammar or anything. I'm talking to myself here :). 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 :). - | 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-
Re: XPath grammars (Was: Re: globs and trees in Perl6)
On Oct 2, 2008, at 10:36 , Timothy S. Nelson wrote: On Thu, 2 Oct 2008, Timothy S. Nelson wrote: Now that Perl6 is in the mix, though, I think that the best way to do it is to make roles that model eg. Nodes, Plexes (Documents), Elements, and the like, and then have operators on them do all the work (like my idea of using a slash for a combined feed and call code operator). I could be wrong, but it seems to me that we could get something that's somewhat like XPath this way, without having to worry about defining an XPath grammar or anything. I'm talking to myself here :). 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 :). I'm trying to find Trey to get his example, but I was under the pretty strong impression that rules could be treated as higher level entities in a pattern, thus allowing you to e.g. drill down into an XML document without needing to specify explicit paths. WHich is what I recall his example doing, -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: XPath grammars (Was: Re: globs and trees in Perl6)
For tree-oriented pattern matching syntax, I'd recommend for inspiration the RELAX NG Compact Syntax, rather than XPath. Technically, RELAX NG is an XML schema validation language; but the basic principle that it uses is to describe a tree-oriented pattern, and to consider the document to be valid if it matches the pattern. XPath, by contrast, isn't so much about pattern matching as it is about creating a tree-oriented addressing scheme. Also note that S05 includes an option near the end about matching elements of a list rather than characters of a string; IMHO, a robust structured data-oriented pattern-matching technology for perl6 ought to use that as a starting point. -- Jonathan Dataweaver Lang
XPath grammars (Was: Re: globs and trees in Perl6)
Qui, 2008-10-02 às 12:55 +0100, Tim Bunce escreveu:
Like applying XPath to an XML DOM, only more general and taken
further.
By more general and taken further I'm thinking of the same kind of
evoltion from simple regular expressions in perl5 to grammars in perl6.
An XPath query is like a perl5 regular expression.
During YAPC::EU::2007 (yeah... some time ago...) we had this discussion
motivated by the need to have something easier to transform parse
trees...
In that case, we were thinking about programming-language-translators
that would take the parse tree of one language, make some modifications
in the tree before emitting the other language (i.e.: turning specific
language dialects, for instance some uses of map and grep in perl5, to a
language that doesn't support map and grep, then turning that into a
different p5 construct that could be effectively translated to the
target language).
One thing we realized at that time is that XPath is good enough, even if
it seems to be adressing XML specifically, it has the concept of
dimension that can be extended to represent arbitrary aspects of
objects.
When we then take XQuery into account, we might have all the tools to
build an coherent tree-oriented Rule system.
xgrammar Foo {
xtoken bar {
'some XPath expression' subtoken
{ make 'some XQuery expression' }
}
xtoken subtoken {
'some other Xpath expression'
{ make 'yet another xquery expression' }
}
}
Of course we still need to think how to compose different xpath
expressions and how to make captures of it, but maybe XQuery already
solves that problem...
daniel
Re: XPath grammars (Was: Re: globs and trees in Perl6)
On Fri, 3 Oct 2008, Timothy S. Nelson wrote: On Thu, 2 Oct 2008, Timothy S. Nelson wrote: Now that Perl6 is in the mix, though, I think that the best way to do it is to make roles that model eg. Nodes, Plexes (Documents), Elements, and the like, and then have operators on them do all the work (like my idea of using a slash for a combined feed and call code operator). I could be wrong, but it seems to me that we could get something that's somewhat like XPath this way, without having to worry about defining an XPath grammar or anything. I'm talking to myself here :). 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 :). Talking to myself again. I'm not as convinced as I was. I'll write up a long post about that if necessary, but want to get something else figured out first. First, a paste from the IRC log: TimToady note to treematching folks: it is envisaged that signatures in a rule will match nodes in a tree My question is, how is this expected to work? Can someone give an example? :) - | 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-
globs and rules and trees, oh my! (was: Re: XPath grammars (Was: Re: globs and trees in Perl6))
On Fri, 3 Oct 2008, Timothy S. Nelson wrote:
On Fri, 3 Oct 2008, Timothy S. Nelson wrote:
On Thu, 2 Oct 2008, Timothy S. Nelson wrote:
Now that Perl6 is in the mix, though, I think that the best way to do
it is to make roles that model eg. Nodes, Plexes (Documents), Elements,
and the like, and then have operators on them do all the work (like my
idea of using a slash for a combined feed and call code operator). I
could be wrong, but it seems to me that we could get something that's
somewhat like XPath this way, without having to worry about defining an
XPath grammar or anything.
I'm talking to myself here :). 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 :).
Talking to myself again. I'm not as convinced as I was. I'll write
up a long post about that if necessary, but want to get something else
figured out first. First, a paste from the IRC log:
TimToady note to treematching folks: it is envisaged that signatures in a
rule will match nodes in a tree
My question is, how is this expected to work? Can someone give an
example?
I'm assuming that this relates to Jon Lang's comment about using rules
to match non-strings.
I'm starting to see how *matching* would work now. But how would it
be if I wanted to search a tree for all nodes whose readonly attribute were
true, and return an array of those nodes? Hmm. Or something like the
following XPath...
/html/body//p/[EMAIL PROTECTED] = #SampleName]
(my XPath isn't that great, but I'm assuming this will find all a tags
in the html body that are the direct descendant of a paragraph, and have their
@name attribute set to #SampleName). My guess is something like this:
$htmlobject = HTML-new();
$htmlobject.children()
== grep { /html/ } == map { .children() }
== grep { /body/ } == map { .children() }
== recursivegrep { /p/ } == map { .children() }
== grep { /a/ and .name eq #Samplename } == $anchors
I'm guessing that might do it (although the tree role and
recursivegrep would also require some work). But the syntax is dreadful :).
You can see why I was talking about having a feed operator that did a grep
and got children as well as doing the feed. But no doubt I'm missing
something here. And I'm still thinking like a Perl5 programmer :).
:)
-
| 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-
