Re: Short-circuiting user-defined operators
Is there any specific reason this was a reply to Michael Lazarro's "Re: == vs. eq" dated Tue, 1 Apr 2003 16:30:00 -0800 ? (What I mean is, PLEASE don't use reply when you're not replying at all) -- Matthijs van Duin -- May the Forth be with you!
Re: Conditional Cs?
On Tue, 1 Apr 2003 22:01:48 +0300, arcadi shehter wrote:
> Damian Conway writes:
> >given baz(@args) { return $_ when defined }
> >given baz(@args) { return $_ when $_ > 0 }
> ># etc.
>
> since we have 2 forms of "return" -- "return" and "leave" , may be we
> can make "return" also to be a topicalizer for the rest of experssion
> , and then :
>
> return baz(@args) when $_ > 0 ;
> return baz(@args) when defined ;
> return baz(@args) when true ;
Damian's solution looks a lot better to me. I'm going to be surprised by the
behaviour of code that works like yours for a long time before I get used to
it.
--
Peter Haworth [EMAIL PROTECTED]
"I have to continue using UUCP for sentimental reasons"
-- Ian Lance Taylor
Re: == vs. eq
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> One thing we should clear up is that we already *have* a generic
> comparator, C<~~>, depending on what you mean by "generic". It can
> be
> made to compare things however you like, according to whatever
> standard
> of similarness you decide you want to enforce, and can even compare
> objects of disparate types (if you tell it how.)
>
> The way I personally have been envisioning this working is:
>
> $a == $b; # compares numerifications of $a and $b
> $a eq $b; # compares stringifications of $a and $b
> $a ~~ $b; # tests equality of $a and $b
> $a =:= $b; # tests identity of $a and $b
>
> Of these, I would expect that ==, eq, and =:= would almost never be
> overloaded, because they have very specific meanings.[*]
>
> You _could_ choose to override those == and eq for a particular
> custom
> class, and use those for comparing equality of objects. But since
> some
> people will tend to want to override ==, and some will want to
> override
> eq, it's not clear that the Perl6 community will converge on using
> only
> one or the other, which might make things quite confusing if you're
> using a library that has standardized on the opposite convention from
>
> your own.
>
> ~~, on the other hand, is meant to be overloaded to a
> possibly-excruciating extent, and I've been assuming that it will be
> the thing that classes most often overload when they want to test
> "equality" of two arbitrary objects, without resorting to serializing
>
> them via num/str. (Using num/str comparisions to test for object
> equality obviously only works if num/stringifying _completely_
> serializes the object -- which very often is _not_ what you want the
> num/stringification of an object to do, by default.)
>
> The proposed =:=, however, merely tests that two objects are
> identical
> -- that is, _that they are bound to the same underlying thing_. It's
>
> possible for two objects to be equal, ~~wise, without actually being
> identical, identitywise. I don't see ever wanting to overload =:=,
> and
> it's unclear if it should even be allowed.
It has been pointed out once already that we already talked about this,
and I for one am in favor of the general version of it.
The original discussion posited an "adverbial comparison", viz:
C<$a eq:ref $b>. Which, looking at your proposal, is very close to
C<$a =:= $b>, because I'm reading that as "equals, under assignment".
Likewise, I could argue that it be called C<=:\> (the "disgruntled
muppet" operator?) since that reflects the "equals, under reference"
symbology. But that's yucky.
So: I believe that adverbial comparisons are desirable, and in fact
believe that arbitrary-sub comparisons are desirable, provided they
don't cost much.
sub budgetwise(Int $a, Int $b) { -1_000_000 <= $a - $b <= 1_000_000; }
my Int $log_rolling, Int $pork_barrel;
$log_rolling = random() * 1.0E9;
$pork_barrel = random() * 1.0E9;
if ($log_rolling eq:budgetwise $pork_barrel)
print "They cost the same, give or take a million dollars.";
> Note also that == and eq comparisions are naturally accompanied by
> greater-than, less-than variants. But ~~ and =:= don't really have
> those variants, because they wouldn't make much sense.
Even inverted comparisons are suspect in junctionville.
> Having said all that, it should be noted that I'm completely making
> this stuff up.
Finest kind.
Re: Ruminating RFC 93- alphabet-blind pattern matching
--- Yary Hluchan <[EMAIL PROTECTED]> wrote:
> A couple nights ago I read RFC93 as discussed in Apoc. 5 and got
> fired up- it reminded me of some ideas from when I was hacking
> Henry Spencer's regexp package. How to futher generalize regular
> expression input. It's a bit orthoginal- a properly implemented
> RFC93 make some difficult things easier- whether it's done as
> binding to a sub, or as overloading =~, or whatever.
>
> A very general description of a regular expression, is a program
> that seeks a match within a string of letters. In perl4 the string
> of letters was a string of bytes, and in perl6 it's a string of
> Unicode (most of the time).
>
> It might as well be a string of *anythings*. Binding a match against
> a sub is a natural way to get the anythings you want to match. Now,
> I'm a newbie to perl6, so be patient with my hacked-up examples
> below.
> They won't work in any language. And, for the first I tweaked RFC93:
>
> When the match is finished, the subroutine would be called one
> final
> time, and passed >1 arguments: a flag set to 1, and a list
> containing
> the "unused" elements
>
> which I admit is a poor interface- but it lets me write:
>
> # Looking for luck- find a run of 3 numbers divisible by 7 or 13
> # "sub numerology" is simply an interface to an array of integers
> sub numerology { $#_ ? shift,unshift @::nums,@_ : splice
> @::nums,0,@_ }
> &numerology =~ / <( !($_[0] % 7 and $_[0] % 13) )><3> /;
>
grammar Numerology;
rule number { \b \d+ \b }
rule lucky {
{ fail unless ($1 % 7 == 0) && ($1 % 13 == 0); }
}
rule lucky_strike { :3x } ## Is this right?
> True, it's easy to join integers with spaces and write an equivalent
> regexp on the result- but why stringify when you don't have to?
>
> I'm running into trouble here- using <( code )> to match against a
> single "atom" (a number), it should be more "character classy".
> Assertions are flexible enough to match all sorts of non-letter
> atoms, can write a grammer to make it more readable- maybe something
> like
> &numerology =~ / < ><3> /;
Actually, this is a good argument for nested rules, and thereby for
nested subs:
my &numerology = rx/
rule number { \b \d+ \b }
rule divisible($by) { () :: { fail if ($1 % $by); }}
:x3
/;
> Another example. Let's say there's a class that deals with colors.
> It has an operator that returns true if two colors look about the
> same. Given a list of color objects, is there a regexp to find a
> rainbow? Even if the color class doesn't support stringification?
Yes.
grammar Rainbow;
rule color {...}; # this one's on you.
rule same_color($color is Colorific)
{
::: { fail unless $1.looks_like($color); }
}
rule band($color is Colorific)
{
+
}
rule Rainbow
{
?
}
> A less fanciful example- scan a sound. A very crude beat-finding
> regexp-
> &fetch_sound_frames =~
> / ( # store soundclip (array of frames)
> in $1
> (<50,1500>) # quietish section, 50-1500 frames
> (+) # Followed by some loud frame(s)
> ) # End capture of the first beat
>
> repeats,
> [ # but don't require the exact same
> frames
> <$2.length*.95,$2.length*1.05>
> <$3.length*.95,$3.length*1.05>
> ]{3}
> >
> /
>
You're just about there. Only the syntax needs work.
http://dev.perl.org/perl6/exegesis/5
> The point I'm trying to make:
> A regexp is already able to consume diffent kinds of characters from
> a
> string- :u0, :u1, :u2, :u3- and with RFC93 it can be fed anything a
> sub
> can return. Those things can be characters- or strings- or
> stringified if
> the regexp requires- but if the regexp doesn't have any strings to
> match
> against, don't bother. Let the assertions get the atoms raw.
>
> Plenty of brilliance on this list, I know I'm not brilliant,
> especially
> when drowsy... did some research before posting but if this has been
> covered already (or is completely daft) please face me in the right
> direction and shoo me along gently.
What I think you're looking for is the fact that they're not regexes
any more. They are "rexen", but in horrifying-secret-reality, what has
happened is that Larry's decided to move Fortran out of core, and
replace it with yacc.
It's funny, but I try to describe this to people (gently) and they
immediately fall into three classes:
People who never got it, regex-wise, just kind of screw up their faces
and say "Huh?"
People (a very small number) who go "Oh. Cool!" and their eyes light
up.
And finally the majority of coders, who look as though they opened a
door expecting to find a bookstore, and instead a 250-pound tuna fell
on them.
> -y
=Austin
Re: == vs. eq
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> Likewise, I could argue that it be called C<=:\> (the "disgruntled
> muppet" operator?) since that reflects the "equals, under reference"
> symbology. But that's yucky.
Shouldn't that be ==:/ (maybe the "severely startled muppet" operator?
lol...) A single = would be assignment, but I have no idea how
adverbial modification would affect that. Exactly what *would*
adverbial assignment be? Would
$a =:\ $b
be like
$a = \$b;
> sub budgetwise(Int $a, Int $b){-1_000_000 <= $a - $b <= 1_000_000;}
> my Int $log_rolling, Int $pork_barrel;
> $log_rolling = random() * 1.0E9;
> $pork_barrel = random() * 1.0E9;
> if ($log_rolling eq:budgetwise $pork_barrel)
> print "They cost the same, give or take a million dollars.";
Is that saying to make budgetwise the comparison operator at the same
precedence as eq?
Wouldn't that be much like saying
my sub infix:um (Int $a, Int $b) is equiv(&infix:eq) { # c.f.A6 p.11
-1_000_000 <= $a - $b <= 1_000_000; }
if ($log_rolling um $pork_barrel) # etc
So how does one get a ref in P6 that won't dereference itself???
The we could say
my sub infix:embodies ($a,$b) is equiv(&infix:eq) {
$a.ref eq $b.ref # unless eq deref's even here.
}
if ($x embodies $y) {
print "X and Y refer to the same entity\n";
}
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: Ruminating RFC 93- alphabet-blind pattern matching
> "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
AH> grammar Rainbow;
AH> rule color {...}; # this one's on you.
AH> rule same_color($color is Colorific)
AH> {
AH>::: { fail unless $1.looks_like($color); }
AH> }
AH> rule band($color is Colorific)
AH> {
AH> +
AH> }
AH> rule Rainbow
AH> {
AH>
AH>
AH>
AH>
AH>
AH>
AH>
AH> ?
AH> }
for the p6 regex impaired among us, please explain that. it might make a
nice tute for the docs. i get the general picture but i don't follow how
it works regarding the color checking.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: == vs. eq
--- Paul <[EMAIL PROTECTED]> wrote:
>
> --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > Likewise, I could argue that it be called C<=:\> (the "disgruntled
> > muppet" operator?) since that reflects the "equals, under
> reference"
> > symbology. But that's yucky.
>
> Shouldn't that be ==:/ (maybe the "severely startled muppet"
> operator?
> lol...) A single = would be assignment, but I have no idea how
> adverbial modification would affect that. Exactly what *would*
> adverbial assignment be? Would
> $a =:\ $b
> be like
> $a = \$b;
>
> > sub budgetwise(Int $a, Int $b){-1_000_000 <= $a - $b <= 1_000_000;}
> > my Int $log_rolling, Int $pork_barrel;
> > $log_rolling = random() * 1.0E9;
> > $pork_barrel = random() * 1.0E9;
> > if ($log_rolling eq:budgetwise $pork_barrel)
> > print "They cost the same, give or take a million dollars.";
>
> Is that saying to make budgetwise the comparison operator at the same
> precedence as eq?
Actually, what I think I'm saying in this case is "replace the do()
behavior of infix:eq with this sub."
Which has kind of startling effects, because then you can also say
things like this:
sub uniquely(@dest is rw, @src)
{
my $last = @src[0] ~ "1";
for @src -> $s
{
@dest.push($last = $s) unless $s == $last;
}
}
my @a = <>; # Read all lines from a file.
my @b =:uniquely @a;# Eat the duplicates
>
> Wouldn't that be much like saying
>
> my sub infix:um (Int $a, Int $b) is equiv(&infix:eq) { # c.f.A6
> p.11
> -1_000_000 <= $a - $b <= 1_000_000; }
> if ($log_rolling um $pork_barrel) # etc
Looks right to me, modulo type-casting behavior -- I think yours does
typechecking and blows up if the types are misaligned enough, while
mine finds the right infix:= operator, and replaces the actual
mechanics. (Frankly, I'm not sure what the right behavior of mine is.
It may be better to think of it as "temporizing" the infix:= operator
for one expression only. More thought required.)
> So how does one get a ref in P6 that won't dereference itself???
No idea. I thought that the auto-da-fe^Wautodereference behavior was
intended to make "loose references" impossible -- that is, you have to
treat a reference object as an object, always. (Which just means more
backslashes, I guess.)
> The we could say
>
> my sub infix:embodies ($a,$b) is equiv(&infix:eq) {
> $a.ref eq $b.ref # unless eq deref's even here.
> }
Maybe you just have to say C<\$a eq \$b> ?
>
> if ($x embodies $y) {
> print "X and Y refer to the same entity\n";
> }
>
=Austin
Re: Ruminating RFC 93- alphabet-blind pattern matching
I'm reordering this post rather than retype stuff. Forgive me.
--- Uri Guttman <[EMAIL PROTECTED]> wrote:
> for the p6 regex impaired among us, please explain that. it might
> make a nice tute for the docs. i get the general picture but i don't
> follow how it works regarding the color checking.
Of course, the color checking is the part that I messed up. See below.
> > "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
>
Disclaimer: I'm *SO* clueless about this stuff...
> AH> grammar Rainbow;
>
> AH> rule color {...}; # this one's on you.
Yary posited a color class, so I accept that he can recognize them. I
called it Colorific, just because. So my first mistake was probably
failure-to-declare:
grammar Rainbow;
use Colorific; # Import C and C, among others.
What I don't know is how to recognize a color, which is to say I don't
know how to write the rule -- because I don't know what this is
being applied to. Is this reading pixels, interpreting the results of
radio telescopy, or consuming Lucky Charms breakfast cereal bits? I
don't know, so I'm just going to assume that Yary can write that for me
-- it's his class, after all.
And the Colorific class supposedly has a way to determine if two colors
look about like each other. Again, I don't know how that works, but I
don't need to.
> AH> rule same_color($color is Colorific)
> AH> {
> AH>::: { fail unless $1.looks_like($color); }
> AH> }
This is really probably bad code. Maybe a better rule would be:
rule same_color($color is Colorific)
{
::: { fail unless $color.looks_like($1); }
}
I KNOW that $color is an object-of-type-Colorific, while I'm not sure,
frankly, what is returning. Let Colorific handle that.
Also, please note that the only reason that C is a separate
rule is because I haven't learned, yet, how to do that in one amazing
line of P6 code. I suspect that it could have been written all inside
the C rule, if I were smarter.
> AH> rule band($color is Colorific)
> AH> {
> AH> +
> AH> }
Here, I'm just saying that a 'band' of the rainbow is made up of
at-least-one-maybe-more bit of a color that looks like $color.
So, for a "color band" of, say, red, I'll take red and require that
there be a bunch of stuff that looks like red, using the same_color
rule (that, in turn, uses the Colorific::looks_like function, which
someone else wrote).
But that's the key: once I know how to recognize a band of color, I can
look up my old ROY G. BIV mnemonic from Astronomy (or what that
electronics? Too many dead brain cells:- I apologize if my rainbow is
actually a RadioShack-bow.)
So I need to declare what a Rainbow looks like. I'll use my band
"shortcut" to specify the seven different colors.
Note that rexen / rules are declarative, not imperative. The lines are
each pattern-invocations, and there aren't any semicolons. If I want
procedural, I need to open a sub-block to drop into "perl command
mode", like I did in the C rule, above.
Since there's no alternation(|) or grouping or anything here, these
declarations are straight-line: they all apply, one after the other.
So a Rainbow is recognized when there's a
band-of-red followed immediately by a
band-of-orange followed immediately by a
...
band-of-violet.
Then, if you're lucky, there might be a pot-o-gold at the end. :-)
rule pot_o_gold {
$lucky :=# You *DO* know how to catch a Leprechaun,
# don't you?
{
if (trick($lucky)) {
print "Begorrah! I'm rich!";
} else {
print "Always after me Lucky Charms ...";
}
}
}
}
> AH> rule Rainbow
> AH> {
> AH>
> AH>
> AH>
> AH>
> AH>
> AH>
> AH>
> AH> ?
> AH> }
This really is bad code on my part. s/Color/Colorific/, please.
rule Rainbow
{
?
}
>
> for the p6 regex impaired among us, please explain that. it might
> make a
> nice tute for the docs. i get the general picture but i don't follow
> how
> it works regarding the color checking.
Re: Conditional Cs?
Reading A6, I was wondering if the following would work:
sub return_if_true ($value)
{
if ($value)
{
leave where=>caller(1), value=>$value
}
}
Re: Conditional Cs?
>given baz(@args) { return $_ when defined }
>given baz(@args) { return $_ when $_ > 0 }
Sweet.
Shouldn't the latter example be:
given baz(@args) { return $_ if $_ > 0 }
In general, if a C condition clause contains
a C<$_>, chances are good that it's a mistake, right?
If a pipe short-circuited would one be able to do:
foo==> baz;# do pipe iff foo is true
baz(@args) ==> return; # if LHS true, return it
?
(If you wanted a pipe to NOT short-circuit you would
have to use another pipe operator, say:
foo ==>> baz; # always do pipe
foo ===> baz; # many possible syntaces
The mnemonic would be that the shorter pipe does
short-circuiting. Or use an adverb:
foo ==> :always baz; # always do pipe)
--
ralph
Re: A6: Named vs. Variadic Parameters
On Wed, Mar 19, 2003 at 12:19:20PM -0800, Michael Lazzaro wrote: > I think newbies are going to unquestionably try and put the parameters > in the same order as they expect to see the eventual arguments, and be > durn confused it doesn't work -- I know I would. [...] > Dunno. I'm just one datapoint, but I strongly see the difference > between (1) and (2) as being a *huge* newbie trap. Well, I guess I'm another datapoint then. Although I don't consider myself a wizard by any means, I've been programming Perl for a long time and I'm very comfortable with it. I've read A6 a couple of times and been following the discussions on the list. And, despite all those advantages, I _still_ don't really grok the proposed signature stuff (it gets a little clearer every time I read it, but it's still awfully muddy). I hadn't even recognized the trap that we are discussing until this thread came up. I think people just coming to Perl are going to be extremely baffled and frustrated by the signature syntax and semantics. This is going to promote one of two reactions: they will leave and go to Python/Ruby/whatever, or they will never use signatures. I'm still waiting for the Exegesis...I recognize that the Apocalpsi are hard simply because they are definitive and must cover every edge case. Possibly, with some day-to-day examples and down-to-earth tutorial materials available, all of this will become simple; that has happened for me before with prior Apocalpsi. However, even if it ends up being clarified by the Exegesis, the signature syntax/semantics ARE complex. In order to justify that complexity, they need to provide a tremendous advantage; I'm simply not sure that the advantages they provide are worth the complexity. In order to make it worthwhile (IMO), it would need to be very easy to use, which would imply at least the following: 1) There are both long and short forms of the zone markers. E.g: sub foo($x, $y, ?$z, *a);or sub foo(pos($x, $y), opt($z), slurp(@a)); (I'm pretty sure this is already planned.) 2) Once the params and their nature have been determined, it should be possible to use the function with the arguments in the same order as the declaration: E.g.: sub bar(pos($a, $b), slurp(@x), named($key)); bar($a, $b, 1,2,3, key => 'jack'); I understand what I'm asking here...the slurpy array must somehow know to "stop", which is somewhat opposed to the idea of "slurping". I would be perfectly happy if it were a compile-time error to declare the slurpy array anywhere other than last, and to declare positional arguments anywhere other than first. I guess what I'd really like is to see the concept of 'zones' taken to its logical extreme; specify the order in which the zones must appear, and then have a marker that denotes the transition, as opposed to labelling every parameter. Therefore (violating the rule about the colon for a moment): sub foobar( $x, $y, $z, # required positionals go here o: $a, $b, $c, # optional positionals go here n: $d, $e, $f, # named go here h: %h, # slurpy hash here s: $s, # slurpy scalar here a: @a # slurpy array here ); mygrep( Block &code, a: @list ); init_screen( n: $color, $height, $width, h: %control_values); etc... --Dks
Re: Ruminating RFC 93- alphabet-blind pattern matching
Thanks for the thoughtful consideration. Austin's given some high-
level examples of the kind I was hoping for,
"AH>" = Austin Hastings
AH> grammar Rainbow;
AH> use Colorific; # Import C and C, among others.
AH>
AH> What I don't know is how to recognize a color, which is to say I don't
AH> know how to write the rule -- because I don't know what this is
AH> being applied to. Is this reading pixels, interpreting the results of
AH> radio telescopy, or consuming Lucky Charms breakfast cereal bits? I
AH> don't know, so I'm just going to assume that Yary can write that for me
AH> -- it's his class, after all.
Right, "encapsulation" & "public interface" are the keys- rexen don't need
to know what makes Colorific. (And yes, I am a he, unlike Yari from Tron.)
I am curious about
AH> rule color {...}; # this one's on you.
if Colorific doesn't have stringification- that's the crux: passing
non-letter atoms to the regex engine. The way it's presented and
used, it's a rule that matches a color object, and seeing it in the
same_color rule is terrific- but (via RFC93?) I want to write it thus:
rule color { (.) <( $1.isa(Colorific) )> }
$daylight = &peek_at_sky =~ //; # is something in sky Colorific?
This example could be written with grep- but then, T(always)MTOWTDI.
Bonus points for the implementation of grammar Rainbow, very cute!
Lucky strike is also clearly written, though, I was hoping to do away
with any mention of \d. I want to grab numbers as atoms and never
enter the character realm.
AH>What I think you're looking for is the fact that they're not regexes
AH>any more. They are "rexen", but in horrifying-secret-reality, what has
AH>happened is that Larry's decided to move Fortran out of core, and
AH>replace it with yacc.
Cool, I did quite like yacc when I needed it- and it does look like we
have that expressive power now! Never used Fortran but I did spend a
couple summers in RPG-2, good riddence to big iron...
-y
~
The Moon is Waxing Crescent (1% of Full)
Re: A6: Named vs. Variadic Parameters
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2003 at 12:19:20PM -0800, Michael Lazzaro wrote:
> > I think newbies are going to unquestionably try and put the
> > parameters in the same order as they expect to see the eventual
> > arguments, and be durn confused it doesn't work -- I know I would.
> [...]
> > Dunno. I'm just one datapoint, but I strongly see the difference
> > between (1) and (2) as being a *huge* newbie trap.
>
> Well, I guess I'm another datapoint then.
*sigh* Count me in on that one.
I *love* this sort of thing, but I *really* don't believe the average
guy is going to take the same masochistic pleasure from it as I do.
> Although I don't consider myself a wizard by any means, I've been
> programming Perl for a long time and I'm very comfortable with it.
> I've read A6 a couple of times and been following the discussions on
> the list. And, despite all those advantages, I _still_ don't really
> grok the proposed signature stuff (it gets a little clearer every
> time I read it, but it's still awfully muddy). I hadn't even
> recognized the trap that we are discussing until this thread came up.
> I think people just coming to Perl are going to be extremely baffled
> and frustrated by the signature syntax and semantics. This is going
> to promote one of two reactions: they will leave and go to
> Python/Ruby/whatever, or they will never use signatures.
Ditto, though I realize that most people aren't going to *need* sigs
for most things Perl subs will just be perl subs, and folk will
only use sigs when they need what only sigs can give them. If they need
the speed and precision, they'll use an explicit signature to specify
what's required, though most of the time I think a lot of people will
still just say
sub foo { print @_ } # copied straight from A6, p.1
I think Larry's accomodating everybody, here.
Those of us who want to play with the tinkertoys will probably enjoy
the whole box, even the little widgets that take us a while to
identify. Those who just need blocks can ignore all the little
sockety-holes and connecting rods, and just stack the blocks. Those who
*need* the widgets but don't *want* to use them are a minority, even if
they be among the power users professionally.
The hard part is accomodating both ends.
> I'm still waiting for the Exegesis...I recognize that the Apocalpsi
> are hard simply because they are definitive and must cover every edge
> case. Possibly, with some day-to-day examples and down-to-earth
> tutorial materials available, all of this will become simple; that
> has happened for me before with prior Apocalpsi.
> However, even if it ends up being clarified by the Exegesis, the
> signature syntax/semantics ARE complex. In order to justify that
> complexity, they need to provide a tremendous advantage; I'm simply
> not sure that the advantages they provide are worth the complexity.
> In order to make it worthwhile (IMO), it would need to be very easy
> to use, which would imply at least the following:
>
> 1) There are both long and short forms of the zone markers.
>E.g: sub foo($x, $y, ?$z, *a);or
> sub foo(pos($x, $y), opt($z), slurp(@a));
>
> (I'm pretty sure this is already planned.)
Good! I think this is a great idea. Looks funny to me, but MUCH
clearer!
Could they then be reordered?
> 2) Once the params and their nature have been determined, it should
>be possible to use the function with the arguments in the same
>order as the declaration:
>E.g.: sub bar(pos($a, $b), slurp(@x), named($key));
> bar($a, $b, 1,2,3, key => 'jack');
>
>I understand what I'm asking here...the slurpy array must somehow
>know to "stop", which is somewhat opposed to the idea of
>"slurping". I would be perfectly happy if it were a compile-time
>error to declare the slurpy array anywhere other than last, and to
>declare positional arguments anywhere other than first.
I'm *still* fuzzy on this.
Personally, I'd just be more likely to avoid mixing types.
I'd have positionals and then optional scalars and/or slurpies,
or named pairs with optional named pairs and/or slurpy *hashes*,
but probably wouldn't mix types otherwise if I could avoid it
But I still want to *understand* how it works, and be *able* to use all
the toys! (Damian, PLEASE find some way to magically make this all
crystal clear in the synopsis. ;o)
> I guess what I'd really like is to see the concept of 'zones' taken
> to its logical extreme; specify the order in which the zones must
> appear, and then have a marker that denotes the transition, as
> opposed to labelling every parameter.
> Therefore (violating the rule about the colon for a moment):
>
> sub foobar(
> $x, $y, $z, # required positionals go here
>o: $a, $b, $c, # optional positionals go here
>n: $d, $e, $f, # named go here
>h: %h, # slurpy hash here
>
Re: Ruminating RFC 93- alphabet-blind pattern matching
On Wed, Apr 02, 2003 at 10:16:37AM -0800, Austin Hastings wrote:
> And the Colorific class supposedly has a way to determine if two colors
> look about like each other. Again, I don't know how that works, but I
> don't need to.
>
>> AH> rule same_color($color is Colorific)
>> AH> {
>> AH>::: { fail unless $1.looks_like($color); }
>> AH> }
>
> This is really probably bad code. Maybe a better rule would be:
>
> rule same_color($color is Colorific)
> {
>::: { fail unless $color.looks_like($1); }
> }
>
> I KNOW that $color is an object-of-type-Colorific, while I'm not sure,
> frankly, what is returning. Let Colorific handle that.
It's my understanding (such as it is) of regexen that subrules called
via capture their result in hypothetical variables. In
same_color, by the time you get into the code after the :::, $color
contains what was matched by . So, if matched at all, I
don't think you can call looks_like on $color because it's the
hypothetical result of not a Colorific. Either that or it fails
because you said it was a Colorific and it's not. Or you tried to
assign to it but you can't because it's not C.
I think we need a P6 regexen engine to play with to get used to all this
new stuff properly :-) Oh, and I really, really don't like all this
extraneous type information that everybody seems to be sprinkling around
their Perl6 code.
andrew
--
Virgo: (Aug. 23 - Sept. 22)
It seems the danger is over for now, but something tells you that you
haven't seen the last of that dastardly villain.
Re: == vs. eq
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Paul <[EMAIL PROTECTED]> wrote:
> > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > > Likewise, I could argue that it be called C<=:\> (the
> > > "disgruntled muppet" operator?) since that reflects the
> > > "equals, under reference" symbology. But that's yucky.
> >
> > Shouldn't that be ==:/ (maybe the "severely startled muppet"
> > operator? lol...) A single = would be assignment, but I have
> > no idea how adverbial modification would affect that. Exactly
> > what *would* adverbial assignment be? Would
> > $a =:\ $b
> > be like
> > $a = \$b
Still no input here. Was it a stupid question? :)
> > > sub budgetwise(Int $a, Int $b) {
> > > -1_000_000 <= $a - $b <= 1_000_000; }
> > > my Int $log_rolling, Int $pork_barrel;
> > > $log_rolling = random() * 1.0E9;
> > > $pork_barrel = random() * 1.0E9;
> > > if ($log_rolling eq:budgetwise $pork_barrel)
> > > print "They cost the same, give or take a million dollars.";
> >
> > Is that saying to make budgetwise the comparison operator at the
> > same precedence as eq?
>
> Actually, what I think I'm saying in this case is "replace the do()
> behavior of infix:eq with this sub."
Okay, that clicked. I'm here now.
> Which has kind of startling effects, because then you can also say
> things like this:
>
> sub uniquely(@dest is rw, @src) {
> my $last = @src[0] ~ "1";
> for @src -> $s {
> @dest.push($last = $s) unless $s == $last;
> }
> }
> my @a = <>; # Read all lines from a file.
> my @b =:uniquely @a;# Eat the duplicates
(Apologies: code above reformatted purely in the interest of readable
space, and not considered an improvement. >:O)
Ok, so you replace ='s do{} with uniquely(). The example won't work to
assign to a scalar, right? I think I'm following you, and I like where
you're going.
"My God, it's full of stars"
> > Wouldn't that be much like saying
> >
> > my sub infix:um(Int$a,Int $b)is equiv(&infix:eq){#c.f.A6p.11
> > -1_000_000 <= $a - $b <= 1_000_000; }
> > if ($log_rolling um $pork_barrel) # etc
>
> Looks right to me, modulo type-casting behavior -- I think yours does
> typechecking and blows up if the types are misaligned enough, while
> mine finds the right infix:= operator, and replaces the actual
> mechanics. (Frankly, I'm not sure what the right behavior of mine is.
> It may be better to think of it as "temporizing" the infix:= operator
> for one expression only. More thought required.)
Good territory to expore.
> > So how does one get a ref in P6 that won't dereference itself???
>
> No idea. I thought that the auto-da-fe^Wautodereference behavior was
> intended to make "loose references" impossible -- that is, you have
> to treat a reference object as an object, always. (Which just means
> more backslashes, I guess.)
>
> > Then we could say
> > my sub infix:embodies ($a,$b) is equiv(&infix:eq) {
> > $a.ref eq $b.ref # unless eq deref's even here.
> > }
> > if ($x embodies $y) {
> > print "X and Y refer to the same entity\n";
> > }
>
> Maybe you just have to say C<\$a eq \$b> ?
Makes sense to me. Then the right spelling of the above would be
my sub infix:embodies ($a,$b) is equiv(&infix:eq) { \$a eq \$b }
The only reason I didn't put that to begin with was because of a
discussion I saw about arrays deref'ing themselves. Let's try again
with a little more complexity:
my sub infix:embodies(Ref $a is ref,$b is ref)is equiv(&infix:eq){
$a eq $b
}
Could it be this simple? (Granted, for some definition of "simple")
If I read this right, it means $a is a referencing alias of the first
argument, $b the second. Could we then say
if (@x embodies @y) { foople() }
and have it DWIM? Would that mean (in P5-speak) $a->[0] *IS* @x[0] ???
Because if so, then that's exactly what Larry was talking about. The
"cruft" has been sucked back up into the signature where the coder had
to work out the details *once*, and then the code of the operator is
deafeningly simple, as is it use.
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: == vs. eq
Error correction:
--- Paul <[EMAIL PROTECTED]> wrote:
> > > no idea how adverbial modification would affect that. Exactly
> > > what *would* adverbial assignment be? Would
> > > $a =:\ $b
> > > be like
> > > $a = \$b
Thatv should have been: would
$a =:\ $b
be like
\$a = \$b
???
And does that mean that the do{} block of the \ operator replaces the
do{} of the = op? That wouldn't work.
But the resulting muppet really *IS* cute! ;~}
__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Re: Ruminating RFC 93- alphabet-blind pattern matching
W= Andrew Wilson, AH=Austin Hastings
AH> This is really probably bad code. Maybe a better rule would be:
AH>
AH> rule same_color($color is Colorific)
AH> {
AH>::: { fail unless $color.looks_like($1); }
AH> }
AH>
AH> I KNOW that $color is an object-of-type-Colorific, while I'm not sure,
AH> frankly, what is returning. Let Colorific handle that.
W>It's my understanding (such as it is) of regexen that subrules called
W>via capture their result in hypothetical variables. In
W>same_color, by the time you get into the code after the :::, $color
W>contains what was matched by . So, if matched at all, I
W>don't think you can call looks_like on $color because it's the
W>hypothetical result of not a Colorific. Either that or it fails
W>because you said it was a Colorific and it's not. Or you tried to
W>assign to it but you can't because it's not C.
So long as the regexp is grabbing unicode. I posit a modifier:
rule color { :ref (.) <( $1.isa(Colorific) )> }
$daylight = &peek_at_sky =~ //;
where ":ref" tells the engine that each atom is a reference, not
unicode. Then what matches is still Colorific.
On-the-side syntax question- what happens to modifiers that take arguments
when they're inside the rule? like from A5 "s:myoption($x) /foo/bar/",
can that be written "s/:myoption($x) foo/bar/" ? Wondering what happens
if the "ref" modifier can take an argument, saying what it's a ref of...
-y
~
The Moon is Waxing Crescent (1% of Full)
Re: Ruminating RFC 93- alphabet-blind pattern matching
--- Andrew Wilson <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 02, 2003 at 10:16:37AM -0800, Austin Hastings wrote:
> > And the Colorific class supposedly has a way to determine if two
> colors
> > look about like each other. Again, I don't know how that works, but
> I
> > don't need to.
> >
> >> AH> rule same_color($color is Colorific)
> >> AH> {
> >> AH>::: { fail unless $1.looks_like($color); }
> >> AH> }
> >
> > This is really probably bad code. Maybe a better rule would be:
> >
> > rule same_color($color is Colorific)
> > {
> >::: { fail unless $color.looks_like($1); }
> > }
> >
> > I KNOW that $color is an object-of-type-Colorific, while I'm not
> sure,
> > frankly, what is returning. Let Colorific handle that.
>
> It's my understanding (such as it is) of regexen that subrules called
> via capture their result in hypothetical variables. In
> same_color, by the time you get into the code after the :::, $color
> contains what was matched by . So, if matched at all,
> I don't think you can call looks_like on $color because it's the
> hypothetical result of not a Colorific. Either that or it
> fails because you said it was a Colorific and it's not. Or you tried
> to assign to it but you can't because it's not C.
More bad code on my part.
I had not intended that there be any correlation between the C<>
rule result and the C<$color> named argument -- that's just
coincidental evidence of my poor design skills.
If you'll replace $color with $c, and try again?
rule same_color($c is Colorific)
{
::: { fail unless $c.looks_like($1); }
}
The intention here is that the result of C<> is actually bound
to $1, per E5. So the idea is that C is asked to run its
.looks_like method on the C<> that was just recognized.
> I think we need a P6 regexen engine to play with to get used to all
> this new stuff properly :-) Oh, and I really, really don't like all
> this extraneous type information that everybody seems to be
> sprinkling around their Perl6 code.
I know someone's working on P6::Rexen or some such (NOT regex, per LW).
As for the type info, I think that the compiler won't be able to do too
much with the low level of information that we're specifying here, so
it's mostly codereader hints. But Damian has suggested that using types
at all opens the yawning void of contamination up the call tree, so
your implicit preference for no-type-info may wind up being the norm.
=Austin
Re: Ruminating RFC 93- alphabet-blind pattern matching
Austin Hastings wrote:
Another example. Let's say there's a class that deals with colors.
It has an operator that returns true if two colors look about the
same. Given a list of color objects, is there a regexp to find a
rainbow? Even if the color class doesn't support stringification?
Yes.
grammar Rainbow;
rule color {...}; # this one's on you.
rule same_color($color is Colorific)
{
::: { fail unless $1.looks_like($color); }
}
rule band($color is Colorific)
{
+
}
rule Rainbow
{
?
}
I'm a bit confused by the C rule; specifically, this line:
$1.looks_like($color)
Shouldn't this be: C<< $color.looks_like($1) >> ? Otherwise, it
suggests that you're redefining the match object class, which
probably isn't a good idea.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Ruminating RFC 93- alphabet-blind pattern matching
--- Yary Hluchan <[EMAIL PROTECTED]> wrote:
> Thanks for the thoughtful consideration. Austin's given some high-
> level examples of the kind I was hoping for,
>
> "AH>" = Austin Hastings
>
> AH> grammar Rainbow;
> AH> use Colorific; # Import C and C, among others.
> AH>
> AH> What I don't know is how to recognize a color, which is to say I
> don't
> AH> know how to write the rule -- because I don't know what
> this is
> AH> being applied to. Is this reading pixels, interpreting the
> results of
> AH> radio telescopy, or consuming Lucky Charms breakfast cereal bits?
> I
> AH> don't know, so I'm just going to assume that Yary can write that
> for me
> AH> -- it's his class, after all.
>
> Right, "encapsulation" & "public interface" are the keys- rexen don't
> need
> to know what makes Colorific. (And yes, I am a he, unlike Yari from
> Tron.)
> I am curious about
>
> AH> rule color {...}; # this one's on you.
>
> if Colorific doesn't have stringification- that's the crux: passing
> non-letter atoms to the regex engine. The way it's presented and
> used, it's a rule that matches a color object, and seeing it in the
> same_color rule is terrific- but (via RFC93?) I want to write it
> thus:
>
This isn't quite meaningful. What does a "non-letter atom" mean?
If you're processing a file or a string, that's the basic P6 model.
But consider \u for unicode -- that's a multi-byte object in the
stream. So for streams of bytes, the right way is just to code C such that it recognizes them in whatever form -- stringified or
not.
On the other hand, let's suppose that you've got a vast array of
floating point data:
my float @seti = {...evidence of intelligence, somewhere...};
It's a fair question to ask how to retarget the rexengine to use @seti
as the input stream. (I hereby declare that if anyone ever writes a
grammar to do stock-picking, I thunk it first! :-)
I'm guessing that the right way is to replace the low-level operators,
but what are they?
> rule color { (.) <( $1.isa(Colorific) )> }
> $daylight = &peek_at_sky =~ //; # is something in sky
> Colorific?
Alternatively, there may be a lower-level "stream" object that could be
replaced:
grammar Rainbow
{
let &Rex::get_one := &read_float_from_array;
# ...
}
> This example could be written with grep- but then, T(always)MTOWTDI.
Interesting, and possibly true. If you replaced all the interface-level
rules with code that interacted with some other data structure, it
might work:
rule color {
fail unless some_condition($_);
$0 = $_;
}
and then:
grep , @sky_data;
But that's just wrong. I'll wager there's a "trick" we don't know yet
that will allow for processing arbitrary streams of data, no matter
what the source. The only question is whether we have to override
something on the grammer, override something on the regex, or implement
a "fake IOstream" class to feed to the rexengine.
>
> Bonus points for the implementation of grammar Rainbow, very cute!
> Lucky strike is also clearly written, though, I was hoping to do away
> with any mention of \d. I want to grab numbers as atoms and never
> enter the character realm.
But what does that mean? Do you want "standard patterns" so that you
can talk about patterns and just have them work, or do you want
to change your "source" from a character stream/string to something
else?
>
> AH>What I think you're looking for is the fact that they're not
> regexes
> AH>any more. They are "rexen", but in horrifying-secret-reality, what
> has
> AH>happened is that Larry's decided to move Fortran out of core, and
> AH>replace it with yacc.
>
> Cool, I did quite like yacc when I needed it- and it does look like
> we
> have that expressive power now! Never used Fortran but I did spend a
> couple summers in RPG-2, good riddence to big iron...
Well, formats have gone into a module, and the complex number stuff has
been relegated to the care of a more formal class structure. I was
pulling for "COMMON" data declarations, but that went to "state".
But at least the Parrot interpreter can use computed gotos... :-)
=Austin
Re: Ruminating RFC 93- alphabet-blind pattern matching
>This isn't quite meaningful. What does a "non-letter atom" mean?
>
>If you're processing a file or a string, that's the basic P6 model.
>
>But consider \u for unicode -- that's a multi-byte object in the
>stream. So for streams of bytes, the right way is just to code Ccolor> such that it recognizes them in whatever form -- stringified or
>not.
>
>On the other hand, let's suppose that you've got a vast array of
>floating point data:
>
>my float @seti = {...evidence of intelligence, somewhere...};
>
>It's a fair question to ask how to retarget the rexengine to use @seti
>as the input stream.
I'm asking! Array of float, int, Colorific, sound_frame, mixed bag
of objects- those are examples of "non-letter atoms" (what's it mean?
Exactly what I mean to. Lewis Carol makes it so easy...)
Let's go back to A5. It defines modifiers for different levels of
unicode- :u0, :u1, :u2, :u3 - which change what are considered the
atoms to grab and match. Hence my suggestion for a ":ref" modifier
to tell the engine to grab references. ":scalar" could be used to
grab floats in the seti example.
>But what does that mean? Do you want "standard patterns" so that you
>can talk about patterns and just have them work, or do you want
>to change your "source" from a character stream/string to something
>else?
Something else. In all my examples, I've been binding to a sub, so
that the input stream can be something other than character stream/
strings.
-y
~
The Moon is Waxing Crescent (2% of Full)
