Re: $? and $! equivalents

[N6Ghost]

On Fri, 14 Sep 2018 18:15:21 -0400
Brandon Allbery  wrote:

> Magic variables make multiple threads impossible, which is why perl 5
> is stuck with ithreads: what happens if two threads each "run"
> something at around the same time?
> 
> In Perl 6, you have a Proc object for each subprocess, and can query
> it for its status and/or result code; for things like sub run, the
> Proc should be the return value.
> 
> On Fri, Sep 14, 2018 at 6:08 PM Parrot Raiser <1parr...@gmail.com>
> wrote:
> 
> > This is probably going to be a forehead-slapper, but I can't find a
> > reference in either perlintro.com or http://docs.perl6.org/
> > (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
> > P6.What are they?
> >
> > I want to be able to "run" or "shell" programs, then examine return
> > codes and errors. (The immediate case is to see if a program name is
> > already in use by running  "which $progname". )
> >  
> 
> 

this is very good to know. 

Re: $? and $! equivalents

[Parrot Raiser]

OK, different paradigm, different methods.

Thanks.

Another couple of entries for the "differences" list? Even a note the
thing doesn't exist saves fruitless further searching.

On 9/14/18, Brad Gilbert  wrote:
> On Fri, Sep 14, 2018 at 5:08 PM Parrot Raiser <1parr...@gmail.com> wrote:
>>
>> This is probably going to be a forehead-slapper, but I can't find a
>> reference in either perlintro.com or http://docs.perl6.org/
>> (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
>> P6.What are they?
>>
>> I want to be able to "run" or "shell" programs, then examine return
>> codes and errors. (The immediate case is to see if a program name is
>> already in use by running  "which $progname". )
>
>my $proc = run , :out, :!in;
>say $proc.out.slurp;
>say $proc.exitcode;
>

Re: $? and $! equivalents

[Brad Gilbert]

On Fri, Sep 14, 2018 at 5:08 PM Parrot Raiser <1parr...@gmail.com> wrote:
>
> This is probably going to be a forehead-slapper, but I can't find a
> reference in either perlintro.com or http://docs.perl6.org/
> (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
> P6.What are they?
>
> I want to be able to "run" or "shell" programs, then examine return
> codes and errors. (The immediate case is to see if a program name is
> already in use by running  "which $progname". )

   my $proc = run , :out, :!in;
   say $proc.out.slurp;
   say $proc.exitcode;

Re: $? and $! equivalents

[Brandon Allbery]

Magic variables make multiple threads impossible, which is why perl 5 is
stuck with ithreads: what happens if two threads each "run" something at
around the same time?

In Perl 6, you have a Proc object for each subprocess, and can query it for
its status and/or result code; for things like sub run, the Proc should be
the return value.

On Fri, Sep 14, 2018 at 6:08 PM Parrot Raiser <1parr...@gmail.com> wrote:

> This is probably going to be a forehead-slapper, but I can't find a
> reference in either perlintro.com or http://docs.perl6.org/
> (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
> P6.What are they?
>
> I want to be able to "run" or "shell" programs, then examine return
> codes and errors. (The immediate case is to see if a program name is
> already in use by running  "which $progname". )
>


-- 
brandon s allbery kf8nh
allber...@gmail.com

Re: allow .re and .im to be l-values

[Moritz Lenz]

On 05/19/2012 06:05 AM, Siddhant Saraf wrote:
>  r: my $x = 4 + 2i; $x.re = 5;
>  rakudo 45679a: OUTPUT«Cannot assign to a non-container␤  in
> block  at /tmp/PeeJaa8bWJ:1␤␤»
> 
> I think $x.re (Real part of $x) and $x.im (Imaginary part of $x)
> should be allowed to be l-values.
> What do you say?

No.

Complex objects are value types and immutable.

It's bad enough that we conflate the container/value distinction for
substr-rw already, but we do it because it's quite useful.

But for complex numbers, it's not so useful, because you can just create
a new one quite easily:

$x = 5 + $x.im*i;

Cheers,
Moritz

allow .re and .im to be l-values

[Siddhant Saraf]

 r: my $x = 4 + 2i; $x.re = 5;
 rakudo 45679a: OUTPUT«Cannot assign to a non-container␤  in
block  at /tmp/PeeJaa8bWJ:1␤␤»

I think $x.re (Real part of $x) and $x.im (Imaginary part of $x)
should be allowed to be l-values.
What do you say? Will this affect the performance of Rakudo, Niecza ?

Recently substr-rw was split off from substr, so that now substr-rw is
the lvalue form. So maybe we can have $x.re-rw and $x.im-rw, but that
would be really ugly :)

-sisar

Re: and in S05

[Larry Wall]

On Sat, Jun 21, 2008 at 01:59:28PM -0700, cognominal wrote:
: C and  being zero width assertions , I think they must
: always be called with
: a question mark. This is not the case line 394 and 1537.
: Perljam  suggested that a zero width assertion can be also a capturing
: one and that
: could explain the dropping of the question mark. I don't agree with
: that suggestion.

I see little reason to prohibit use of ?-less  to mean capture.
If someone is looking to eke out more performance, it will be fairly
obvious that the syntax tree has extraneous "before" nodes in it.
And since you can use  in a kind of "and" logic to view a
string in different ways, any of which are valid views, I think
a particular view should be able to return its matches even if
you later force it to succeed at zero width.

: Anyway the examples given line 394 and 1537 don't involve capture.

True, those are fossils.

Larry

Re: &, &&, and backtracking.

[Larry Wall]

On Thu, Sep 06, 2007 at 03:49:42PM -0700, Larry Wall wrote:
: On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote:
: : I agree.  One thought I had was that perhaps non-greedy matching
: : could also terminate the token prefix.
: 
: Well, that's more or less arguing it the other way.  It kind of assumes
: your fooba-ish arguments are smart enough to test for non-r after.

The more I think about it, the more I like this approach.  Most token
should be matched in ratchet mode, and I think minimal matching
is perhaps a form of cheating: "Look for the nearest end of this
without me actually bothering to parse the middle."  And certainly
any reasonable grammer is going to be checking that a keyword is
properly terminated by a word boundary anyway.

Larry

Re: &, &&, and backtracking.

[Larry Wall]

On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote:
: I agree.  One thought I had was that perhaps non-greedy matching
: could also terminate the token prefix.

Well, that's more or less arguing it the other way.  It kind of assumes
your fooba-ish arguments are smart enough to test for non-r after.

: > [...]
: > I think longest-token semantics have to trump minimal matching here,
: > and my argument is this.  Most uses of *? have additional information
: > on what terminates it, either implicitly in what it is matching, or
: > explicitly in the next bit of regex.  That is, you'd typically see
: > either
: > foo\w+? | fooba
: > or
: > foo.+?  | fooba
: > 
: > In either case, the clear intent is to match foobar over fooba.
: > Therefore I think the DFA matcher just strips ? and does its ordinary
: > character by character match, relying on that extra info to match
: > the real extent of the quantifier.
: 
: Does this still hold true for a non-greedy quantifier in the
: middle of an expression... ?  I.e.,
: 
: "foobazbar deborah" ~~ /foo .+? b.r | fooba | foobazb /
: 
: matches "foobazbar debor" ?

I suppose one approach would be to limit the DFA to the longest known
constant string, and then rerun any variable branches individually
to see if they will actually match something that long.  Alternately,
if the DFA engine is smart enough to kick out all the matches of the
"foo .+? b.r" branch then it could conceivably be taught to return
the shortest one rather than the longest one.  Course, the question
after than is, what if you mix minimal with maximal quantifiers?

Another consideration is the efficiency of matching that pattern
against "foobazbar" ~ 'b' x 1.  That would definitely run
faster if you cut off the DFA after the longest known token, or as
soon as the DFA reduces to one possibility, presuming you can know
such a thing.

Any way we work it, there will be a way to use it wrong.

Larry

Re: &, &&, and backtracking.

[Patrick R. Michaud]

On Thu, Sep 06, 2007 at 12:37:37PM -0700, Larry Wall wrote:
> On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote:
> : On a somewhat similar question, what happens with a pattern
> : such as
> : 
> : "foobar" ~~ / foo.+? | fooba /
> : 
> : The LHS initially matches "foob", but with backtracking could
> : eventually match "foobar".  Do the longest-token semantics
> : in this case cause the RHS to be dispatched first, even
> : though the token declaration of the LHS _could_ match a 
> : longer token prefix?  
> 
> Yow.  ICATBW.  Non-greedy matching is somewhat antithetical to
> longest-token matching.  

I agree.  One thought I had was that perhaps non-greedy matching
could also terminate the token prefix.

> [...]
> I think longest-token semantics have to trump minimal matching here,
> and my argument is this.  Most uses of *? have additional information
> on what terminates it, either implicitly in what it is matching, or
> explicitly in the next bit of regex.  That is, you'd typically see
> either
> foo\w+? | fooba
> or
> foo.+?  | fooba
> 
> In either case, the clear intent is to match foobar over fooba.
> Therefore I think the DFA matcher just strips ? and does its ordinary
> character by character match, relying on that extra info to match
> the real extent of the quantifier.

Does this still hold true for a non-greedy quantifier in the
middle of an expression... ?  I.e.,

"foobazbar deborah" ~~ /foo .+? b.r | fooba | foobazb /

matches "foobazbar debor" ?

(I completely grant that the examples I'm coming up with here
may be completely nonsensical in real application, but I'm
just exploring the space a bit.)

Pm

Re: &, &&, and backtracking.

[Geoffrey Broadwell]

On Thu, 2007-09-06 at 12:37 -0700, Larry Wall wrote:
> Yow.  ICATBW.

The what now?


-'f

Re: &, &&, and backtracking.

[Larry Wall]

On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote:
: > Were we using the procedural conjunction:
: > 
: > "foobar" ~~ / <[a..z]>+ && [ ... ] /;
: > 
: > I would guess that the LHS matches as much as it can ("foobar"), then
: > the RHS matches "foo" [...and then backtracks the LHS until a 
: > conjunctional match is found...]
: >
: > Or it's much simpler than that and both of the regexes above just fail
: > because of the greediness of C<+> and there is no intra-conjunction
: > backtracking.
: 
: I think we definitely allow intra-conjunction backtracking.
: PGE implements it that way.

That's what I think.

: On a somewhat similar question, what happens with a pattern
: such as
: 
: "foobar" ~~ / foo.+? | fooba /
: 
: The LHS initially matches "foob", but with backtracking could
: eventually match "foobar".  Do the longest-token semantics
: in this case cause the RHS to be dispatched first, even
: though the token declaration of the LHS _could_ match a 
: longer token prefix?  

Yow.  ICATBW.  Non-greedy matching is somewhat antithetical to
longest-token matching.  But basically it boils down to this:
Does the longest-token matcher ignore the ?  and do

foo.+ | fooba

or is there an implicit ordering above and beyond the DFA engine of

foob | fooba ||
fooba | fooba ||
foobar | fooba ||

I think longest-token semantics have to trump minimal matching here,
and my argument is this.  Most uses of *? have additional information
on what terminates it, either implicitly in what it is matching, or
explicitly in the next bit of regex.  That is, you'd typically see
either

foo\w+? | fooba

or

foo.+?  | fooba

In either case, the clear intent is to match foobar over fooba.
Therefore I think the DFA matcher just strips ? and does its ordinary
character by character match, relying on that extra info to match
the real extent of the quantifier.

Larry

Re: &, &&, and backtracking.

[Patrick R. Michaud]

On Wed, Sep 05, 2007 at 09:36:24PM -0500, Jonathan Scott Duff wrote:
> How do C<&> and C<&&> differ with respect to backtracking?  For instance,
> 
> "foobar" ~~ / <[a..z]>+ & [ ... ] /;
> 
> Both sides of the C<&> happen in parallel, so I would guess that they
> both match "foo" then stop. Please correct me if that's wrong.

I think the phrase "happen in parallel" overstates things a bit
here.  From S05:

The & form is considered declarative rather than procedural;
it allows the compiler and/or the run-time system to decide 
which parts to evaluate first, and it is erroneous to assume 
either order happens consistently.  The && form guarantees 
left-to-right order, and backtracking makes the right argument 
vary faster than the left.

So, to answer your original question, I think the most we can
say is that C<&&> guarantees a specific order of evaluation,
while C<&> allows the pattern matcher to choose an ordering.

> Were we using the procedural conjunction:
> 
> "foobar" ~~ / <[a..z]>+ && [ ... ] /;
> 
> I would guess that the LHS matches as much as it can ("foobar"), then
> the RHS matches "foo" [...and then backtracks the LHS until a 
> conjunctional match is found...]
>
> Or it's much simpler than that and both of the regexes above just fail
> because of the greediness of C<+> and there is no intra-conjunction
> backtracking.

I think we definitely allow intra-conjunction backtracking.
PGE implements it that way.


On a somewhat similar question, what happens with a pattern
such as

"foobar" ~~ / foo.+? | fooba /

The LHS initially matches "foob", but with backtracking could
eventually match "foobar".  Do the longest-token semantics
in this case cause the RHS to be dispatched first, even
though the token declaration of the LHS _could_ match a 
longer token prefix?  

Thanks,

Pm

Re: &, &&, and backtracking.

[Jonathan Lang]

Jonathan Scott Duff wrote:
> How do C<&> and C<&&> differ with respect to backtracking?  For instance,
>
> "foobar" ~~ / <[a..z]>+ & [ ... ] /;
>
> Both sides of the C<&> happen in parallel, so I would guess that they
> both match "foo" then stop. Please correct me if that's wrong.

As written, this match would fail, since '<[a..z]>+' would match
"foobar" while '[ ... ]' would match "foo".  '&' requires that both
sides match the same start and end points.  I suppose that it might be
worth considering requiring only the start points to match, and having
the conjoined match use the earliest end point; so that the above
match would then match "foo" instead of failing.  But it's entirely
possible that there's something faulty with this approach.

The difference between '&' and '&&' is that '&' evaluates the two
sides in an arbitrary order, possibly even in parallel; '&&' always
evaluates the left side first, and only bothers with the right side if
the left side matched.

-- 
Jonathan "Dataweaver" Lang

Re: === and array-refs

[Audrey Tang]

在 2006/8/18 上午 3:31 時，Ben Morrow 寫到：

Just to make sure I've got all this straight:

=:= compares names
=== compares containers
eqv compares values


=:= evaluates both sides as lvalue -- that's VAR() -- and compare  
them with ===.
=== evaluates both sides as rvalue and, for container (mutable)  
types, compares their pointer address.
eqv evaluates both sides as rvalue and, for container (mutable)  
types, compares their content values.


None of the three coerces their arguments to concatenated List (aka  
list flattening, aka slurpy context).



So given an array @W,

my @X := @W;# @X =:= @W
my @Y =  @W;# @Y === @W but @Y !=:= @W
my @Z =  @W.clone;  # @Z eqv @W but @Z !=== @W


Your Array example would be correct with the $ sigil:

my $w = [1,2,3,4]; # Scalar containing Array
my $x := $w;   # $x =:= $w
my $y =  $w;   # $y === $w but $y !=:= $w
my $z =  $w.clone; # $z eqv $w but $z !=== $w

However, &infix:<=> when its left-hand side is an array, has an  
different signature
(and indeed, different precedence) than when its left-hand side is a  
scalar:


my $y = $w;   # does not flatten $w
my @Y = @W;   # does flatten @w, essentially doing a .clone
my @Z = @W.clone; # same as "my @Z = @W" really.

So the two assignments (@Y and @Z) above turns out to be the same  
thing, and neither

will make "===" hold afterwards.

Cheers,
Audrey


PGP.sig
Description: This is a digitally signed message part

Re: === and array-refs

[Ben Morrow]

Quoth [EMAIL PROTECTED] ("Mark J. Reed"):
> On 8/17/06, David Green <[EMAIL PROTECTED]> wrote:
> > >$a=[1, 2, [EMAIL PROTECTED];
> > >$c=[1, 2, [EMAIL PROTECTED];
> > >$d=[1, 2, [EMAIL PROTECTED];
> > >
> > >So $a, $c, and $d may all have the same *value*
> > >(or "snapshot", when evaluated all the way down
> > >through nesting and references), i.e. they might
> > >be eqv, but only $a and $c are === because they
> > >have the same contents [unevaluated contents]
> > >and $d doesn't.
> 
> In this case, it seems like [===] @$a, @$c would do what you want,
> yes?  It would return true, while [===] @$a,@$d would return false...
>
> In the general case - well, I think the thread demonstrates that it's
> hard to define a general case for what you want to do.   Based on your
> example, I assumed you wanted one-level dereferencing, regardless of
> the contents. But it sounds like what you want is infinite
> dereferencing as long as the referent is anonymous,  and no
> dereferencing if the referent is a named variable?

Surely that's a meaningless distinction? A named variable can become
anonymous if its name goes out of scope; an anon can be bound to a name.

Just to make sure I've got all this straight:

=:= compares names
=== compares containers
eqv compares values

So given an array @W, 

my @X := @W;# @X =:= @W
my @Y =  @W;# @Y === @W but @Y !=:= @W
my @Z =  @W.clone;  # @Z eqv @W but @Z !=== @W

? This seems like a useful set of distinctions to me...



Ben

-- 
  The cosmos, at best, is like a rubbish heap scattered at random.
   Heraclitus
  [EMAIL PROTECTED]

Re: === and array-refs

[Andrew Suffield]

On Thu, Aug 17, 2006 at 12:00:17AM -0700, Darren Duncan wrote:
> As a lead-in, I should say that Synopsis 3 has a good and complete 
> explanation of these matters and has had it for several weeks, in my 
> opinion.
> 
> Since you are wanting to compare two mutable Array, just use the eqv 
> operator, which will do everything you want in a terse and easy to 
> understand manner.

I'd just like to point out that S03 is back-arsewards here - it
explains === first, and then explains eqv in terms of ===. Since eqv
is the familiar thing people will want most of the time, and === is
the weird thing that isn't used very often, it would make far more
sense to explain them the other way around (and probably confuse less
people). Understanding === should not be a prerequisite for
understanding eqv.

Re: === and array-refs

[Dave Whipp]

David Green wrote:



No, look at the example I've been using.  Two arrays (1, 2, [EMAIL PROTECTED]) and (1, 
2, [EMAIL PROTECTED]) clearly have different (unevaluated) contents.  "eqv" only tells 
me whether they have the same value (when @x and @y are evaluated).  
That's a different question -- yes, it's the more common question, but I 
think the comparison I want to make is just as reasonable as ===, except 
there's no easy way to do it.



does "*$a === *$b" work? I.e. splat the two arrays into sequences, and 
then do the immuable compare on those sequences.

Re: === and array-refs

[Mark J. Reed]

On 8/17/06, David Green <[EMAIL PROTECTED]> wrote:

>$a=[1, 2, [EMAIL PROTECTED];
>$c=[1, 2, [EMAIL PROTECTED];
>$d=[1, 2, [EMAIL PROTECTED];
>
>So $a, $c, and $d may all have the same *value*
>(or "snapshot", when evaluated all the way down
>through nesting and references), i.e. they might
>be eqv, but only $a and $c are === because they
>have the same contents [unevaluated contents]
>and $d doesn't.


In this case, it seems like [===] @$a, @$c would do what you want,
yes?  It would return true, while [===] @$a,@$d would return false...

In the general case - well, I think the thread demonstrates that it's
hard to define a general case for what you want to do.   Based on your
example, I assumed you wanted one-level dereferencing, regardless of
the contents. But it sounds like what you want is infinite
dereferencing as long as the referent is anonymous,  and no
dereferencing if the referent is a named variable?  That doesn't seem
like a common enough case to warrant sugar to me; what am I missing?

--
Mark J. Reed <[EMAIL PROTECTED]>

Re: === and array-refs

[Larry Wall]

On Thu, Aug 17, 2006 at 12:18:55PM -0600, David Green wrote:
: So perhaps what I'm looking for is more syntactic 
: sugar for easily traversing nested data 
: structures in different ways.

Quoth S03:

If that's not enough flexibility, there is also an C function
that can be passed additional information specifying how you want
canonical values to be generated before comparison.  This gives
C the same kind of expressive power as a sort signature.

Larry

Re: === and array-refs

[David Green]

On 8/16/06, David Green wrote:

   $a=[1, 2, [EMAIL PROTECTED];
   $c=[1, 2, [EMAIL PROTECTED];
   $d=[1, 2, [EMAIL PROTECTED];

$a =:= $c;  #false, different variables
$a === $c;  #true, same elements make up $a and $c
$a eqv $c;  #true, same elements therefore same values

$a === $d;  #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are 
different refs

So $a, $c, and $d may all have the same *value* 
(or "snapshot", when evaluated all the way down 
through nesting and references), i.e. they might 
be eqv, but only $a and $c are === because they 
have the same contents [unevaluated contents] 
and $d doesn't.


(Actually $a===$c above should be false.)  Given 
that === answers the question "are these things 
the same object", what's the solution for my 
original motivation of comparing two items for 
their unevaluated contents?  "Eqv" evaluates 
everything (both references and nested 
containers) down to immutable values; I want to 
follow nested structures all the way down, but 
not evaluate/deref any variable references.


For the one-dimensional $a and $c given above, I could do something like:
?all(@[EMAIL PROTECTED], grep {$^a === $^c} zip(@$a; @$c))

For multidimensional/nested arrays, I could check 
that they're the same size with $a.shape eqv 
$b.shape, but I believe grep (or map, etc.) work 
only one-dimensionally.  I don't think using 
hyperoperators would work either, because $a 
»===« $c would deref the contained @x before 
applying ===, right?


Plus hyperops return a nested structure, and I'm 
looking for a single bool -- I think hyperising 
"all" around the whole result would work 
Hyperops also upgrade dimensions that don't match 
between the RHS and LHS, which is not always what 
you want.


So perhaps what I'm looking for is more syntactic 
sugar for easily traversing nested data 
structures in different ways.



-David

Re: === and array-refs

[David Green]

On 8/17/06, Darren Duncan wrote:

At 11:16 PM -0600 8/16/06, David Green wrote:
I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to 
[1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case 
(regardless of Seq vs. Array -- I didn't think it made a difference 
here).

[...]
Since you are wanting to compare two mutable Array, just use the eqv 
operator, which will do everything you want in a terse and easy to 
understand manner.


No, look at the example I've been using.  Two arrays (1, 2, [EMAIL PROTECTED]) and 
(1, 2, [EMAIL PROTECTED]) clearly have different (unevaluated) contents.  "eqv" 
only tells me whether they have the same value (when @x and @y are 
evaluated).  That's a different question -- yes, it's the more common 
question, but I think the comparison I want to make is just as 
reasonable as ===, except there's no easy way to do it.



-David

Re: === and array-refs

[Markus Laire]

On 8/17/06, Darren Duncan <[EMAIL PROTECTED]> wrote:

Generally speaking, the direct use of === is more for specialized
purposes, somewhat like the direct use of =:= is.  If one can't tell
the difference between === and eqv, they most likely want snapshot
semantics anyway, and so might as well forget === exists, and just
use eqv everywhere.


For me === feels like it should be the operator with "easier"
semantics, i.e. the operator which perl-newbies would first want to
learn, so it feels like the semantics of === and eqv should be
swapped.

=== is a lot nearer to what many other languages uses for they
comparison than more cryptic eqv.

Also, == does "simpler" comparison than eq, so I feel that === should
also do "simpler" (to understand) comparison than eqv

--
Markus Laire

Re: === and array-refs

[Darren Duncan]

At 11:16 PM -0600 8/16/06, David Green wrote:

On 8/15/06, Darren Duncan wrote:

At 2:51 PM -0600 8/15/06, David Green wrote:

[...]
You are right, but we have both Seq and Array types, so depending 
which one you use, you want either the === or eqv operators to do 
what you want.  There is no reason that === should say 2 Array are 
equal; we have eqv for that, or use 2 Seq instead of 2 Array if you 
want === to return true on the same values.


Is Seq vs Array the right distinction here?  A Seq is immutable, so 
I can't change its size, for instance, which is not what I want.  I 
just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to 
[1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case 
(regardless of Seq vs. Array -- I didn't think it made a difference 
here).


As a lead-in, I should say that Synopsis 3 has a good and complete 
explanation of these matters and has had it for several weeks, in my 
opinion.


Since you are wanting to compare two mutable Array, just use the eqv 
operator, which will do everything you want in a terse and easy to 
understand manner.


Generally speaking, the direct use of === is more for specialized 
purposes, somewhat like the direct use of =:= is.  If one can't tell 
the difference between === and eqv, they most likely want snapshot 
semantics anyway, and so might as well forget === exists, and just 
use eqv everywhere.


There's no point arguing that === should deeply compare mutable types 
when you already have eqv to do that.  Continuing on like you appear 
to be is like saying that the + operator should be useable to 
concatenate two Str, when we have the ~ operator for that.  Arguing 
that === should deeply compare mutable types is like arguing that + 
should contactenate two Str.


-- Darren Duncan

Re: === and array-refs

[David Green]

On 8/16/06, David Green wrote:

   $a=[1, 2, [EMAIL PROTECTED];
   $c=[1, 2, [EMAIL PROTECTED];
   $d=[1, 2, [EMAIL PROTECTED];

$a =:= $c;  #false, different variables
$a === $c;  #true, same elements make up $a and $c
$a eqv $c;  #true, same elements therefore same values

$a === $d;  #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are 
different refs

So $a, $c, and $d may all have the same *value* (or "snapshot", when 
evaluated all the way down through nesting and references), i.e. 
they might be eqv, but only $a and $c are === because they have the 
same contents [unevaluated contents] and $d doesn't.


OK, here's the counter-argument to my incessant ranting:

In the above example, $a and $c do "look" awfully similar, but 
suppose we replace the anonymous arrays with named ones:


@X1=(1, 2, [EMAIL PROTECTED]);
@X2=(1, 2, [EMAIL PROTECTED]);

[EMAIL PROTECTED];
[EMAIL PROTECTED];

Now $a clearly does NOT === $b, because @X1 and @X2 are different 
variables (that just coincidentally happen to share the same contents 
at the moment).  Replacing @X1 and @X2 with their anonymous 
equivalents shouldn't suddenly change that.


[Well, anonymous object could have different rules, I suppose, but 
it's no longer "obvious" that they should.  Strings, for example, do 
have special treatment to make different string-objects look the 
same, but strings can't contain other variables, so it's easy to make 
them act like plain values.]


However, it also follows that @X1 !=== @X2.  There's no anonymous 
reference hiding there, so why aren't @X1 and @X2 the same?  (Well, 
they just aren't!)  So... probably what I wanted all along is just to 
compare the contents of an array -- and === just isn't it.  Hm.


=:= checks for same variable
=== checks for same object
eqv checks for same value

except that if the operands aren't objects, === will compare them as 
values (like eqv).  Or rather, if an item is a value (or an object 
that ought to act like a value), just make sure its SKID (which === 
uses) compares in an appropriate value-like way.



-David

Re: === and array-refs

[David Green]

On 8/15/06, Darren Duncan wrote:

At 2:51 PM -0600 8/15/06, David Green wrote:

[...]
You are right, but we have both Seq and Array types, so depending 
which one you use, you want either the === or eqv operators to do 
what you want.  There is no reason that === should say 2 Array are 
equal; we have eqv for that, or use 2 Seq instead of 2 Array if you 
want === to return true on the same values.


Is Seq vs Array the right distinction here?  A Seq is immutable, so I 
can't change its size, for instance, which is not what I want.  I 
just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to 
[1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case 
(regardless of Seq vs. Array -- I didn't think it made a difference 
here).


Actually, my previous example which Larry said was correct was:

   $a=[1, 2, [EMAIL PROTECTED];
   $c=[1, 2, [EMAIL PROTECTED];
   $d=[1, 2, [EMAIL PROTECTED];

$a =:= $c;  #false, different variables
$a === $c;  #true, same elements make up $a and $c
$a eqv $c;  #true, same elements therefore same values

$a === $d;  #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are 
different refs

So $a, $c, and $d may all have the same *value* (or "snapshot", when 
evaluated all the way down through nesting and references), i.e. they 
might be eqv, but only $a and $c are === because they have the same 
contents [unevaluated contents] and $d doesn't.


Which is what makes sense to me, but S03 says "[1,2]!===[1,2]".  My 
position is that even if they are different "objects", that 
difference is fairly useless, and should therefore be hidden (same as 
it is for objects that are strings).


First of all, in Perl 6, there are no separate "arrays" and "array 
refs"; we simply have the 'Array' type, which is treated as a lump 
on its own.

More generally, there are no "reference" types in Perl 6.


I thought there were, just not as conspicuously.  There are 
"captures" anyway, which are supposed to be like P5-refs, and beyond. 
(However, I admit to being a bit fuzzy on exactly how Signatures and 
Captures work -- if anyone could write an Exegesis on the subject, I 
know I'm not the only one who would appreciate it.)


[...]
The difference between === and eqv is that, if you have 2 symbols, 
$a and $b, and $a === $b returns true, then that result is 
guaranteed to be eternal if you don't assign to either symbol 
afterwards.  For a mutable type like an Array, === returns false on 
2 containers because it can't guarantee that someone else holding 
another symbol for either container won't change its content, and so 
$a or $b could change after we made the === test, without us causing 
that to happen, and so for mutable types, === only returns true for 
2 aliases, because that is the most it can guarantee that they will 
be the same.


So, given mutable types, $a===$b if and only if $a=:=$b?  That 
doesn't sound right, otherwise === seems superfluous.  The thing is 
if $a=[1,2] and $b=[1,2], then arrays or not, nothing can change $a 
or $b except by changing $a or $b.  [Or aliases bound to same, of 
course.]  So there's no reason for $a===$b to be false.  (If they 
look the same, and they act the same, then they're ducks.  Er, or 
something.)


(Hoping the 'eternal' stuff hasn't thrown me off and resulted in my 
completely misinterpreting what you were trying to say.)



-David

Re: === and array-refs

[Dr.Ruud]

Larry Wall schreef:
> Dr.Ruud:

>> Comparing strings in Perl5, using NFKD:
>>
>> perl5 -MUnicode::Normalize -we '
>>   ($\, $,) = ("\n", "\t") ;
>>   $x = qq{Henry IV} ;
>>   $y = qq{Henry \x{2163}} ;
>>   print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
>> # $x = NFKD $x ;
>>   $y = NFKD $y ;
>>   print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
>> '
>> Wide character in print at -e line 5.
>>8   7   0
>> 8   8   1
>>
>>
>> How will the Str type do this?
>
> That'd just be:
>
> eqv($x, $y, :(NFKD $^s))
>
> [...]

Thanks. Is it also possible to define an NKFD_Str type so that you can
code C<$x === $y>, and the NKFD-stuff is done because of the type's
.SKID?  (Can a "type" have a (type-wide) .SKID?)

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: === and array-refs

[David Green]

On 8/16/06, Charles Bailey wrote:

This is where the "eternal" part starts to confuse me (not picking on
your wording, but on the semantics).


I'll pick on the wording (wording should always be picked on -- not 
to be pedantic (OK, I like to be pedantic, but that's not the *only* 
reason!), but because it really is an advantage to develop 
terminology that's as precise and pretty as possible).


Maybe values can be considered "eternal", in some philosophical 
platonic sense, but variables certainly aren't (eventually your 
program will reach the end or the sun will explode or something). 
"Permanent", maybe...



What happens if I insert the C<$aa = "Two"> before line 255?  In other
words, can I rely on P6 to know at line 3 that there's an alias out
there by which C<$a> _might_ change without assignment later (i.e. the
guarantee that "$a and $b will remain the same unless you assign to
one" might be violated)?


...but there's nothing permanent either really, because you can 
always change any variable you like, later on at line 255.  (Unless 
the variable is a constant, which is not the same thing as being 
immutable even though those words are fairly synonymous, i.e. yet 
more confusing terminology.)


What we're really talking about is action-at-a-distance: one variable 
changing its value because *something else* changed -- some other 
variable that was somehow "contained inside" the first one.


Not to be confused with changing some other variable that is really 
the same variable because they were bound together: $a:=$b.  Should I 
call that two variables (somehow "linked" or bound together)?  Or 
would it be better (easier, less confusing) to call it *one* variable 
that has two names?  (Still nothing to be described as "permanent" 
here, because I can always unbind them later on, and have $a and $b 
being two completely separate variables, right?)


I find myself tempted to talk in temporal terms to explain the issue, 
and that's a natural way to frame examples, but the language of 
examples doesn't seem to be that good for explaining the concepts. 
Whether stuff may or may not change isn't the point; what it comes 
down to is referring to a variable itself vs. evaluating it.



-David

Re: === and array-refs

[David Green]

On 8/16/06, Dr.Ruud wrote:

I also wondered why a "simple" array (for example containing only value
type objects) whould not C<===> its copy.
But with .SKID that must be easy to handle.


That's what I was wondering that started off this thread.  I 
understand (more or less, I think), why it *does* work that way; I'm 
just not sure why we'd *want* it to work that way.


And maybe the answer is that in an ideal world, we wouldn't want it 
-- but in practice, that simply isn't feasible, so instead we get 
mutables and immutables and most of the time I'll just use "eqv" and 
everything will DWIM and it doesn't matter, and on the rare occasions 
when I really need to do === stuff, I'll just have to cope with it. 
(Or maybe subclass stuff with my own SKIDs to make it work the way I 
want, whatever.)


That's fine, trade-offs are a fact of life.  But nobody's actually 
said that, so I don't know whether I'm misunderstanding something 
still, whether I just haven't clearly explained what the heck I mean 
(or both, always a distinct possibility!).



-David

Re: === and array-refs

[Larry Wall]

On Wed, Aug 16, 2006 at 04:25:13PM +0200, Dr.Ruud wrote:
: Comparing strings in Perl5, using NFKD:
: 
: perl5 -MUnicode::Normalize -we '
:   ($\, $,) = ("\n", "\t") ;
:   $x = qq{Henry IV} ;
:   $y = qq{Henry \x{2163}} ;
:   print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
: # $x = NFKD $x ;
:   $y = NFKD $y ;
:   print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
: '
: Wide character in print at -e line 5.
:8   7   0
: 8   8   1
: 
: 
: How will the Str type do this?

That'd just be:

eqv($x, $y, :(NFKD $^s))

or some such, give or take a little notation in the signature to force MMD
to match a Str and coerce to NFKD.  This is mentioned in S03 as a subproblem
of the general canonicalization/collation problem.  It should be using the
same underlying semantics as

cmp($x, $y, :(NFKD $_))

or
sort :(NFKD $_), @strings;

Larry

Re: === and array-refs

[Dr.Ruud]

"Markus Laire" schreef:
> Dr.Ruud:
>> Markus Laire:

>>> my $x = 'Just Another';
>>> my $y := $x;
>>> $y = 'Perl Hacker';
>>>
>>> After this, both $x and $y contain the string "Perl Hacker", since
>>> they are really just two different names for the same variable.
>>> 
>>
>> So "$x === Sy" stil[l] holds.
>
> Exactly, and because of that $a === $b does NOT hold in my example.
> ($a would be "Two", $b would be "One")

Yes, sorry for my over-compact reply. Where Darren wrote:

  The difference between === and eqv is that, if you have 2 symbols, $a
  and $b, and $a === $b returns true, then that result is guaranteed to
  be eternal if you don't assign to either symbol afterwards.

I think he meant something like "to either symbol (or alias)".
But read S03 for an exacter description.


I also wondered why a "simple" array (for example containing only value
type objects) whould not C<===> its copy.
But with .SKID that must be easy to handle.


Comparing strings in Perl5, using NFKD:

perl5 -MUnicode::Normalize -we '
  ($\, $,) = ("\n", "\t") ;
  $x = qq{Henry IV} ;
  $y = qq{Henry \x{2163}} ;
  print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
# $x = NFKD $x ;
  $y = NFKD $y ;
  print qq{<$x>}, qq{<$y>}, length $x, length $y, $x eq $y ? 1 : 0 ;
'
Wide character in print at -e line 5.
   8   7   0
8   8   1


How will the Str type do this?

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: === and array-refs

[Markus Laire]

On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote:

I'll try saying what I meant differently here:

The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to either symbol [or other symbols
aliased to either] afterwards.

The idea is that, the degree to which === examines 2 variables to
consider them equal or not is only so far as they are immutable.  So
if you say "$foo = $bar", and then "$baz === $foo" returns true, then
a subsequent assignment to or type-allowed mutation of $bar won't
invalidate that $baz === $foo, but an assignment to $foo would.


IMHO the text "a subsequent assignment to or" is useless here because
I don't think any subsequent assignment to $bar could ever affect
$foo, even if they were mutable types:
   $bar = [1,2];
   $foo = $bar;
   ...
   $bar = 123; # This doesn't affect $foo

Of course, type-allowed mutation of $bar will affect $foo if $bar is
mutable type.

Still, thanks for clarification - I misunderstood what you meant with
"someone else holding another symbol".

--
Markus Laire

Re: === and array-refs

[Charles Bailey]

On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote:

At 11:42 AM +0300 8/16/06, Markus Laire wrote:
>On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
>>The difference between === and eqv is that, if you have 2 symbols, $a
>>and $b, and $a === $b returns true, then that result is guaranteed to
>>be eternal if you don't assign to either symbol afterwards.
>
>So do you mean that this code
>  $a = "One";
>  $b = "One";
>  $aa := $a;
>  say "Same before" if $a === $b;
>  $aa = "Two";
>  say "Same after" if $a === $b;
>would print
>  Same before
>  Same after
>because here I have "2 symbols, $a and $b, and $a === $b returns true"
>and I don't assign to either symbol afterwards - and you seem to be
>saying that only with mutable types like Array can you change the
>contents via another symbol ($aa here).

Thanks for catching that typo.

What you are saying with your above example is correct, and I knew
about that before, but it slipped my mind when I wrote my explanation
before.

I'll try saying what I meant differently here:

The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to either symbol [or other symbols
aliased to either] afterwards.


This is where the "eternal" part starts to confuse me (not picking on
your wording, but on the semantics).  For example, suppose I say

   <0> $a = "One";
   <1> $b = "One";
   <2> $aa := $a;
   <3> say "Immutidentical" if $a === $b;

As I understand it, I'll see "Immutidentical".

If I insert the C<$aa = "Two"> before line 3, then I won't see "Immutidentical".

What happens if I insert the C<$aa = "Two"> before line 255?  In other
words, can I rely on P6 to know at line 3 that there's an alias out
there by which C<$a> _might_ change without assignment later (i.e. the
guarantee that "$a and $b will remain the same unless you assign to
one" might be violated)?

What happens if the  C<$aa = "Two">  is in an eval-equivalent, so the
compiler can't see it before runtime?  Does the fact that the alias
exists violate the guarantee of immutability, or does the guarantee
just mean that at the instant the test is executed, both the contents
and container are the same?  (If the latter, I'm not sure in what
practical situations I'd use it.)

If I've -- once again -- totally missed the boat, please be patient.

--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu

Re: === and array-refs

[Markus Laire]

On 8/16/06, Dr.Ruud <[EMAIL PROTECTED]> wrote:

"Markus Laire" schreef:

> my $x = 'Just Another';
> my $y := $x;
> $y = 'Perl Hacker';
>
> After this, both $x and $y contain the string "Perl Hacker", since
> they are really just two different names for the same variable.
> 

So "$x === Sy" stil holds.


Exactly, and because of that $a === $b does NOT hold in my example.
($a would be "Two", $b would be "One")

--
Markus Laire

Re: === and array-refs

[Darren Duncan]

At 11:42 AM +0300 8/16/06, Markus Laire wrote:

On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote:

The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to either symbol afterwards.


So do you mean that this code
 $a = "One";
 $b = "One";
 $aa := $a;
 say "Same before" if $a === $b;
 $aa = "Two";
 say "Same after" if $a === $b;
would print
 Same before
 Same after
because here I have "2 symbols, $a and $b, and $a === $b returns true"
and I don't assign to either symbol afterwards - and you seem to be
saying that only with mutable types like Array can you change the
contents via another symbol ($aa here).


Thanks for catching that typo.

What you are saying with your above example is correct, and I knew 
about that before, but it slipped my mind when I wrote my explanation 
before.


I'll try saying what I meant differently here:

The difference between === and eqv is that, if you have 2 symbols, $a 
and $b, and $a === $b returns true, then that result is guaranteed to 
be eternal if you don't assign to either symbol [or other symbols 
aliased to either] afterwards.


The idea is that, the degree to which === examines 2 variables to 
consider them equal or not is only so far as they are immutable.  So 
if you say "$foo = $bar", and then "$baz === $foo" returns true, then 
a subsequent assignment to or type-allowed mutation of $bar won't 
invalidate that $baz === $foo, but an assignment to $foo would.


-- Darren Duncan

Re: === and array-refs

[Dr.Ruud]

"Markus Laire" schreef:

> my $x = 'Just Another';
> my $y := $x;
> $y = 'Perl Hacker';
>
> After this, both $x and $y contain the string "Perl Hacker", since
> they are really just two different names for the same variable.
> 

So "$x === Sy" stil holds.

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: === and array-refs

[Markus Laire]

On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote:

Both the === and eqv operators test the actual values of 2
containers, but that their semantics differ in regards to mutable
containers.  Given an immutable container/type, such as a number or
Str or Seq, both will always return true if the values are the same.
With a mutable container, such as an Array, only eqv will return true
if the value is the same, and === will return false for 2 containers
having the same value.

The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to either symbol afterwards.  For a
mutable type like an Array, === returns false on 2 containers because
it can't guarantee that someone else holding another symbol for
either container won't change its content, and so $a or $b could
change after we made the === test, without us causing that to happen,
and so for mutable types, === only returns true for 2 aliases,
because that is the most it can guarantee that they will be the same.
By contrast, eqv does not make the eternal guarantee, and works only
on snapshots, so eqv can safely deep-compare mutable types like
Arrays, since even if one of them changes afterwards, it doesn't
matter, since eqv only guaranteed them equal for that point in time
when it executed.


So do you mean that this code
 $a = "One";
 $b = "One";
 $aa := $a;
 say "Same before" if $a === $b;
 $aa = "Two";
 say "Same after" if $a === $b;
would print
 Same before
 Same after
because here I have "2 symbols, $a and $b, and $a === $b returns true"
and I don't assign to either symbol afterwards - and you seem to be
saying that only with mutable types like Array can you change the
contents via another symbol ($aa here).

But according to S03 this would only print "Same before", because the
assigment to $aa would change $a

A new form of assignment is present in Perl 6, called binding, used in
place of typeglob assignment. It is performed with the := operator.
Instead of replacing the value in a container like normal assignment,
it replaces the container itself. For instance:

   my $x = 'Just Another';
   my $y := $x;
   $y = 'Perl Hacker';

After this, both $x and $y contain the string "Perl Hacker", since
they are really just two different names for the same variable.


--
Markus Laire

Re: === and array-refs

[Darren Duncan]

It seems to me that there is some confusion being given in this 
thread and the most recent parts of its predecessor (which can lead 
to FUD in the wrong hands), so I'll briefly try to clear it up, as I 
would like to think I understand the issues.


At 2:51 PM -0600 8/15/06, David Green wrote:

On 8/14/06, Smylers wrote:

David Green writes:

 I guess my problem is that [1,2] *feels* like it should === [1,2].
 You can explain that there's this mutable object stuff going on, and I
 can follow that (sort of...), but it seems like an implementation
 detail leaking out.


There are no implementation details leaking out, but rather we are 
just dealing with the declared interface behaviour of different types 
and operators.


I agree that [EMAIL PROTECTED] should be distinct from [EMAIL PROTECTED] -- in the former 
case, we're deliberately taking a reference to the @orig variable. 
What I don't like is that [EMAIL PROTECTED] is distinct from [EMAIL PROTECTED] -- sure, 
I'm doing something similar to Array->new(1,2) followed by another 
Array->new(1,2), but I still want them to be the same, just as I 
want Str->new("foo") to be the same as Str->new("foo").  They're 
just constants, they should compare equally regardless of how I 
created them.  (And arrays should work a lot like strings, because 
at some conceptual level, a string is an array [of characters].)


You are right, but we have both Seq and Array types, so depending 
which one you use, you want either the === or eqv operators to do 
what you want.  There is no reason that === should say 2 Array are 
equal; we have eqv for that, or use 2 Seq instead of 2 Array if you 
want === to return true on the same values.


So, (1,2) always === and eqv (1,2), but [1,2] only eqv [1,2] and 
[1,2] generally !=== [1,2].


First of all, in Perl 6, there are no separate "arrays" and "array 
refs"; we simply have the 'Array' type, which is treated as a lump on 
its own.


More generally, there are no "reference" types in Perl 6.  We do have 
a concept of multiple symbols being aliases for the same container, 
and they only come to be that way if they are explicitly aliased, 
such as with "$a := $b"; only in those cases, the operator =:=, which 
sees if 2 symbols represent the same container, would return true. 
If you create 2 values separately and don't explicitly alias them 
like that, =:= will return false, even if the 2 containers have 
appearances of the same value.


Both the === and eqv operators test the actual values of 2 
containers, but that their semantics differ in regards to mutable 
containers.  Given an immutable container/type, such as a number or 
Str or Seq, both will always return true if the values are the same. 
With a mutable container, such as an Array, only eqv will return true 
if the value is the same, and === will return false for 2 containers 
having the same value.


The difference between === and eqv is that, if you have 2 symbols, $a 
and $b, and $a === $b returns true, then that result is guaranteed to 
be eternal if you don't assign to either symbol afterwards.  For a 
mutable type like an Array, === returns false on 2 containers because 
it can't guarantee that someone else holding another symbol for 
either container won't change its content, and so $a or $b could 
change after we made the === test, without us causing that to happen, 
and so for mutable types, === only returns true for 2 aliases, 
because that is the most it can guarantee that they will be the same. 
By contrast, eqv does not make the eternal guarantee, and works only 
on snapshots, so eqv can safely deep-compare mutable types like 
Arrays, since even if one of them changes afterwards, it doesn't 
matter, since eqv only guaranteed them equal for that point in time 
when it executed.


It is important for some applications to distinguish whether the 
result of an equivalence test will be valid eternally or not, and 
hence we have multiple analagous types and multiple equality tests, 
where pairwise they distinguish eternally vs snapshot.  We can say 
exactly what we mean, and it is unambiguous, which is a GOOD thing.


-- Darren Duncan

Re: $/ and $! should be env (and explanation of env variables)

[TSa]

HaloO,

happy new year to Everybody!

Luke Palmer wrote:

Env variables are implicitly passed up through any number of call
frames.


Interesting to note that you imagine the call chain to grow upwards
where I would say 'implicitly passed down'. Nevertheless I would
also think of upwards beeing the positive direction where you find
your CALLER's environment with a $+ twigil var or where the $^ twigiled
vars come from ;)

Since exception handling is about *not* returning but calling your
CALLER's CATCH blocks in the same direction as the environments are
traversed there should be some way of navigating in the opposite
direction of these environments up---or down---to the point where
the error occured. Could this be through $- twigil vars? Or by
having an @ENV array that is indexed in opposite call direction yielding
this frame's %ENV? Thus @ENV[-1] would nicely refer to the actual
error environment. And [EMAIL PROTECTED] tells you how far away you are catching
the error. But this would not allow to retrieve non-exceptional
environmental data frames unless forward indexing from @[EMAIL PROTECTED] and
beyond is supported.

Well, alternative we could have an ERR namespace. BTW, how is the
object data environment handled? Is there a SELF namespace? How much
of that is automagically accessible in CATCH blocks?



$/ was formerly lexical, and making it environmental, first of all,
allows substitutions to be regular functions:

$foo.subst(rx| /(.*?)/ |, { "$1" })

Since .subst could choose bind $/ on behalf of its caller.


Just let me get that right. Whatever $foo contains is stringyfied
and passed as $?SELF to .subst with $_ as a readonly alias?
Then the string is copied into an 'env $/ is rw' inside subst and
handed over to some engine level implementation routine which actually
performs the subtitution. Finally .subst returns the value of this $/.
Well, and for an in-place modification of $foo the call reads
$foo.=subst(...), I guess?

Or was the idea to have three declarations

  env $_ is rw = CALLER<$_>; # = $?SELF in methods?
  env $/ is rw = CALLER<$/>; # = $?SELF in rules?
  env $! is rw = undef;  # = CALLER<$!> when exceptional

beeing implicitly in effect at the start of every sub (or block)?
Thus subst could just modify $+/ without disturbing CALLER<$foo>
which might actually be invisible to subst?



It is also aesthetically appealing to have all (three) punctuation
variables being environmental.


And it clears up the strange notion of lexical my-vars :)
I hope lexical now *only* means scanning braces outwards on
the source code level with capturing of state in the (run)time
dimension thrown in for closure creation, lazy evaluation etc.

Talking about lazy evaluation: does it make sense to unify
the global $*IN and $*OUT with lazy evaluation in general?
That is $OUT is where yield writes it value(s) to and $IN
is for retrieving the input. Iteration constructs automatically
stall or resume coroutines as needed.
--

Re: ~ and + vs. generic eq

[TSa]

HaloO,

Yuval Kogman wrote:

No, the role installs homogenious targets into the generic
binary-MMD comparator which I think is called eqv.



Err, why? We already have that with regular MMD semantics.

role Num {
multi &*infix: ($x:, Num $y) { $x == $y }
}


What you mean is double dispatch, cascading, delegation or what ever.
I had the two juxtapositions of

   $x eqv $y

versus

   $x &ee $y  # or even $x $ee $y when $ee is a coderef

in mind. In the latter case you a get a complicated mix of parsing that
in the first place and generating code for a three invocant anonymous
dispatch or whatever it is. I mean with *no* : in the definition.

   multi &*infix: ($lhs, Compare &comp, $rhs) {...}

BTW, is that now valid syntax? I thought there is no & sigil
but one of the two keywords sub or method:

   multi sub *infix: ($lhs, Compare &comp, $rhs) {...}



I'm not sure if I get you right, but I think we agree that
there should be only one comparer for a certain type/class.
Everything else is nonsense. I mean apples should know how
to eqv to other apples and oranges with oranges. MMD enters
the picture only if you want to compare apples with oranges.
By color, by weight, as fruits in general, etc.



Comparing apples with oranges should do two equivalent MMD lookups
on coercion, one of apples to oranges, the other of oranges to
apples (unless there is an MMD compare between apples and oranges
already), and if they are equivalent then there is an error.


Sorry, I don't understand what an "MMD lookup on coercion" should be?
Do you think of eqv as a simple two parameter sub that *single* dispatches
first on the $one then on the $other arg with the respective non-invocant
as parameter and then xor's and negates the results for consistency?

  sub eqv ($one, $other --> Bit)
  {
  # .compare_to:(Object: Object --> Bit) note the single invocant!
  return !($one.compare_to($other) ^^ $other.compare_to($one));
  }

Apart from the fact that somehow two types are involved I don't
see MMD in that. To me a method's name is a concept that is
realized differently for different types of arguments. At hand
we are discussion the well known problem of generic equality
versus more specific equalities of strings, numbers or objects/refs.

And now Perl6 addresses the ternary problem of remaining generic
with respect of the infix operator name or precise concept such
that it ends up comparing numbers numerically, strings textually,
colors colorfully plus all the mixed cases while at the same time
keeping compatible to Perl5's operator semantics. The first problem
you face in this quest is naming the beast---and the three letters
'eqv' aren't it to me because variable stuff in Perl is expressed
with sigils. I'm not sure if the above discribed extreme case

if $x $ee $y { say "Hurray, we have equality" }

has a chance not to end up with a 'two terms in a row' parse
error.



And I'm unsure if

  $x (+&eqv)() $y

works even when prefix:<+>:(Comparor) exists and returns a
numeric Comparor. But named params next to the operator could work


I think it should even without the parens... isn't the & sigil
enough to make it clear? & is just like $ in this respect


Which parens? The ones around (+&eqv) or the trailing call op ()?
Note that the precedence of postfix () is higher than prefix +.
And +&eqv might simply mean a numerified coderef and not a dispatched
call of prefix + where the returned value is type checked at runtime
for infix operator type compatibility. And then after this successfull
type check this returned operator is MM dispatched on ($x,$y).
And I can increase the challenge level easily to

  my $o := &eqv; # or with \&eqv ?

  if $x +$o $y {...} # parseable without type info about $o?

Just to mention one possible alternate interpretation, imagine prefix +
on $o returning a postfix op that given $x returns yet another
prefix op that given $y returns a value that is booleanized by
the if which then executes or skips the trailing block correspondingly.
That is with explicit parens we would get:

  if (($x(+$o))($y)) {...} # parseable?

That is like parsing the sentence: "Time flies like an arrow",
and asking yourself: "What are time flies and why do they like arrows?"

If the above works, I guess variability against the if will not parse?

  sub foo ($i, $x, $y, $z)
  {
 $i $x $y $z { say "something got us here" }
  }

Or does it? Actually sigiling i and y with & instead of $
reduces the possibilities a lot and might even imply to
associate the trailing block literal with &i and default
&y to an infix op. Thus a call

  foo( &*if, 42, &infix:<==>, 42);

will indeed say "something got us here"---that something
beeing the numeric equality of 42 and 42 :)

With some parsing magic thrown in, I would still propose to
make junctions in the style of the above foo such that

  if any( $points > @highscores ) { say "a new entry!" }

means what auto-threaded ($points == any(@highscores)) means
now, but makes

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Wed, Sep 21, 2005 at 13:53:20 +0200, TSa wrote:
> HaloO Yuval,
> 
> you wrote:
> >On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote:
> >>  role Object does Compare[Object, =:=]
> >>  role Numdoes Compare[Num, ==]
> >>  role Strdoes Compare[Str, eq]
> >What is the implication of from the perspective of the person using
> >Object, Num and Str?
> >Do they have one unified comparator?
> 
> No, the role installs homogenious targets into the generic
> binary-MMD comparator which I think is called eqv.

Err, why? We already have that with regular MMD semantics.

role Num {
multi &*infix: ($x:, Num $y) { $x == $y }
}

> That's an interesting question which is related to my retention to metric
> MMD. We must distinguish homogenous from heterogenous comparisons.  My
> role Compare from above ensures that the comparor can be deduced from the
> unique (super)type of the two values to be compared. As such the comparator
> indirectly is class or type specific. The heterogenous cases however have to
> fallback to "real" MMD. Now metric MMD could spoils this approach by picking
> the "wrong" eqv target even though a proper homogenous target were
> available!

Then MMD must be fixed, as I've argued several times before.

MMD cannot work unless it does what almost everyone means and
complains when there is no obvious way.

What you're describing is a problem that a broken (by this
definition) MMD system can provide.

> I'm not sure if I get you right, but I think we agree that
> there should be only one comparer for a certain type/class.
> Everything else is nonsense. I mean apples should know how
> to eqv to other apples and oranges with oranges. MMD enters
> the picture only if you want to compare apples with oranges.
> By color, by weight, as fruits in general, etc.

Comparing apples with oranges should do two equivalent MMD lookups
on coercion, one of apples to oranges, the other of oranges to
apples (unless there is an MMD compare between apples and oranges
already), and if they are equivalent then there is an error.

> It seems that the Code type is still some kind of second class
> citizen in Perl6 because you can't nicely apply prefix ops to
> pending invocations without some help from the meta categories.
> And I'm unsure if
> 
>$x (+&eqv)() $y
> 
> works even when prefix:<+>:(Comparor) exists and returns a
> numeric Comparor. But named params next to the operator could work

I think it should even without the parens... isn't the & sigil
enough to make it clear? & is just like $ in this respect

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me tips over a cow: neeyah!!



pgpwtz063b7N7.pgp
Description: PGP signature

Re: ~ and + vs. generic eq

[TSa]

HaloO Yuval,

you wrote:

On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote:

  role Object does Compare[Object, =:=]
  role Numdoes Compare[Num, ==]
  role Strdoes Compare[Str, eq]



What is the implication of from the perspective of the person using
Object, Num and Str?

Do they have one unified comparator?


No, the role installs homogenious targets into the generic
binary-MMD comparator which I think is called eqv.



If so, this sounds like you are subverting MMD with some odd
currying of the 'compare' method (whatever it's name may be)
provided by the Compare role, instead of relying on the already
existing semantics of MMD dispatch to give you the same name for
several, superficially same meanings.


The problem with equality checking is that there are several
notions of equality :) And if you include them into the set of
types used in the dispatch decision you end up with the very
unspecific :( ::X, ::Y, Code.does(Compare) --> bool ) type and
the difficulty of defining a nice call syntax for it!



The driving idea here is that the syntactical choice of the programmer
amounts to a type preference of the Comparer subtype.



Do you mean on a per class or per comparison basis?


That's an interesting question which is related to my retention to metric
MMD. We must distinguish homogenous from heterogenous comparisons.  My
role Compare from above ensures that the comparor can be deduced from the
unique (super)type of the two values to be compared. As such the comparator
indirectly is class or type specific. The heterogenous cases however have to
fallback to "real" MMD. Now metric MMD could spoils this approach by picking
the "wrong" eqv target even though a proper homogenous target were
available!



I think that exceptions from the class perspective should not be
done by parametrising the quality role, but overriding it, and that
from the per comparison perspective we need to say either:

coerce_to_other_type($value)
generic_equality
coerce_to_other_type($other_value)


I'm not sure if I get you right, but I think we agree that
there should be only one comparer for a certain type/class.
Everything else is nonsense. I mean apples should know how
to eqv to other apples and oranges with oranges. MMD enters
the picture only if you want to compare apples with oranges.
By color, by weight, as fruits in general, etc.



and being an operator rich language we can specificate the generic
comparator to make things a bit more fun like I proposed:

$x +eqv $y;
$x ~eqv $y;


It seems that the Code type is still some kind of second class
citizen in Perl6 because you can't nicely apply prefix ops to
pending invocations without some help from the meta categories.
And I'm unsure if

  $x (+&eqv)() $y

works even when prefix:<+>:(Comparor) exists and returns a
numeric Comparor. But named params next to the operator could work

  $x eqv:num $y

and plain eqv could actually mean binary eqv:mmd on the lhs and rhs.



Ofcourse, I think that s/eqv/==/;, but everyone hates that.


Well, I wonder if ($x eqv $y) is the same as !($x xor $y) and
as such we just lack a high precedence correspondence to ^^ :)

H, the Mathematician in me sees <==> ...
But wouldn't that mean that ^^ should be  ...
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote:
> HaloO,
> 
> Damian Conway wrote:
> >Just a meta-point...one thing we really do need to be careful of is not 
> >ending up with 17 different "equality" operators (like certain languages I 
> >shall refrain from naming). So far we're 
> >contemplating:
> >=:=
> >~~
> >==
> >eq
> >eqv
> >equals
> >Do we really need even that many???
> 
> My opinion is there should be a role Compare that takes a
> Comparer as one of it's parameters. For the above we have
> in pseudo syntax e.g.:
> 
>role Object does Compare[Object, =:=]
>role Numdoes Compare[Num, ==]
>role Strdoes Compare[Str, eq]

What is the implication of from the perspective of the person using
Object, Num and Str?

Do they have one unified comparator?

If so, this sounds like you are subverting MMD with some odd
currying of the 'compare' method (whatever it's name may be)
provided by the Compare role, instead of relying on the already
existing semantics of MMD dispatch to give you the same name for
several, superficially same meanings.

> The driving idea here is that the syntactical choice of the programmer
> amounts to a type preference of the Comparer subtype.

Do you mean on a per class or per comparison basis?

I think that exceptions from the class perspective should not be
done by parametrising the quality role, but overriding it, and that
from the per comparison perspective we need to say either:

coerce_to_other_type($value)
generic_equality
coerce_to_other_type($other_value)

like:

+$x eqv +$y;

or:

~$x eqv ~$y;

and being an operator rich language we can specificate the generic
comparator to make things a bit more fun like I proposed:

$x +eqv $y;
$x ~eqv $y;

Ofcourse, I think that s/eqv/==/;, but everyone hates that.


> I fully agree that the number of standard Comparers should be kept
> small---that is close to three, not counting ~~ as a Comparer but
> as (the only) Matcher.

I'm glad that you guys think so too =)

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: : neeyah!



pgp2FmxiAKkJ3.pgp
Description: PGP signature

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Wed, Aug 24, 2005 at 16:57:30 +1000, Damian Conway wrote:

This is what the operators mean to me:

>   =:=
 
The right side and the left are the same thing, in the sense that:

$x =:= $y; # if this is true
$x.mutating_method; # and one side is changed
$x =:= $y; # then this will always still be true

This may describe either truely the same space in memory, or some
sort of proxying. One scenario under which I think it's OK if they
are not the same location in memory is if I have two proxy handles
into the same remote object. They represent the same object, and are
randomly interchangable in any point in the control flow.

>   ~~

Does the right side describe the left side? Is the left side "like"
what the right side defines?

This is variadic depending on the right side, WRT to the shape and
type of the right side. It's truely a smart (polymorphic, dwimmy)
match (the right side can describe any number of values) operator,
and not equality in any sense.

>   ==
>   eq
>   eqv
>   equals

For all of these, The two are equal - the same value, but not
necessarily the same thing:

$x == $y; # if this is true (assume generic equality)
$x.mutating_method; # and one side is changed
$x == $y; # this might not be true anymore

As I see it ==, eq, eqv and equals are overly verbose and redundant
options for checking this same property WRT to the values involved.

When we want to be truely sure that we are comparing the two values
on a certain dimension of equality (numeric, stringwise or natural
equality, as denoted by ==, eq and equals (not eqv if the previous
posts in this thread are used)) then we force it anyway.

In perl 5 when I want my code to be readable I don't say

if (@array == @other)

because I find that confusing.

I try to remember to say:

if (scalar(@array) = scalar(@array))

so that it's obvious I'm comparing a coercion of the array's value.

Furthermore, I find even this repulsive... What kind of scalar
value?

Perl 6 has the ability to make this obvious by using the now
standard prefixes:

~   - as a string
+   - as a number
?   - as a boolean

all of which are special cases of "natural" equality.

When I say

if ([EMAIL PROTECTED] == [EMAIL PROTECTED])

it's more obvious that I'm treating these as numerical values
(I may be tempted to say @array.elems if i really want to be clear,
but that's besides the point).

If I say @array == @other, it's clear to someone ***WITH A PERL 5
BACKGROUND** that i'm forcing the array into numerical context, and
then comparing that instead.

I for one know that I'll always write

if (... eqv ...)

in perl 6, to avoid my tendency to compare strings and objects as
numbers.

I deeply regret that people from other language will mock me for
having such an ugly operator, and that everyone who doesn't care
enough will use == in a way that is broken 5% of the time.

I regret most deeply of all that the amount inertia that == and eqv have is
so imbalanced and unfair, that no one will implement 'eqv' for
generic equality in their own classes, and we'll have something that
looks like 'use overload' in perl 5.

Oh well.

> Do we really need even that many???

At the risk of sounding like a broken record, i think not

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: : neeyah!



pgpEr3BiOWrFY.pgp
Description: PGP signature

Re: ~ and + vs. generic eq

[TSa]

HaloO,

Damian Conway wrote:
Just a meta-point...one thing we really do need to be careful of is not 
ending up with 17 different "equality" operators (like certain languages 
I shall refrain from naming). So far we're contemplating:


=:=
~~
==
eq
eqv
equals

Do we really need even that many???


My opinion is there should be a role Compare that takes a
Comparer as one of it's parameters. For the above we have
in pseudo syntax e.g.:

  role Object does Compare[Object, =:=]
  role Numdoes Compare[Num, ==]
  role Strdoes Compare[Str, eq]

  ::eqv ::= none(=:=); # non-Object Comparer

The difficult part is the definition of inhomogenious cases
by means of MMD unless we can form supertypes of Comparers
easily:

  role Foo does Compare[Object|Num, =:= | ==]

or with set syntax and a bit de-sugared on the op:

  role Foo does Compare[(Object,Num), (&infix:<=:=>, &infix:<==>)]


The driving idea here is that the syntactical choice of the programmer
amounts to a type preference of the Comparer subtype. I fully agree
that the number of standard Comparers should be kept small---that is
close to three, not counting ~~ as a Comparer but as (the only) Matcher.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Tue, Aug 23, 2005 at 16:32:37 -0700, Larry Wall wrote:
> Hmm, well, I don't think >>&op<< is valid syntax, but you did say
> "semantics", so I can't criticize that part.  :-)

What is >><<, btw?

Is it

&circumfix:{'>>','<<'} (Code &op --> Code); # takes some code, returns 
a listop

or
&precircumfix:{'>>','<<'} (Code &op, [EMAIL PROTECTED] --> List);

> I don't know how close ~~ and eqv will end up.  There are some
> differences in emphasis, and when two operators get too much like each
> other, I tend to add more differences to make them inhabit different
> parts of the solution space.  One current difference is that, despite
> the symmetry of ~~, it's not actually a symmetrical operator much of
> the time, such as when matching values to rules.  ~~ is intended to
> be heavily dwimmical, so it's allowed to do various kinds of abstract
> coercions to figure out some mystical "good enough" quotient.  But eqv
> on the other hand should probably be false in asymmetrical situations.
> The implementation of ~~ may delegate to eqv in certain symmetrical
> situations, of course.

Right... Magic is defined in the "base" definitions of ~~:

&infix:<~~> ($x, Rule $r) { ... }
&infix:<~~> ($x, Code &test) { code($x) }

And so on and so forth, and then it is extended by the extender to
make cool aggregate operations, but even this doesn't have to be the
same for ~~ and eqv, it's just that eqv should have good builtins
for collections, is all.

> should say "true", since those are the same values, and they can't
> change.  However, in Perl-5-Think, [1,2,3] produces mutable arrays,
> so unless we come up with some kind of fancy COW for [1,2,3] to be
> considered immutable until someone, er, mutes it, I think eqv would
> have to return false, and consider two such objects to be different
> values (potentially different if not actually different).

Well, when I use it as

if (@array eqv [1, 2, 3]) {

}

I think it's obvious that I'm checking "what is the value right
now", and ditto when I say

my $str = "foo";
$hash{$str} = 1;
$str ~= "bar";
$hash{$str}; # not the same

Arguably use of an array as a hash key is using a reference to a
container, and use of a scalar as a hash key is using the value
inside a container, so in a sense the hash key didn't change when I
appended the string, but this distinction is subtle and mostly an
implementation detail.


> It would be possible to declare %hash some way that forces a "snapshot"
> via some kind of serialization or other, but then it gets hard to keep
> the identity around.  Then the question arises how we doctor
> 
> if [1,2,3] eqv [1,2,3] { say "true" } else { say "false" }

eqvs! it pronounces very well: 'eekyoovies'. Try it:

if 1 2 3 eekyooviesses 1 2 3 say true, otherwise say false

It's fun, but I hate it even more than eqv ;-)

> to do the same snapshot comparison.  Arguably ~~ could do it, since it's
> explicitly *not* about identity.
> 
> if [1,2,3] ~~ [1,2,3] { say "true" } else { say "false" }

But ~~ is not "is the same" it's "matches". This is also true, and
not what I want eqv for:

if [1, 2, 3] ~~ [code { 1 }, rx/\d+/, Num] { say "true" } else { say 
"false" }

> Or we could have a more explicit way of doing whatever it is that the
> snapshot hash does to each argument.
> 
> if [1,2,3].snap eqv [1,2,3].snap { say "true" } else { say "false" }

I think the opposite is better, make snapshotting by default, and
mutable value equality false by saying

[1, 2, 3] eqv [1, 2, 3] :always # or :forever

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah



pgpkL3zKnNBEK.pgp
Description: PGP signature

Re: ~ and + vs. generic eq

[Damian Conway]

Larry wrote:


Or we could have a different operator that coerces like == and eq, only
via .snap:

if [1,2,3] equals [1,2,3] { say "true" } else { say "false" }

(Actual name negotiable, of course).  The advantage of the latter approach
is that you can say

@foo >>equals<< @bar

and the .snaps are automatically distributed.  Otherwise you'd have to say

@foo<<.snap >>eqv<< @bar<<.snap

which is a pain.  On top of which, equals doesn't actually have to
implemented in terms of .snap--it could just compare the current
values of the mutable objects directly.  (Just as =:= doesn't have
to be implemented in terms of .id.)


Just a meta-point...one thing we really do need to be careful of is not ending 
up with 17 different "equality" operators (like certain languages I shall 
refrain from naming). So far we're contemplating:


=:=
~~
==
eq
eqv
equals

Do we really need even that many???

Damian

Re: ~ and + vs. generic eq

[Larry Wall]

On Wed, Aug 24, 2005 at 12:43:46AM +0300, Yuval Kogman wrote:
: On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
: > On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
: > :   "10" == "10"; # dispatches to Str, due to better match
: > 
: > Nope, that will continue to coerce to numeric comparison.  The design
: > team did in fact consider pure "equivalence" MMD dispatch of == in
: > the last meeting, but rejected it in favor of "eqv"
: 
: BTW, regardless of whether it's called 'eqv' or '==', the semantics
: shared between the MMD variants of ~~ and eqv as proposed in the
: bottom of the message are not utter crap, right?

Hmm, well, I don't think >>&op<< is valid syntax, but you did say
"semantics", so I can't criticize that part.  :-)

Not that the rest of what I say amounts to criticism.  More just thinking
in your general direction.

I don't know how close ~~ and eqv will end up.  There are some
differences in emphasis, and when two operators get too much like each
other, I tend to add more differences to make them inhabit different
parts of the solution space.  One current difference is that, despite
the symmetry of ~~, it's not actually a symmetrical operator much of
the time, such as when matching values to rules.  ~~ is intended to
be heavily dwimmical, so it's allowed to do various kinds of abstract
coercions to figure out some mystical "good enough" quotient.  But eqv
on the other hand should probably be false in asymmetrical situations.
The implementation of ~~ may delegate to eqv in certain symmetrical
situations, of course.

Another difference in emphasis is that eqv is intended to equate values
(one of the reasons for the 'v') that would be treated as equal when used
as keys of an object hash.  Now the funny thing about an object hash is
that you don't ever want to hash based on a mutable value.  Ordinary
value types are immutable, so this 42 is the same as that 42 over there.
So we have

$a = 42;
$b = 42;
$a eqv $b   # always true
$a =:= $b   # might be true

The =:= operator always compares object identities, even if the
objects want to pretend to be values.  So eqv lets them pretend,
while =:= doesn't.  But for objects that don't want to pretend to be
values, eqv can delegate to =:=.

On the other hand, it's not clear whether eqv (and by extension hashes)
should take "snapshots" of mutable values.  That is, it's not clear
whether this should say "true true" or "false false":

my %hash is shape(Object);

%hash{ [1,2,3] } = 1;
if exists %hash{ [1,2,3] } { say "true" } else { say "false" }
if [1,2,3] eqv [1,2,3] { say "true" } else { say "false" }

But whatever it says, I think it should say the same thing both times.
Certainly if we had Pythonic immutable tuples

if (1,2,3) eqv (1,2,3) { say "true" } else { say "false" }

should say "true", since those are the same values, and they can't
change.  However, in Perl-5-Think, [1,2,3] produces mutable arrays,
so unless we come up with some kind of fancy COW for [1,2,3] to be
considered immutable until someone, er, mutes it, I think eqv would
have to return false, and consider two such objects to be different
values (potentially different if not actually different).

It would be possible to declare %hash some way that forces a "snapshot"
via some kind of serialization or other, but then it gets hard to keep
the identity around.  Then the question arises how we doctor

if [1,2,3] eqv [1,2,3] { say "true" } else { say "false" }

to do the same snapshot comparison.  Arguably ~~ could do it, since it's
explicitly *not* about identity.

if [1,2,3] ~~ [1,2,3] { say "true" } else { say "false" }

Or we could have a more explicit way of doing whatever it is that the
snapshot hash does to each argument.

if [1,2,3].snap eqv [1,2,3].snap { say "true" } else { say "false" }

Or we could have a different operator that coerces like == and eq, only
via .snap:

if [1,2,3] equals [1,2,3] { say "true" } else { say "false" }

(Actual name negotiable, of course).  The advantage of the latter approach
is that you can say

@foo >>equals<< @bar

and the .snaps are automatically distributed.  Otherwise you'd have to say

@foo<<.snap >>eqv<< @bar<<.snap

which is a pain.  On top of which, equals doesn't actually have to
implemented in terms of .snap--it could just compare the current
values of the mutable objects directly.  (Just as =:= doesn't have
to be implemented in terms of .id.)

Larry

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Tue, Aug 23, 2005 at 10:28:01 -0700, Larry Wall wrote:
> On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
> : "10" == "10"; # dispatches to Str, due to better match
> 
> Nope, that will continue to coerce to numeric comparison.  The design
> team did in fact consider pure "equivalence" MMD dispatch of == in
> the last meeting, but rejected it in favor of "eqv"

BTW, regardless of whether it's called 'eqv' or '==', the semantics
shared between the MMD variants of ~~ and eqv as proposed in the
bottom of the message are not utter crap, right?

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me does a karate-chop-flip: neeyah!!



pgpXv1WO6rB8S.pgp
Description: PGP signature

Re: ~ and + vs. generic eq

[Larry Wall]

On Tue, Aug 23, 2005 at 06:19:33PM +0300, Yuval Kogman wrote:
:   "10" == "10"; # dispatches to Str, due to better match

Nope, that will continue to coerce to numeric comparison.  The design
team did in fact consider pure "equivalence" MMD dispatch of == in
the last meeting, but rejected it in favor of "eqv", which has the
benefit of looking more Huffmanly abstract to Perl 5 and C programmers.
Otherwise we lose the main point of being an operator-rich language,
which is to use the operators to drive coercion in the common cases
instead continually casting between strings and numbers.

Larry

Re: ~ and + vs. generic eq

[Yuval Kogman]

On Tue, Aug 23, 2005 at 18:15:07 +0200, Ingo Blechschmidt wrote:
> sorry, I've some problems with this proposal:
> 
> == has always meant numeric equality in Perl and I'd like it to stay
> that way.

For "simple" values like numbers and strings == is numberic, because
it's affinity to it.


> > "10" == 10; # dispatched to Num, by means of coercion (== has some
> > affinity to it for backwards compatibility)


I guess the difference is that this will fallback to dispatching to
strings if "10" can't be numified.

I think what sets perl 6 apart from perl 5 is that it's 95% as
optimized for "simple" values as perl 5 was, but a magnitude times
better for complex types (first class functions, better objects),
and in this sense generic equality is a place I find the current
spec lacking.

> More importantly, the distinction between +== and ~== is far too subtle,
> I think -- the two long =s kind of hide the +~?. You have to look more
> carefully to see the distinction between +== and ~==; == vs. eq is much
> more apparent, IMHO.

Arguably it should only matter when it's explicitly stated, so in
this case I think your argument is very strong. The only difference
is that I don't feel that ~== and +== are very close to == visually,
and although they are hard to distinguish, they do stand apart from
just bare ==.

> 
> Oh and +== isn't as good huffmanized as == is.

99% of the time you should use == for numbers anyway... It's
unambiguous.

> > The "matchic MMD generator" in the prelude, that makes the complex
> > set of rules found in s04 should simply apply to any infix operator
> > (and should be applied in the prelude to ~~, as well as ==), so that
> > ~~ and == on collections are defined with the same aggregate
> > semantics, but MMD ~~ or == applies to the nested elements in the
> > same "shape":
> > 
> > sub extend_comparators (&op) {
> [...]
> 
> I think I like that idea, although I have to admit that I might have not
> understood it fully.
> 
> I wonder whether it's possible to use an adverbial modifier to specify
> the comparator:
> 
> say @foo ~~ @bar;  # is really
> say @foo ~~ @bar :comparator{ $^a ~~ $^b };
> 
> say @foo ~~ @bar :comparator{ $^a eq $^b };
> say @foo ~~ @bar :comparator{ $^a == $^b };

In this example I would say

my sub comparator ($a, $b) { .. your comparison here };
Prelude::extend_comparators(&comparator);

say comparator(@foo @bar);

and the name "comparator" could be a lexically scoped &infix:<~~> just the
same.

It's not as short, but I'm sure an evil macro could be cooked up if
it recurrs.

We can even specify

multi &infix:<~~> (Any $a, Any $b, :&comparator) { # what is the
# syntax for mandatory positionals nowadays?
my &augmented = &comparator; # a copy
Prelude::extend_comparators(&augmented);
&augmented($a, $b);
}

And have your interface wrap around this behavior.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me beats up some cheese: neeyah!



pgp9aYZ5J4EQD.pgp
Description: PGP signature

Re: ~ and + vs. generic eq

[Ingo Blechschmidt]

Hi,

Yuval Kogman wrote:
> I think this is more consistent, and just as useful:
> 
> 10 == 10; # dispatches to num
> "10" == 10; # dispatched to Num, by means of coercion (== has some
> affinity to it for backwards compatibility) "10" == "10"; # dispatches
> to Str, due to better match "10.0" == "10"; # unlike perl 5 this is
> false "10.0" +== "10"; # but this is true
> 10 ~== 10; # like eq

sorry, I've some problems with this proposal:

== has always meant numeric equality in Perl and I'd like it to stay
that way.

More importantly, the distinction between +== and ~== is far too subtle,
I think -- the two long =s kind of hide the +~?. You have to look more
carefully to see the distinction between +== and ~==; == vs. eq is much
more apparent, IMHO.

Oh and +== isn't as good huffmanized as == is.

> The "matchic MMD generator" in the prelude, that makes the complex
> set of rules found in s04 should simply apply to any infix operator
> (and should be applied in the prelude to ~~, as well as ==), so that
> ~~ and == on collections are defined with the same aggregate
> semantics, but MMD ~~ or == applies to the nested elements in the
> same "shape":
> 
> sub extend_comparators (&op) {
[...]

I think I like that idea, although I have to admit that I might have not
understood it fully.

I wonder whether it's possible to use an adverbial modifier to specify
the comparator:

say @foo ~~ @bar;  # is really
say @foo ~~ @bar :comparator{ $^a ~~ $^b };

say @foo ~~ @bar :comparator{ $^a eq $^b };
say @foo ~~ @bar :comparator{ $^a == $^b };


--Ingo

-- 
Linux, the choice of a GNU | "The future is here. It's just not widely
generation on a dual AMD   | distributed yet."  -- William Gibson  
Athlon!|

Re: $ @ and %

[Larry Wall]

On Tue, Nov 30, 2004 at 04:41:00AM +0300, Alexey Trofimenko wrote:
: >P.P.P.S. If answer on my "why?" would be "just because!" I would take it  
: >silently.
: 
: yes, answer was as I predicted above. I promised..

You have a funny idea of what "silently" means.  :-)

: ..but:
: >As far as I understood, arrays and hashes, and references them are much  
: >more similar in Perl6 than it was in Perl5.
: >
: >F.e. we have @a and $a = [EMAIL PROTECTED];
: >the same:
: >
: > push @a,1,2,3   push $a, 1,2,3
: > $b = @a $b = $a
: >(?)  say "@a[]"  say "$a[]"
: >(?)  myfunc( [EMAIL PROTECTED])myfunc ( *$a)
: >
: >...
: 
: were all thoose right?

I think so.

: >hm.. i'm not so competent to continue that list.. could anyone kind make  
: >a comparison table?
: 
: yes, please! I think, answer could be very informative for other readers  
: too. and even could make it's way to perl6 documentation. So, where's @a  
: and [EMAIL PROTECTED] are the same, and where they aren't?

I think the only place they differ is in list context.  @a always
interpolates, and $a never does.

: >in all other places where they work different, we could use @$a in place  
: >of @a, right?
: 
: if @ in @a is a part of name, would @$b work? and what's that @ here,  
: behind the scenes? operator? macro?

Syntactic sugar for $b[], basically.

By the way, I've always wondered about the possibility declaring things like

my bit @$vector;

as a way of specify that @vector and $vector are the same object.
That would let you have your highlander variables when you want them,
without having to figure out whether &foo and $foo are the same.

: >...
: >P.P.P.P.S
: >  open $file, "filename";
: >  print @file;
: >...
: 
: ..er, in that case:
:open $file, "filename";
:print @$file;

In any case, the open function doesn't take a filehandle as its first
argument anymore.  It returns the new filehandle.

: i mean, what about using objects(files, iterators, etc) as arrays? AFAIK,  
: we will have custom subscripting defined on our objects, so $file[10]  
: could be made to work, but what about @$file, or @($file) or $file[] (um,  
: maybe $file[*], I forgot) would it make any sense?

Any object that mixes in the ArrayIndex role can be indexed as an array.
Any object that mixes in the HashIndex role can be indexed as a hash.
Though it's probable that any object will act like a hash if you force
it, in which case $obj{'key'} ends up trying to call $obj.key, just so
that people can write in the Perl 5 object attribute idiom, and have it
really using accessors underneath.  But we may yet decide that's a bad
idea as a default.  Maybe it's just turned on by the p5-to-p6 translator.

: and, one more question: if we would have both tying (arrays which call  
: hidden object methods) and objects which could act as array references,  
: where's a difference between them? could it be THE same? Should it? could  
: we write
:  my $a = new ArrayLikeClass;
:  my @b := @$a;
:or
:  my @b := $a;
: (which one is right?)

I don't see a problem with either of them, but I didn't get enough sleep
last night, so I could be completely clueless.  In any event, we may
allow

my @$a is ArrayLikeClass;

as a shorthand for the above.  Or at least it should be possible via pragma.

Larry

Re: $ @ and %

[Alexey Trofimenko]

P.P.P.S. If answer on my "why?" would be "just because!" I would take it  
silently.
yes, answer was as I predicted above. I promised..
..but:
As far as I understood, arrays and hashes, and references them are much  
more similar in Perl6 than it was in Perl5.

F.e. we have @a and $a = [EMAIL PROTECTED];
the same:
 push @a,1,2,3   push $a, 1,2,3
 $b = @a $b = $a
(?)  say "@a[]"  say "$a[]"
(?)  myfunc( [EMAIL PROTECTED])myfunc ( *$a)
...
were all thoose right?
hm.. i'm not so competent to continue that list.. could anyone kind make  
a comparison table?
yes, please! I think, answer could be very informative for other readers  
too. and even could make it's way to perl6 documentation. So, where's @a  
and [EMAIL PROTECTED] are the same, and where they aren't?

in all other places where they work different, we could use @$a in place  
of @a, right?
if @ in @a is a part of name, would @$b work? and what's that @ here,  
behind the scenes? operator? macro?

...
P.P.P.P.S
  open $file, "filename";
  print @file;
...
..er, in that case:
   open $file, "filename";
   print @$file;
i mean, what about using objects(files, iterators, etc) as arrays? AFAIK,  
we will have custom subscripting defined on our objects, so $file[10]  
could be made to work, but what about @$file, or @($file) or $file[] (um,  
maybe $file[*], I forgot) would it make any sense?

and, one more question: if we would have both tying (arrays which call  
hidden object methods) and objects which could act as array references,  
where's a difference between them? could it be THE same? Should it? could  
we write
 my $a = new ArrayLikeClass;
 my @b := @$a;
   or
 my @b := $a;
(which one is right?)

Re: $ @ and %

[Larry Wall]

On Fri, Nov 26, 2004 at 10:29:52AM +0300, Alexey Trofimenko wrote:
: I'm talking about unifying namespaces of arrays, hashes and scalars. I  
: could swear i've seen some RFC about it..

Yes that's RFC 9, which was discussed and rejected long ago in A2.
I just find that I prefer to think of the sigils as part of the name.
That's doubly true now that we have various secondary sigils.

Larry

RE: :, ::, :::, and :::: in P6REs

[Paul Marquess]

 
> > Is that the "soon to be released" E5?
> 
> No, that's the "to be released today" E5.
> 
> ;-)

Yy!!

Re: :, ::, :::, and :::: in P6REs

[Simon Cozens]

[EMAIL PROTECTED] (Paul Marquess) writes:
> Is that the "soon to be released" E5?

Sometime today, all being well.

-- 
 I often think I'd get better throughput yelling at the modem.

Re: :, ::, :::, and :::: in P6REs

[Damian Conway]

Paul Marquess wrote:

> Is that the "soon to be released" E5?

No, that's the "to be released today" E5.

;-)

Damian

Re: :, ::, :::, and :::: in P6REs

[Damian Conway]

Simon Cozens wrote:

> While I'm messing about with REs, is it specified how :any and hypotheticals
> interoperate?
> 
>"ab" =~ rx:any / $match := (\w) /;
>print $match;
> 
> Can that be undefined behaviour? Please? :)

I don't think so.

It would probably result in $0 containing an array of match objects,
one for each possible match. Each of those second tier match
objects would then have a 'match' key in its hash attribute.

Hence, to see the individual hypotheticals one might write:

for @$0 -> $possible_match {
print $possible_match{match}, "\n";
}


A more intriguing possibility is that the top-level match object ($0 itself)
would *also* have a 'match' key...whose value contained a superposition of all
the possible hypotheticals. So you could also just write:

print egs( $0{match} _ "\n" );


Bwah-ha-ha-ha-hah!!

Damian

RE: :, ::, :::, and :::: in P6REs

[Paul Marquess]

> The behaviour is explained quite well in E5 I think.

Is that the "soon to be released" E5?

Paul

Re: :, ::, :::, and :::: in P6REs

[Simon Cozens]

[EMAIL PROTECTED] (Damian Conway) writes:
> It's not an exception, but you could certainly *implement* it that way.

I would argue that it is in some sense, if not an Official Perl 6 Exception,
since it jumps out of several levels of a match. But yeah, I'm probably
just looking at this from an implementor's viewpoint.

> It gives up tracktracking the immediately preceding atom.
> The behaviour is explained quite well in E5 I think.

Aha! Got it, thank you.

While I'm messing about with REs, is it specified how :any and hypotheticals
interoperate?

   "ab" =~ rx:any / $match := (\w) /;
   print $match;

Can that be undefined behaviour? Please? :)

-- 
DEC diagnostics would run on a dead whale.
-- Mel Ferentz

Re: :, ::, :::, and :::: in P6REs

[Damian Conway]

> I think I can distinguish :: from ::: - :: fails the current branch point,
> whereas ::: fails the entire rule. 

Correct.

> I think I can distinguish between ::: and ; the implementation
> is a bit tricky, because ::: fails the current match - easy enough -
> whereas  has to specify to all upper-level matches that they
> failed too. Is it reasonable for failing a  to be an exception?

It's not an exception, but you could certainly *implement* it that way.


> I don't think I can distinguish between : and ::. Essentially, how many
> nodes does each commit to? I would expect the following
> 
> [ a+ : b | c+ : d | e+ : f ]
> 
> to do precisely the same as 
> 
> [ a+ :: b | c+ :: d | e+ :: f ]

It doesn't. The first says:

[ # Non-capturingly...
a+#Match 1+ a's
: #And never backtrack to match fewer a's
b #Then match a b
| # Or if that failed...
c+#Match 1+ c's
: #And never backtrack to match fewer c's
d #Then match a d
| # Or if that failed...
e+#Match 1+ e's
: #And never backtrack to match fewer e's
f #Then match an
]

whereas the second says:

[ # Non-capturingly...
a+#Match 1+ a's
::#And if you ever have to backtrack,
   #  then immediately fail the entire surrounding group
b #Then match a b
| # Or if that failed...
c+#Match 1+ c's
::#And if you ever have to backtrack,
   #  then immediately fail the entire surrounding group
d #Then match a d
| # Or if that failed...
e+#Match 1+ e's
 ::#And if you ever have to backtrack,
   #  then immediately fail the entire surrounding group
f #Then match an f
]

So a single colon has the same effect as the Perl 5 (?>...) metasyntax.


> I don't see why Larry describes one as "if-then", but not the other.
> Basically, I don't think I'm sure what : "gives up".

It gives up tracktracking the immediately preceding atom.
The behaviour is explained quite well in E5 I think.

Damian

Re: -> and .

[Michel J Lambert]

> I could see something like:
>
> method operator.( $self: $function ) {
>   if( $function eq "inc" ) { ++%self.funcount{$_[2]}; }
>   else { $self.inc( $function ) }
> }
>
> That would count how many times you called each function.

Sounds a lot like aspect-oriented programming. If what you want is
overriding functions to do other stuff before, after, or both before and
after, a function, then aspects should be enough for you. Check out
Aspects on CPAN for a Perl 5 implementation, or the AspectJ stuff for the
original (at least, I think it was the first) definitive source for this
kind of stuff.

Of course, overloading and/or changing the way certain operators work
should be fair game in Perl6 along with the rest of the grammar. But I'm
just pointing out that this other solution will solve your recursiveness
problem, and is doable today, in Perl 5. It's also a much nicer interface
to this kind of programming. :)

Mike Lambert

Re: !< and !>

[raptor]

|
| > !<  and !>
|
| How is !< different from >=?

]- the way of Expression or syntax-sugar if u like it :"), and is faster to
prononce :")

if, if not, unless
bigger, smaller, equal
less than or equal, bigger than or equal
not bigger, not smaller  ...etc.

Personally I almost always make error when type '>=',  my hands go faster
and I write '=>' insteadnot that this matter much..
=
iVAN
[EMAIL PROTECTED]
=

Re: !< and !>

[Ken Fox]

"Bryan C. Warnock" wrote:
> I'm waiting for someone to say that in tri-state logic, '!<' != '>='

That's what I thought it was. "$a !< $b" might be "!defined($a) || $a >= $b".
In SQL this is "$a IS NULL or $a >= $b".

- Ken

RE: !< and !>

[Sterin, Ilya]

> -Original Message-
> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 02, 2001 8:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: !< and !>
>
>
> Bart Lateur <[EMAIL PROTECTED]> writes:
>
> > Why is it ">=" and not "=>"?
>
> Because in English, it's "less than or equal to" not "equal to or less
> than," I presume.
>
> > Simply trying to remember the order of characters might be (a bit of) a
> > pain. That problem doesn't exist with "!<" and "!>".
>
> Every other programming language I've ever seen uses >= and <=.  I think

This is Perl.  Why should it be like every other langage?  what happens to
innovation?

> adding additional comparison operators not found in any other language and
> identical to (and harder to type than!) existing operators is a really bad
> idea.

I don't see anything bad about, don't like it don't use it.  I can tell you
quite a few things I don't particularly like in Perl, but what I like is
more than one way of doing things, so I choose my preference.  I can't
recall a langage with unless() either, but sure help is exression writting
sometimes.

Ilya

>
> --
> Russ Allbery ([EMAIL PROTECTED])
> <http://www.eyrie.org/~eagle/>

Re: !< and !>

[Russ Allbery]

Bart Lateur <[EMAIL PROTECTED]> writes:

> Why is it ">=" and not "=>"?

Because in English, it's "less than or equal to" not "equal to or less
than," I presume.

> Simply trying to remember the order of characters might be (a bit of) a
> pain. That problem doesn't exist with "!<" and "!>".

Every other programming language I've ever seen uses >= and <=.  I think
adding additional comparison operators not found in any other language and
identical to (and harder to type than!) existing operators is a really bad
idea.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: !< and !>

[Bart Lateur]

On 01 Sep 2001 14:40:40 -0700, Russ Allbery wrote:

>Sterin, Ilya <[EMAIL PROTECTED]> writes:
>>> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
>
>>> How is !< different from >=?
...

>It's the same number of characters.  How can it be more convenient?

Why is it ">=" and not "=>"? Why "=<" and not "<="? Simply trying to
remember the order of characters might be (a bit of) a pain. That
problem doesn't exist with "!<" and "!>".

-- 
Bart.

RE: !< and !>

[Sterin, Ilya]

> -Original Message-
> From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 01, 2001 5:59 PM
> To: Russ Allbery; [EMAIL PROTECTED]
> Subject: Re: !< and !>
>
>
> On Saturday 01 September 2001 05:40 pm, Russ Allbery wrote:
> > Sterin, Ilya <[EMAIL PROTECTED]> writes:
> > >> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> > >>
> > >> How is !< different from >=?
> > >
> > > It's just more syntax just like foo != bar
> > > is the same as (foo > bar || foo < bar).
> > >
> > > It might prove convenient to express the expression.
> >
> > It's the same number of characters.  How can it be more convenient?
>
> You only have to manipulate the shift key once!  ;-)
>
> I'm waiting for someone to say that in tri-state logic, '!<' != '>='

I was actually thinking a similar before I send the initial reply, but I
just can't see a scenerio where it would be easily expressed !<=> :-)

Ilya


>
> --
> Bryan C. Warnock
> [EMAIL PROTECTED]

RE: !< and !>

[Sterin, Ilya]

> -Original Message-
> From: Andrew Wilson [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 01, 2001 6:06 PM
> To: Russ Allbery
> Cc: [EMAIL PROTECTED]
> Subject: Re: !< and !>
>
>
> On Sat, Sep 01, 2001 at 02:40:40PM -0700, Russ Allbery wrote:
> > >> How is !< different from >=?
> >
> > > It's just more syntax just like foo != bar
> > > is the same as (foo > bar || foo < bar).
>
> Not if you're using Quantum::SuperPositions ;-)
>
> > > It might prove convenient to express the expression.
> >
> > It's the same number of characters.  How can it be more convenient?
>
> It may help you to express yourself better in the way that you
> understand the problem you're solving.  Every little bit helps.
>

That's exactly what I was getting at.  The readability of the program,
otherwise why have more than one way to do it:-)

> cheers
>
> Andrew

Re: !< and !>

[Andrew Wilson]

On Sat, Sep 01, 2001 at 02:40:40PM -0700, Russ Allbery wrote:
> >> How is !< different from >=?
> 
> > It's just more syntax just like foo != bar 
> > is the same as (foo > bar || foo < bar).

Not if you're using Quantum::SuperPositions ;-)

> > It might prove convenient to express the expression.
> 
> It's the same number of characters.  How can it be more convenient?

It may help you to express yourself better in the way that you
understand the problem you're solving.  Every little bit helps.

cheers

Andrew

Re: !< and !>

[Bryan C . Warnock]

On Saturday 01 September 2001 05:40 pm, Russ Allbery wrote:
> Sterin, Ilya <[EMAIL PROTECTED]> writes:
> >> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> >>
> >> How is !< different from >=?
> >
> > It's just more syntax just like foo != bar
> > is the same as (foo > bar || foo < bar).
> >
> > It might prove convenient to express the expression.
>
> It's the same number of characters.  How can it be more convenient?

You only have to manipulate the shift key once!  ;-)

I'm waiting for someone to say that in tri-state logic, '!<' != '>='

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: !< and !>

[Russ Allbery]

Sterin, Ilya <[EMAIL PROTECTED]> writes:
>> From: Russ Allbery [mailto:[EMAIL PROTECTED]]

>> How is !< different from >=?

> It's just more syntax just like foo != bar 
> is the same as (foo > bar || foo < bar).

> It might prove convenient to express the expression.

It's the same number of characters.  How can it be more convenient?

-- 
Russ Allbery ([EMAIL PROTECTED]) 

RE: !< and !>

[Sterin, Ilya]

> -Original Message-
> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 01, 2001 4:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: !< and !>
> 
> 
> raptor <[EMAIL PROTECTED]> writes:
> 
> > I was looking at Interbase SELECT syntax and saw these two handy
> > shortcuts :
> 
> >  = {= | < | > | <= | >= | !< | !> | <> | !=}
> 
> > !<  and !>
> 
> How is !< different from >=?

It's just more syntax just like foo != bar 
is the same as (foo > bar || foo < bar).

It might prove convenient to express the expression.

Ilya


> 
> -- 
> Russ Allbery ([EMAIL PROTECTED]) 
> <http://www.eyrie.org/~eagle/>

RE: !< and !>

[Sterin, Ilya]

Though it might prove convenient (just more syntax for more than one way to
do it) it's equivalent to !< == >= and !> == <= , it might be too confusing,
though I myself would think that since != and ne is implemented, !< and !>
would definitely make common sense to implement as well.

Ilya

> -Original Message-
> From: raptor [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 01, 2001 11:18 AM
> To: [EMAIL PROTECTED]
> Subject: !< and !>
>
>
> hi,
> I was looking at Interbase SELECT syntax and saw these two handy
> shortcuts :
>
>  = {= | < | > | <= | >= | !< | !> | <> | !=}
>
> !<  and !>
>
> Personaly i didn't liked  if (! ...) construct too much, so even that
> starting to use "unless" is harder for non-english speaker, I
> think is much
> cleaner and good. Particulary 'cause if(!...) is harder to spot... but
> moving it near to comparison operator looks good  of cource
> not the same
> with !ne , !eq ..
> =
> iVAN
> [EMAIL PROTECTED]
> =
> PS. In my native language we doesn't have a word that fit best to
> "unless"(if not) ...
>
>
>

Re: !< and !>

[Russ Allbery]

raptor <[EMAIL PROTECTED]> writes:

> I was looking at Interbase SELECT syntax and saw these two handy
> shortcuts :

>  = {= | < | > | <= | >= | !< | !> | <> | !=}

> !<  and !>

How is !< different from >=?

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: And A Parser In A Pared Tree (was Re: Overloading && ||)

[David L. Nicol]

perl parser compiles perl language into perl op-code tree.

Larry ("the" Larry) has said that a new parser might parse
other languages into perl op-code trees too.


If the parts of the language are well organized, a LanguageSwitch
(the computer equivalent of a "context switch" in a conversation,
but "context switch" is already taken in computerese, as the
basic magic that underlies multitasking) would cause as little or
as much to be replaced by the overlay as we like.  Parser definition
overlays would be this third language we agree is ugly but needed to
implement this modularly.

So if we've got the vanilla language defined clearly, we can overload
stuff at a higher level.  Current overloading works when you have
a function that the parser recognizes as a function, and you switch the
contents of that function, but its still a function rather than a flow 
control construct.

&& and || are thought of as "functions that short-circuit" that makes
them flow control constructs.  To switch them from parsing into an if-then
kind of thing into being overloadable functions,  the parser needs to
recognize them as functions that will operate on both their arguments
rather than flow control to decide to evaluate or not the right side.

So if we add parser overloading, it might look like

use parseroverload qw{ && treeAnd};
use parseroverload qw{ || treeOr};

treeAnd and treeOr would have to be defined somewhere.


parseroverload language (to be determined) might be able to affect binding
of arguments to functions, are they postfix, prefix, infix, this would
give us "user definiable operators" which I think is a way of saying
that you want to put the function name between the arguments instead
of before them:


assign( $a , add($x, $y))

or

$a assign $x add $y


or

$a = $x + $y


The third version is the one that is most familar, the first is possible
in  languages with implicit pass-by-reference or arguments, the second is
possible (to have it mean the same thing) if we can reprogram the
parser to treat "add" and "assign" as alternate words for what we are
used to thinking of as + and =.  

Of course, when it comes time to translate the language to Chinese, having
all this stuff done in advance means we can drop in a big overlay and
call it translated.




"Bryan C. Warnock" wrote:

> Ideally, it wouldn't involve Yet Another Language, but could be done in
> one of the two Perl already has.  (Or both, I suppose.)  What I don't
> believe should be the goal, although it may be an unfortunate
> side-effect, is to, in essence, write the parser in Perl, and to
> require writing a full parser for every case  That would, in essence,
> require dropping the user parser inline between the lexer and the real
> parser, capturing all the tokens coming out, doing the necessary
> identification and modifications, and passing the new token stream to
> the real parser. I think this was one of Nat's hook areas, and is
> similar to what Chaim suggested with how macros could work.
> This could work with very simple requirements, and could even partially
> extend to adding lexer extensions.  Otherwise, why not just rewrite the
> parser in its entirety, and drop it in as a new front end?
> 
> Alternately, to keep things simple, you could have a signature callback
> type mechanism, where the parser only calls your code upon certain rule
> reductions.  This requires the lexer to have already sent the data to
> the parser, which could make for some icky situations, particularly
> with inspection and modification of what the parser has already done.
> 
> Or, to keep things really simple, have parser pragma types that affect
> the parser internals runtime much like the rest of Perl modules affect
> Perl runtime.  (This would, of course, require the parser to be able to
> support much deeper introspection than it does now.  Yet Another
> Language, more complexity.  But would allow for only a limited number
> of hooks, which would be a little easier to contain and a little less
> scary to deal with.)  This last was basically what I was looking for
> with RFC 40.  This would allow people to write their own pragmas, as
> long as they only needed what hooks were available.  More radical
> changes would involve adding more hooks.
> 
> I'll ponder all this today, and maybe give some examples this evening,
> perhaps showing how some of the current RFCs could be addressed.
> 
>  --
> Bryan C. Warnock
> ([EMAIL PROTECTED])

-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq