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:test { when .accepts: }
or some such...
IIRC, you don't even need .accepts for this. You could just
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
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
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 Cagainst to invert
the arguments to ~~ versus
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 created a pattern
:
: These are the 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 patterns
= {...}. 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, like
acc
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
Bug?
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; # no
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 Yahas
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-proposed tuple
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 only one or two characters
away. Being able to pass junctions around as values (safely) is a nice
bonus too.
Stuart
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 up into tuples
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
, 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 and 2, and all that other
stuff that people like me covet so.
So my proposal is to make a Junction into a plain
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 dispatcher
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
work.
I'd
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
be interested in where my 'Argument Patterns' proposal
was going next, before I ran off to class (and got scared of posting it,
because people would get scared of me). But it seems to be related to
what you're talking about. Maybe we could unify the pattern proposal
and your generation ideas
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 general
types
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
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
Rod Adams writes:
You could do all of this with a library of rules.
/ $x:=generate(@values) test($x) /
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
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
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
--- 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
, $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 a variable binds the variable to
whatever matched
':
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
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
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
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 second, etc.
So
cat dog fox ~~ /( fox
--- 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 second,
etc.
Hmm
A neat idea, but can you elaborate
--- 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
tradition,
Steve Tolkin wrote:
{ $appendline =~ s/in_marker//;
I think this needs a backslash in front of the symbol, and a space
after in_marker, i.e. it should be:
{ $appendline =~ s/in_marker/\sp/;
Isn't the replacement part of a substitution is still a string?
Having the replacement
(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 {
out_marker3 $oldfile:=(\S+) $olddate:=[\h* (\N+?) \h*?] \n
in_marker3 $newfile:=(\S+) $newdate:=[\h* (\N+?) \h*?] \n
}
rule out_marker
35 matches
Mail list logo
