On Sun, Jan 07, 2007 at 03:33:19AM -0800, Jonathan Lang wrote:
: IIRC, you don't even need .accepts for this. You could just say
:
: given $pattern {
:when $a ~~ $_ { ... }
:when $b ~~ $_ { ... }
:when $c ~~ $_ { ... }
: }
:
: ...since an explicit smart-match is a boolean expressio
Larry Wall wrote:
Lots of interesting ideas. But I don't think the reverse-test
situation will arise all that frequently. How 'bout we let the user
just say:
my macro statement_control: { "when .accepts: " }
or some such...
IIRC, you don't even need .accepts for this. You could just sa
Lots of interesting ideas. But I don't think the reverse-test
situation will arise all that frequently. How 'bout we let the user
just say:
my macro statement_control: { "when .accepts: " }
or some such...
Larry
On 1/5/07, Larry Wall <[EMAIL PROTECTED]> wrote:
Anyway, that gives us:
given $pattern {
when .accepts(42) {...}
}
I think this type of usage should be encouraged with a bit more
huffmanization. My first thought would be to add C to invert
the arguments to ~~ versus C.
given @
Larry Wall wrote:
Anyway, that gives us:
given $pattern {
when .accepts(42) {...}
}
which given typical usage patterns of switch statements is probably
adequately huffmanized, unless we want to go for something shorter
than accepts/rejects, like
acc/rej
pix/nix
ok
} or where => {...}. Selector is kind of
a stupid name in any event.
Anyway, that gives us:
given $pattern {
when .accepts(42) {...}
}
which given typical usage patterns of switch statements is probably
adequately huffmanized, unless we want to go for something shorter
than accepts/rejects,
two lines with Any on the right side. I want to remove
: these so that we can have an extensible ~~ operator.
:
: You can think of $x ~~ $y as saying "$x matches $y", i.e. $y is some
: data pattern and we are asking if $x conforms to it. I want to be
: able to add my own kinds of pat
have an extensible ~~ operator.
You can think of $x ~~ $y as saying "$x matches $y", i.e. $y is some
data pattern and we are asking if $x conforms to it. I want to be
able to add my own kinds of patterns, and entries with Any in the
right side undermine this.
Why? Let's say I cr
On Tue, Nov 22, 2005 at 09:31:27AM +0200, Gaal Yahas wrote:
: In pugs, r7961:
:
: my @pats = /1/, /2/;
: say "MATCH" if 1 ~~ any @pats; # MATCH
: say "MATCH" if 0 ~~ any @pats; # no match
:
: So far so good. But:
:
: my $junc = any @pats;
: say "MATCH" if 1 ~~ $junc; # n
HaloO,
Gaal Yahas wrote:
In pugs, r7961:
my @pats = /1/, /2/;
say "MATCH" if 1 ~~ any @pats; # MATCH
say "MATCH" if 0 ~~ any @pats; # no match
So far so good. But:
my $junc = any @pats;
say "MATCH" if 1 ~~ $junc; # no match
say "MATCH" if 0 ~~ $junc; # no match
In pugs, r7961:
my @pats = /1/, /2/;
say "MATCH" if 1 ~~ any @pats; # MATCH
say "MATCH" if 0 ~~ any @pats; # no match
So far so good. But:
my $junc = any @pats;
say "MATCH" if 1 ~~ $junc; # no match
say "MATCH" if 0 ~~ $junc; # no match
Bug? Feature?
--
Gaal Yaha
On 20/09/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> The basic idea is that, alongside Functor, you have a Zippable theory
> which defines:
>
> theory Zippable[::T] {
> multi zip (T[::A], T[::B] --> T[:(::A, ::B)]) {...}
> }
>
> Where that last coloney madness is a yet-to-be-prop
On 9/19/05, Luke Palmer <[EMAIL PROTECTED]> wrote
> Well, I've written up the details in a 40 line Haskell program to make
> sure it worked. I think I deleted the program, though.
Nope. Here it is. And it was 22 lines. :-)
http://svn.luqui.org/svn/misc/luke/work/code/haskell/hyper.hs
Luke
On 9/19/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> On 19/09/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Part 1: fmap
> >
> > I have a plan for the $x »+« $y form (and also foo(»$x«, »$y«, »$z«)),
> > but I don't want to go into that right now. It basically involves
> > zipping the structures
t;
> And the only thing that makes junctions different from Sets (which are
> also Functors) is their behavior in boolean context (and their ability
> to be Patterns; see below).
I think this is really nice: we get rid of invisible junction magic,
yet accessing that magic explicitly is on
function for each of its values and
reconstruct based on the return values. All in all, a Junction sounds
like a perfect candidate to be a Functor. Except all the fmapping is
implicit, which is what makes Junctions break the transitivity of <,
the orthogonality of the patterns "1"
--- Rod Adams <[EMAIL PROTECTED]> wrote:
> I was just relaying the observation that the P6RE was fairly close to
> being able to implement Logical Programming, which several people
> seem to be trying to get into Perl in some fashion or another.
When I get a chance to talk to someone about logic p
Larry Wall wrote:
I suspect it's another one of the many things we just try to
stay within hailing distance of without trying to solve for 6.0.0.
That's cool.
I was just relaying the observation that the P6RE was fairly close to
being able to implement Logical Programming, which several people
On Wed, Mar 09, 2005 at 08:56:22AM -0700, Luke Palmer wrote:
: I was decently insane last night. This generator stuff probably isn't
: going anywhere. It's too abstract, and not precise enough, to be a
: truly powerful part of the language.
I suspect it's another one of the many things we just t
Rod Adams writes:
> >
> >You could do all of this with a library of rules.
> >
> > / $:= )> /
> >
> >
> I don't think this does what I want. In this, &generate returns a rule
> or string of some kind, matches the string being tested, captures what
> matches, and then binds the capture to $.
Luke Palmer wrote:
Rod Adams writes:
Or you could avoid the global modifier and write your tests in <( )>
blocks instead... after all, that's what it's there for.
I *knew* I had seen a syntax for that before... I just didn't see it
when I scanned S05 for it.
I still want the :z modifier for
HaloO Luke,
you wrote:
[..] The *method* is the one that knows everything,
not the object. So definitions on subtypes of general types only check
for those subtypes when dispatching to the methods defined in them.
I stand corrected. Lax usage of Any is fair. Defining subtypes
of general types and
Thomas Sandlaà writes:
> Luke Palmer wrote:
> >But we always have enough knowledge to optimize the hell out of this,
> >and they're not not handwavy "we can probably" optimizations. They're
> >real, and they're pretty darn easy.
>
> I fully agree. But I like to add that a single 'where' on genera
/ $:= )> /
How the rule is actually written is getting into some rule
engine internal stuff, but we're making sure that the rule engine has
enough hooks to do that.
I think you'll be interested in where my 'Argument Patterns' proposal
was going next, before I ran off
Luke Palmer wrote:
But we always have enough knowledge to optimize the hell out of this,
and they're not not handwavy "we can probably" optimizations. They're
real, and they're pretty darn easy.
I fully agree. But I like to add that a single 'where' on general
types like Int, Str or even Any can s
Leopold Toetsch writes:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > I think we should replace our multimethod system with a more general
> > pattern matcher, a "variadic multimethod" system of sorts. Multimethods
> > need to be variadic anyway, because we want pugs's quicksort example to
> > w
Luke Palmer <[EMAIL PROTECTED]> wrote:
> I think we should replace our multimethod system with a more general
> pattern matcher, a "variadic multimethod" system of sorts. Multimethods
> need to be variadic anyway, because we want pugs's quicksort example to
> work.
I'd not say replace. The dispa
Autrijus Tang wrote:
On Tue, Mar 08, 2005 at 04:55:28PM -0600, Rod Adams wrote:
I thought Larry already declared that we are not making Perl act like ML
(yet).
And that was re: type inferencing, not re: pattern matching. :)
Thanks,
/Autrijus/
Sorry about that. Comcast has decided I only
On Tue, Mar 08, 2005 at 04:55:28PM -0600, Rod Adams wrote:
> I thought Larry already declared that we are not making Perl act like ML
> (yet).
And that was re: type inferencing, not re: pattern matching. :)
Thanks,
/Autrijus/
pgp3tE8H37UB0.pgp
Description: PGP signature
We can now define 'equal':
sub equal ($x, $x) { 1 }
sub equal ($x, $y) { "" }
That's one of the MTOWs at least. The evaluation order of the patterns
still needs to be thought out.
I thought Larry already declared that we are not making Perl act like ML
(yet).
-- Rod Adams
x27;equal':
sub equal ($x, $x) { 1 }
sub equal ($x, $y) { "" }
That's one of the MTOWs at least. The evaluation order of the patterns
still needs to be thought out.
There are more types of patterns. Types are patterns, and from this we
see that following a pattern by
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
[extremely large *SNIP*]
> Maybe the "|"/"||" distinction isn't needed, and we just need a
> declarator on rules that says they are side-effect-free, and can thus
> be optimized.
[snip]
> I like this solution better than making a new operator. In Perl
>
> --- "Adam D. Lopresto" <[EMAIL PROTECTED]> wrote:
> > I propose that since the empty pattern is no longer legal (and
> > about time), we use "|" in patterns to indicate alternation without
> > preference, and "||" to indicate "try the
--- "Adam D. Lopresto" <[EMAIL PROTECTED]> wrote:
> I propose that since the empty pattern is no longer legal (and
> about time), we use "|" in patterns to indicate alternation without
> preference, and "||" to indicate "try the first, then the
build an
implementation that, for instance, has no preference among alternatives.
I propose that since the empty pattern is no longer legal (and about
time), we use "|" in patterns to indicate alternation without
preference, and "||" to indicate "try the first, then the
Steve Tolkin wrote:
> { @$appendline =~ s//
> I think this needs a backslash in front of the < symbol, and a space
> after in_marker, i.e. it should be:
>
> { @$appendline =~ s//\
re is this code:
{ @$appendline =~ s///\</;
That a small issue. But the following is more
important because it strikes at the ease of
using inheritance of grammars (i.e. patterns).
In
http://www.perl.com/pub/a/2002/08/22/exegesis5.html?page=5#different_diffs
we see the code:
rule fileinfo {
37 matches
Mail list logo
