s:g/Mexico/Fancy Unicode/;
per RT#132179: https://rt.perl.org/Ticket/Display.html?id=132179#ticket-history
s:g/Mexico/Fancy Unicode/;
per RT#132179: https://rt.perl.org/Ticket/Display.html?id=132179#ticket-history
ico ≥, ≤, and ≠ ops to their Texas alternatives.
It was later pointed out[^2] that this aliasing is stronger than originally
intended:
multi sub infix:«<=» ( Str $, Str $ --> 'Str' ) {}
say 'f' <= 'f'; # Str
say 'f' ≤ 'f'; # Str
This is fixed so far.
Patches:
https://github.com/perl6/nqp/commit/ada83f20892d3d027a0ac5e537ab1b111db1968e
https://github.com/perl6/nqp/commit/8402ce098192cdfe57bd438781d9f1322f63273c
Fixed tests:
https://github.com/perl6/roast/commit/eec7994c1f
# New Ticket Created by Will Coleda
# Please include the string: [perl #126143]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=126143 >
See S05-capture/array-alias.t
Currently fails badly:
11:44 < [Coke]> r: use Test; ok("
-setting-library/Str.pod
Log Message:
---
Improve wording about substr-rw aliasing
Thanks to itz++ for pointing out the sentence's meaning.
On Tue Jun 29 06:34:35 2010, masak wrote:
> std: / $ = [ foo ] /
> std 31503: OUTPUT«ok 00:01 113m»
> std: / $ = [ foo ] /
> std 31503: OUTPUT«ok 00:01 110m»
> rakudo: "foo" ~~ / $ = [ foo ] /; say $
> rakudo 1576d4: OUTPUT«===SORRY!===Confused at line 11, near
> "\"foo\" ~~ /"»
> but
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #76266]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=76266 >
std: / $ = [ foo ] /
std 31503: OUTPUT«ok 00:01 113m»
std: / $ = [ foo ] /
std 3150
Am Montag, den 19.10.2009, 16:43 -0700 schrieb Jon Lang:
> Raphael Descamps wrote:
> > I personally don't understand why we don't have a exclude and alias
> > operator in Perl 6 but I have not read all the synopses and don't have
> > an overview.
>
> I don't think that it's explicitly spelled out
Raphael Descamps wrote:
> In the original traits paper the aliasing is not "deep": to respect the
> flattening property, the semantic of the role must not change, so
> aliasing a recursive method will call the original method. It's a known
> theoretical weakness of the
Raphael Descamps wrote:
> I personally don't understand why we don't have a exclude and alias
> operator in Perl 6 but I have not read all the synopses and don't have
> an overview.
I don't think that it's explicitly spelled out anywhere; but the
reason is fairly straightforward: exclude and alias
On 2009-Oct-18, at 3:44 pm, Jon Lang wrote:
David Green wrote:
I would expect that role Logging { method log(Numeric $x:) {...} }
means the invocant is really of type Numeric & Logging, without
Logging having to do Numeric. On the other hand, I can see that
strictly that might not make se
ve to be solved
> explicitly. The traits paper propose 3 different operators to solve
> such conflicts: overriding, excluding or aliasing.
>
> I definitively think that perl 6 roles should also have an excluding
> operator because I think that *every* composition conflicts arrising
&
David Green wrote:
> Jon Lang wrote:
>>
>> This implies that both Logging and Math do Numeric, since the invocant
>> ought to be of a type that the class does.
>
> I would expect that
> role Logging { method log(Numeric $x:) {...} }
> means the invocant is really of type Numeric & Logging, witho
On 2009-Oct-17, at 1:55 am, Jon Lang wrote:
This implies that both Logging and Math do Numeric, since the
invocant ought to be of a type that the class does.
I would expect that
role Logging { method log(Numeric $x:) {...} }
means the invocant is really of type Numeric & Logging, without
David Green wrote:
> Aha, so the bark:(Dog:) syntax identifies the method by its signature as
> well, thus distinguishing it from the .bark:(Tree:) method. This works fine
> when the sigs can distinguish the invocants, which is very common. However,
> I could have ambiguous methods even including
On 2009-Oct-16, at 12:54 am, Richard Hainsworth wrote:
Is there syntactic sugar for aliasing the conflicting method? Eg.
something like
does XML :db-write;
There needs to be something more than sugar: making a new class or
role with different methods will break substitutability. However
does XML;
method xml-db-write ( @_ ) { self.db-write( @_ ) };
};
This seems a bit clunky just to rename a method to prevent a conflict.
Is there syntactic sugar for aliasing the conflicting method? Eg.
something like
does XML :db-write;
Moreover, suppose that the two modules have roles with the same na
Nicholas Clark wrote:
[...]
Suggestions for a better name for BIND welcome. 4 letters or fewer.
An alias, eh? That's like a nickname, isn't it?
Well, since you're asking, I propose
NICK
Nicholas Clark
PS blead source is at rsync://public.activestate.com/perl-current/
--
Much of the
keep at the nice number of 16, there is a placeholder for a new
type,
tentatively named BIND, for 6-on-5 aliasing. It's all yours, 6-on-5
hackers.
I'm not exactly sure what is needed for 6-on-5, beyond read only aliases
to read-write values, but I think that implementing a workable versio
entatively named BIND, for 6-on-5 aliasing. It's all yours, 6-on-5 hackers.
I'm not exactly sure what is needed for 6-on-5, beyond read only aliases
to read-write values, but I think that implementing a workable version of
that should be fairly straightforward. Probably something lik
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #38064]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38064 >
When partcl unsets a variable, it breaks aliasing. Setting that variable
should
; Given that you are using DynLexPad, you just do:
>
>delete $P2['alias']
If only it were that simple. A delete operation like this will break
the aliasing. And only $alias will be undefined. $foo must also be
undefined. And if either becomes defined again, they must still
Matt Diephouse wrote:
> So what am I supposed to do? It appears that using `null` to mark
> deleted/undefined variables won't work. But it's not clear to me that
> using a Null PMC is a good idea...
Here's one possibility: you can use one of the PObj_private PMC flags to
store the defined/undefin
Matt Diephouse wrote:
$alias = undef
translates to
null $P1
$P2 = getinterp
$P2 = $P2["lexpad"; 1]
$P2['$alias'] = $P1
Given that you are using DynLexPad, you just do:
delete $P2['alias']
HTH
leo
While working out some bugs in ParTcl I came across something roughly
equivalent to the following Perl code (I'm using Perl because I
believe more people know Perl than Tcl, at least on this list):
#!/usr/bin/perl
$var = "Foo";
*alias = *var;
$alias = undef;
$alias = "Baz";
print $va
On Wed, Nov 30, 2005 at 12:41:59PM -0800, Larry Wall wrote:
> private="REFCOUNTED"
> refcnt="1">
>
>
>
>
>
>
>
> [...]
>
> Hope this helps
I sense a great evil. An evil that has been in abeyance since the
defeat of IP
On Wed, Nov 30, 2005 at 11:04:43AM -0800, Chip Salzenberg wrote:
: On Wed, Nov 30, 2005 at 12:49:13PM -0500, Joshua Juran wrote:
: > On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:
: > >Excellent. Now if only I knew a good language for text filters...
: >
: > How about sed or awk?
:
: Hm. I
On Wed, Nov 30, 2005 at 12:49:13PM -0500, Joshua Juran wrote:
> On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:
> >Excellent. Now if only I knew a good language for text filters...
>
> How about sed or awk?
Hm. If only we had a pir2xml, I could use XSLT.
--
Chip Salzenberg <[EMAIL PROTECTE
On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:
On Tue, Nov 29, 2005 at 11:13:05PM +0100, Leopold Toetsch wrote:
On Nov 29, 2005, at 21:36, Chip Salzenberg wrote:
I'm planning a flag day sometime in December. I'm also planning to
create a simple "handles most cases" translator.
That's a
My view I understand the way it's currently done. I'm totally lost
at what's being proposed.
Joshua
On Wed, 30 Nov 2005, Roger Browne wrote:
> Salzenberg wrote:
>
> > ... any language using ":=" for assignment is doomed
> > to obscurity.[*] It's a law of nature.
>
> :-)
>
> > (Ah, langua
Salzenberg wrote:
> ... any language using ":=" for assignment is doomed
> to obscurity.[*] It's a law of nature.
:-)
> (Ah, language design. :-))
No choice will satisfy everyone. So we each say our piece, then we
happily accept whatever the designer decides. No problem.
Regards,
Roger Brow
d "dogs" even though one makes a ''
sound and the other makes a '' sound. In the cases you mention:
P0 := P1 # aliasing: P0 and P1 point to same PMC
P0 := opcode # aliasing: P0 points to PMC returned by opcode
P0 = ... # assignment:
"copy the contents." Under
> this interpretation, both are reasonable for numbers.
You're looking at it backwards.
P and S registers can do something that I and N registers can't do:
They can both point to a common value, so that a change made via one
becomes visible via a
On Tue, Nov 29, 2005 at 10:45:12PM +, Roger Browne wrote:
> On Tue, 2005-11-29 at 12:08 -0800, Chip Salzenberg wrote:
> > Therefore, I propose requiring people to spell aliasing as ':='.
>
> Is some different symbol possible, to avoid confusing people who use
>
On Tue, Nov 29, 2005 at 05:17:25PM -0500, Matt Fowles wrote:
> I very much like it. I think I may have suggested something like it
> earlier (although I might have only thought it).
It's entirely possible. Great minds think alike ... and us too,
apparently. :-)
> "Computer Science is merely th
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Tue, 29 Nov 2005 13:07:22 -0800
On Tue, Nov 29, 2005 at 03:55:22PM -0500, Bob Rogers wrote:
> So "aliasing" copies the pointer (i.e. the object itself), and
> "assignment" copies the value?
Right.
On Tue, 2005-11-29 at 12:08 -0800, Chip Salzenberg wrote:
> Therefore, I propose requiring people to spell aliasing as ':='.
Is some different symbol possible, to avoid confusing people who use
Algol-like languages where ":=" means assignment (Amber, Ada, Eiffel,
o read:
>
>P0 = new .Integer
>P0 = 1
>
> one more time... *sigh*
>
> Therefore, I propose requiring people to spell aliasing as ':='. This will
> affect all code generated to use P and S registers. It should be an easy fix
> (albeit an extensive o
On Tue, Nov 29, 2005 at 11:13:05PM +0100, Leopold Toetsch wrote:
> On Nov 29, 2005, at 21:36, Chip Salzenberg wrote:
> >I'm planning a flag day sometime in December. I'm also planning to
> >create a simple "handles most cases" translator.
>
> That's all ok with me, but not without an automatic tr
On Nov 29, 2005, at 21:36, Chip Salzenberg wrote:
I'm planning a flag day sometime in December. I'm also planning to
create a simple "handles most cases" translator.
That's all ok with me, but not without an automatic translator, that
"handles 99.99% cases". As the current syntax is clear,
codes that set a new *value* for the PMC
referenced by their first parameter, but do not modify the register
itself. (I believe 'assign' fits that description.) So, if we follow
that algorithm, I think these should all be equivalent:
assign P0, P1
P0 = assign P1
P0 = P1
The
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 29, 2005 at 03:25:13PM -0500, Matt Diephouse wrote:
> > Or, perhaps more accurately, `P1 := ...\n assign P0, P1`?
>
> No, PIR doesn't do that kind of thing (allocating P registers) behind
> your back. If a sequence needs a second P register,
On Tue, Nov 29, 2005 at 03:55:22PM -0500, Bob Rogers wrote:
> So "aliasing" copies the pointer (i.e. the object itself), and
> "assignment" copies the value?
Right. Note, however, that you have to *have* a pointer for "copying
the pointer" to be meaningful. T
; Basically, though, my way would mean that copying the register's exact
> contents would always be done with `:=`, and more complicated
> assignments with potentially complex semantics would always be `=`.
I see your point. But I think awareness of reference semantics is
more importa
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Tue, 29 Nov 2005 12:27:03 -0800
On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> >P0 := P1 # aliasing: P0 and P1
On Tue, Nov 29, 2005 at 12:36:03PM -0800, Chip Salzenberg wrote:
> On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote:
> > Second comment: how about access to keyed items -- does this mean:
> >
> > P0 := P1[S1] # alias
> > S0 = P1[S1]# assignment
> > I0 = P1[S1]
On Tue, Nov 29, 2005 at 12:36:03PM -0800, Chip Salzenberg wrote:
> On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote:
> > P0 = P1[S1]# supported?
>
> Yes, it means to fetch a PMC and make P0 an alias to it. Perl 6
> equivalent should be, more or less:
>
> $a := $arra
On Tue, Nov 29, 2005 at 03:25:13PM -0500, Matt Diephouse wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > Therefore, I propose requiring people to spell aliasing as ':='.
>
> "And the Lord did grin. And the people did feast upon the lambs and
&
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote:
> > I'm not sure about the last two (in a lot of ways, they're more like
> > := than = ),
>
> I don't see that.
Well, for one thing, my way would mean that `set` is always `:=`.
On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote:
> On Tue, Nov 29, 2005 at 12:08:01PM -0800, Chip Salzenberg wrote:
> >P0 := P1 # aliasing: P0 and P1 point to same PMC
> >P0 := opcode # aliasing: P0 points to PMC returned by o
On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote:
> Personally I haven't had much trouble with '=' and I don't think
> I ever use ':='. Perhaps I've just trained myself to the current
> implementation, but I like that the shorter '=' does what I tend
> to want/expect and I write
On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > P0 := P1 # aliasing: P0 and P1 point to same PMC
> >P0 := opcode # aliasing: P0 points to PMC returned by opcode
> >
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> And if I have to read:
>
>P0 = new .Integer
>P0 = 1
>
> one more time... *sigh*
>
> Therefore, I propose requiring people to spell aliasing as ':='. This will
> affect all code generated to use P
On Tue, Nov 29, 2005 at 12:08:01PM -0800, Chip Salzenberg wrote:
> Therefore, I propose requiring people to spell aliasing as ':='. This will
> affect all code generated to use P and S registers. It should be an easy fix
> (albeit an extensive one). And if we don't d
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
>P0 := P1 # aliasing: P0 and P1 point to same PMC
>P0 := opcode # aliasing: P0 points to PMC returned by opcode
>P0 = ... # assignment: modifies P0, NO MATTER WHAT '...' IS
>
>S0 := S1 #
Consider:
P0 = P1
P0 = S1
P0 = I1
P0 = N1
o/~ One of these things is not like the others
One of these things just doesn't belong o/~
And if I have to read:
P0 = new .Integer
P0 = 1
one more time... *sigh*
Therefore, I propose requiring people to spell aliasi
No, please close it.
--Josh
methods don't topicalize their invocant.
method bar ($_:) {
.foo();
}
Ahh, does this mean that the auto-aliasing is ditched?
I personally regard $_ as a bit too volatile and if it
is a rw binding it's outright dangerous to not have access
to $?SELF after some topicalizing statem
Ovid skribis 2005-04-10 10:47 (-0700):
> Apologies if this has been covered. What should this do?
> ($x,$y) := ($y,$x);
It would let $x be a second name for the variable that is also called
$y, and $y for $x. The old names $x and $y are overwritten, so
essentially the names for the two variable
Hi all,
Apologies if this has been covered. What should this do?
($x,$y) := ($y,$x);
In Perl5:
$x=2; $y=3;
print "x: $x y: $y\n";
(*::x, *::y) = (*::y, *::x);
$y=4;
print "x: $x y: $y\n";
$x=5;
print "x: $x y: $y\n";
This program shows typeglob
On Fri, Jul 18, 2003 at 06:05:52PM -0400, Benjamin Goldberg wrote:
> What would happen if I used 1,2,3 instead of 1..3? Would it do the same
> thing?
I would think so.
> I wanna know what happens if I do:
>
>@a[0,2,4] = qw/ a b c d e /;
Yup, you're right, I didn't consider non-cont
Benjamin Golberg writes:
> Luke Palmer wrote:
> >
> > > David Storrs wrote:
> > > >
> > > > Thinking about it, I'd rather see lvalue slices become a nicer version
> > > > of C.
> > > >
> > > > my @start = (0..5);
> > > > my @a = @start;
> > > >
> > > > @a[1..3] = qw/ a b c d e /;
>
Dave Whipp wrote:
> "Luke Palmer" wrote:
> > Benjamin Goldberg wrote:
> > > David Storrs wrote:
> > > > @a[1..3] = qw/ a b c d e /;
> > > > print @a; # 0 a b c d e 4 5
> > >
> > > What would happen if I used 1,2,3 instead of 1..3?
> > > Would it do the same thing?
> >
> > Of course.
>
"Luke Palmer" <[EMAIL PROTECTED]> wrote:
> Benjamin Goldberg wrote:
> > David Storrs wrote:
> > > @a[1..3] = qw/ a b c d e /;
> > > print @a; # 0 a b c d e 4 5
> >
> > What would happen if I used 1,2,3 instead of 1..3? Would it do the same
> > thing?
>
> Of course.
I tend to agree, I
Luke Palmer wrote:
>
> > David Storrs wrote:
> > >
> > > Thinking about it, I'd rather see lvalue slices become a nicer version
> > > of C.
> > >
> > > my @start = (0..5);
> > > my @a = @start;
> > >
> > > @a[1..3] = qw/ a b c d e /;
> > > print @a; # 0 a b c d e 4 5
> >
>
> David Storrs wrote:
> >
> > Thinking about it, I'd rather see lvalue slices become a nicer version
> > of C.
> >
> > my @start = (0..5);
> > my @a = @start;
> >
> > @a[1..3] = qw/ a b c d e /;
> > print @a; # 0 a b c d e 4 5
>
> What would happen if I used 1,2,3 instead
David Storrs wrote:
>
> Thinking about it, I'd rather see lvalue slices become a nicer version
> of C.
>
> my @start = (0..5);
> my @a = @start;
>
> @a[1..3] = qw/ a b c d e /;
> print @a; # 0 a b c d e 4 5
What would happen if I used 1,2,3 instead of 1..3? Would it do
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 08, 2003 at 05:52:04PM -0700, Austin Hastings wrote:
> >
> > --- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote:
> > > Am I now thinking clearly?
> > >
> > I don't think so.
> >
> > If you've created two separate arrays that happen
On Tue, Jul 08, 2003 at 05:52:04PM -0700, Austin Hastings wrote:
>
> --- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote:
> > Am I now thinking clearly?
> >
> I don't think so.
>
> If you've created two separate arrays that happen to start with related
> values, then the changes to the first
--- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote:
> "Jonadab the Unsightly One" <[EMAIL PROTECTED]> writes:
>
> > Does this imply, though, that it's pointing to specific elements,
>
> Wow, I wasn't paying attention to what I was thinking there.
> Obviously it points to specific elements,
"Jonadab the Unsightly One" <[EMAIL PROTECTED]> writes:
> Does this imply, though, that it's pointing to specific elements,
Wow, I wasn't paying attention to what I was thinking there.
Obviously it points to specific elements, because the subscripts used
to create a slice don't have to be sequen
David Storrs <[EMAIL PROTECTED]> writes:
> my $r_slice = [EMAIL PROTECTED];
> @$r_slice = qw/ a b c d e /;
> print @a; # 0 a b c d e 4 5
This seems right to me. It would take approximately no time to get
used to this semantic, IMO.
> # Note that it does NOT modify in r
Thinking about it, I'd rather see lvalue slices become a nicer version
of C.
my @start = (0..5);
my @a = @start;
@a[1..3] = qw/ a b c d e /;
print @a; # 0 a b c d e 4 5
# Similarly:
@a = @start;
my $r_slice = [EMAIL PROTECTED];
@$r_slice = qw/ a b c
On 5 Jul 2003, Luke Palmer wrote:
> > return [EMAIL PROTECTED] $begin .. $end ];
>
> I fear that this might take a reference to each element in the slice,
> rather than a reference to the slice
Yes, that would indeed return a list of refs in perl5. Can it also be
assumed that the magic hy
> > On Sat, Jul 05, 2003 at 09:51:29AM -0600, Luke Palmer wrote:
> >
> > > Actually, you can't reference a slice! Where the heck does the
> > > reference point? I would probably do:
> >
> > Of course not. I presume it points to something non-existent just like
> > a substring reference would in
> On Sat, Jul 05, 2003 at 09:51:29AM -0600, Luke Palmer wrote:
>
> > Actually, you can't reference a slice! Where the heck does the
> > reference point? I would probably do:
>
> Of course not. I presume it points to something non-existent just like
> a substring reference would in perl5 :-)
>
On Sat, Jul 05, 2003 at 09:51:29AM -0600, Luke Palmer wrote:
> Actually, you can't reference a slice! Where the heck does the
> reference point? I would probably do:
Of course not. I presume it points to something non-existent just like
a substring reference would in perl5 :-)
$ perl -le '$a =
> On Fri, 4 Jul 2003, Damian Conway wrote:
>
> > > Will it be possible (or sane even) to bind a variable to an array slice
> > It *should* be, since it's possible (if ungainly) to do it in Perl 5:
>
> Ouch, blatant abuse of perl5's aliasing with @_ and glob
On Fri, 4 Jul 2003, Damian Conway wrote:
> > Will it be possible (or sane even) to bind a variable to an array slice
> It *should* be, since it's possible (if ungainly) to do it in Perl 5:
Ouch, blatant abuse of perl5's aliasing with @_ and globs ;) Can I also
assume tha
Dan Brook wrote:
Will it be possible (or sane even) to bind a variable to an array slice
It *should* be, since it's possible (if ungainly) to do it in Perl 5:
use Data::Dumper 'Dumper';
@bar = (1,2,3);
*foo = (sub [EMAIL PROTECTED])->(@bar[1,0,3]);
print Dumper [EMAIL PROTECTED];
> Will it be possible (or sane even) to bind a variable to an array slice
> e.g
>
> ## correct syntax?
> my @array = << a list of values >>;
>
> my @array_slice := @array[ 1 .. @array.end ];
Yeah, that'll work. It has to, lest:
my [EMAIL PROTECTED] := (1, 1, map { $^a + $^b } zip(@fi
Will it be possible (or sane even) to bind a variable to an array slice
e.g
## correct syntax?
my @array = << a list of values >>;
my @array_slice := @array[ 1 .. @array.end ];
Or would this merely bind @array_slice to the list returned by the slice,
or would it DTRT (in my eyes at least)
;
>for $a, $b <- @foo { ... } # "for $a and $b from @foo..."
All else aside, I think that a <- will not
fly. It's too easily read as greater-than-unary-minus
-Erik
>
>(heck, that even looks like shifting -- "shifty aliasing". The A4 syntax
>look
On Saturday, February 8, 2003, at 02:53 AM, Luke Palmer wrote:
If you're talking about your own C example, actually, this would
match it better:
grep $x <- @list { $x eq 3 }
But if you're talking about A4's:
grep @list -> $x { $x eq 3 }
Which is very close to (one of) the currently v
ll or good):
>
> for $a, $b <- @foo { ... } # "for $a and $b from @foo..."
>
> (heck, that even looks like shifting -- "shifty aliasing". The A4 syntax
> looks like popping until you realize it is really shoving the left N
> thingees into the contain
t even looks like shifting -- "shifty aliasing". The A4 syntax
looks like popping until you realize it is really shoving the left N
thingees into the containers on the right -- Syntactical Action at a
Distance).
Then, A4 gives this example of C:
grep -> $x { $x eq 3 } @
Done.
--Josh
At 22:57 on 12/31/2002 GMT, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Currently Parrot is picking up Perl's C compiler flags. Perl is quite
> deliberately attempting to set -fno-strict-aliasing, to stop gcc using
> ANSI's aliasing rules to inf
Currently Parrot is picking up Perl's C compiler flags. Perl is quite
deliberately attempting to set -fno-strict-aliasing, to stop gcc using
ANSI's aliasing rules to infer possible optimisations; optimisations that
will actually break Perl's code.
(Don't ask me to remem
--
On Sun, 08 Sep 2002 22:24:11
Damian Conway wrote:
>
>Think of it as punctuation. As a necessary alternative to the poor
>overworked colon.
>
Or the poor overworked dot?
>
>
>> it all looks the same to me. And I like different things to look different.
>
>A fair point. My counterargume
Steve Canfield wrote:
> I was under the impression that compile time properties, like runtime
> properties, can be arbitrarily invented and/or assigned.
Yes, but not purely lower-case ones. They're reserved for Perl 6 itself.
(i.e. only Larry can invent/assign them ;-)
> If that is
> correct,
>From: Uri Guttman <[EMAIL PROTECTED]>
>that is not a variable property so it should be
>a compile time error.
I was under the impression that compile time properties, like runtime
properties, can be arbitrarily invented and/or assigned. If that is
correct, why would "my $var is true", meaningle
Erik Steven Harrison wrote:
> But still, what counts as a runtime property, other than true or
> false, as in the delightful '0 but true'? What other kind of runtime
> labels can I slap on a value?
Here's ten to start with...
for <> but tainted(0) {...} # note that external data
Erik Steven Harrison wrote:
> Just found this hidden in my inbox.
> I didn't think anyone was paying attention ;-).
Oh, we *always* pay attention. We just don't always respond. ;-)
>>What I most like about the C syntax is (like methods in
>>OO Perl), it associates a meaningful *name* with e
> "SC" == Steve Canfield <[EMAIL PROTECTED]> writes:
SC> Would it be accurate to say that "is" sets properties of variables,
SC> whereas "but" sets properties of values? If so, what would this output:
SC> my $var is true;
that is not a variable property so it should be a compile tim
>From: Trey Harris <[EMAIL PROTECTED]>
>To: Steve Canfield <[EMAIL PROTECTED]>
> > I would expect it to output "false".
>
>Why? I believe that, whatever you set $var to, you have marked the
>variable as constantly true in booleans.
Because in my experience variables are not true or false. They
In a message dated Sun, 8 Sep 2002, Steve Canfield writes:
> Would it be accurate to say that "is" sets properties of variables, whereas
> "but" sets properties of values? If so, what would this output:
>
> my $var is true;
> $var=0;
> if ($var) {print "true"}
> else {print "false"}
>
> I
Would it be accurate to say that "is" sets properties of variables, whereas
"but" sets properties of values? If so, what would this output:
my $var is true;
$var=0;
if ($var) {print "true"}
else {print "false"}
I would expect it to output "false".
__
Peter Behroozi wrote:
>> sub hidden (str $name, int $force is aka($override)) {...}
>
>
> Hang on a moment! In your original answer to this question, you used
> the "is named('alias')" syntax, but now you are suggesting using the
> sigil in the syntax.
Yes, but for a *different* property.
> Damian Conway wrote:
> >>And is the is/but distinction still around?
> >
> >Oh, yes.
>
> Could someone please reference where this decision was
> made. I do not find any information describing the distinction.
The following May 2001 post was related. Poke around the
thread it was in, especial
1 - 100 of 158 matches
Mail list logo
