Re: type sigils redux, and new unary ^ operator
Juerd: Rob Kinyon: What about @array.indices instead? Oops, I said indexes in a former message. AFAIK they share most of their meanings nowadays. (My old Chambers says that indexes are books.) Maybe a good candidate for an alias? No doubt about it. -- Affijn, Ruud Gewoon is een tijger.
Re: type sigils redux, and new unary ^ operator
TSa:
Perhaps we
can live with the numerically lower end always beeing part
of the range, the larger one never,
I don't think so.
0 .. 5 == ( 0, 1, 2, 3, 4)
{ action } for 0 .. 5
is supposed to run for 0,1,2,3,4,5.
But '0 .. ^5' should not mean '( 0, 1, 2, 3, 4, 5)' just because
scalar(^5) is 5.
0 .. ^5 = 0 .. 0 .. 4 = 0 .. 4
I think that '0..^0' should be the empty range, just as '^0'.
0 ..-5 == (-1,-2,-3,-4,-5)
Maybe only a range from low to high should be auto-listified, and a
bare '0..-5' should remain an error.
(0 ..-5) == (0, -1,-2,-3,-4,-5)
-5 .. 5 == (-5,-4,-3,-2,-1, 0, 1, 2, 3, 4)
-5 .. ^5
--
Affijn, Ruud
Gewoon is een tijger.
Re: relational data models and Perl 6
Ruud H.G. van Tol schreef: [RD-interface] See also these Haskell Hierarchical Libraries (base package) http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Set.html http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Map.html -- Affijn, Ruud Gewoon is een tijger.
Re: [svn:perl6-synopsis] r8520 - doc/trunk/design/syn
Larry Wall schreef: Ruud H.G. van Tol: Uri Guttman: When cast into an array, you can access all the positional arguments; Into a hash, all named arguments; Into a scalar, the invocant; Into code, into slurpy nameless block. The last 'into' should be 'the'. And it has become 'its', which is clearer. s/Into/into/g s[ s ( .* ) g ][s:g$0] TomTiedy Ack -- Affijn, Ruud Gewoon is een tijger. (posted via news://nntp.perl.org)
Re: [svn:perl6-synopsis] r8532 - doc/trunk/design/syn
Uri Guttman schreef: you might as well attribute the s:g/Into/into/ to dr. ruud. Right, s:g/I/i/ is all that remained. I really was amazed by your new capitalization style. :) -- Affijn, Ruud Gewoon is een tijger. (posted via news://nntp.perl.org again)
Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn
Ruud H.G. van Tol schreef: Juerd: autrijus: -foo.($arg1, $arg2); +foo. ($arg1, $arg2); [...] Please reconsider. Yes, please come up with a different character to bridge/cross/hide/cloak/skip/zap the succeeding not allowed whitespace. Maybe the \, making \whitespace mean s:s/\s+//. Rather an inline s/[\]\s+// source filter (for code). $foo\.bar(...)\.baz(...)\.quux(...) It will often look like a continuation character: $foo\ .bar(...)\ .baz(...)\ .quux(...) and should be able to eat to the left too: $foo \ .bar(...) \ .baz(...) \ .quux(...) The # is an alternative, and promotes multiline outlining, if you make it mean: remove everything after it until the end of the line, and itself with all whitespace in front of it, and all whitespace from the end of the current line up to the first \S (or EOF). $foo # .bar(...) # .baz(...) # .quux(...) ;) -- Affijn, Ruud Gewoon is een tijger.
Re: [svn:perl6-synopsis] r8698 - doc/trunk/design/syn
[EMAIL PROTECTED] schreef: +The unary prefix operator C* casts a value to an CCapture s/\ban\b/a @@ -1340,7 +1340,7 @@ PairTuple of two elements that serves as an one-element idem +my $ref = [EMAIL PROTECTED]; # $ref is an Capture object - see S02 idem -- Affijn, Ruud Gewoon is een tijger.
Re: [svn:perl6-synopsis] r8724 - doc/trunk/design/syn
[EMAIL PROTECTED] schreef: Author: autrijus Date: Sun Apr 16 18:24:04 2006 New Revision: 8724 Modified: doc/trunk/design/syn/S06.pod doc/trunk/design/syn/S09.pod Log: * more typo cleanups promted by Dr. Ruud. I love tradition: s/mt/mpt ;) -The unary prefix operator C* casts a value to an CCapture +The unary prefix operator C* casts a value to a CCapture -my $ref = [EMAIL PROTECTED]; # $ref is an Capture object - see S02 +my $ref = [EMAIL PROTECTED]; # $ref is a Capture object - see S02 I miss the s/\ban one\b/a one/ correction. Oh well, it has loads of tradition too. (King James; 2 Corinthians: 10:11, 12:5; et many al.) -- Affijn, Ruud Gewoon is een tijger.
Re: A shorter long dot
Jonathan Lang schreef:
When is the last time that you saw an underscore-only method name?
sub _{print$_\n};
--
Affijn, Ruud
Gewoon is een tijger.
[S05] /ee
quote
Instead of /ee say:
s/pattern/{ eval doit() }/
/quote
s/eval/try/ ?
--
Affijn, Ruud
Gewoon is een tijger.
S11 - s/beings/begins/
S11, near the end: s/beings/begins/ :) -- Affijn, Ruud Gewoon is een tijger.
normalized hash-keys
What would be the way to define-or-set that a specific hash has non-case-sensitive keys? Or broader: that the keys should be normalized (think NFKC()) before usage? Would it be easy to delegate it to the hash? (or use a hardly noticeable wrapper) -- Affijn, Ruud Gewoon is een tijger.
Re: normalized hash-keys
Larry Wall schreef:
Dr.Ruud:
What would be the way to define-or-set that a specific hash has
non-case-sensitive keys?
Use a shaped hash with a key type that defines infix:===
appropriately, since object hashes are based on infix:=== rather
than infix:eq.
Suppose I want the keys to be Normalization-Form-C, and the values to be
regexes,
would this be the way to say that?
my Regex %hash{ NFC } ;
http://www.unicode.org/notes/tn5/
http://icu.sourceforge.net/
http://www.ibm.com/software/globalization/icu/
Or broader: that the keys should be normalized (think NFKC()) before
usage?
I think it would be up to the type to generate, transform to and/or
cache such a canonicalized key.
OK, alternatively delegate it to the type.
Would it be easy to delegate it to the hash? (or use a hardly
noticeable wrapper)
Probably--just give the hash a shape with a key type that is easily
coerced from the input types, I suspect. Hash keys could probably
afford to do an implicit .as(KeyType) even if the current language
were to disallow implicit conversions in general.
Maybe not hash keys in general, but only hash keys of a type that needs
it. But wait, even stringification is coercion.
--
Affijn, Ruud
Gewoon is een tijger.
Re: Run time dispatch on ~~
Aaron Sherman schreef:
given $_ {
when $x {...}
}
or
$_ ~~ $x
Can that be written as .~~ $x?
--
Affijn, Ruud
Gewoon is een tijger.
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
Mark A. Biggar schreef: Darren Duncan: Now, I didn't see them yet anywhere in Synopsis 3, but I strongly recommend having negated versions of all these various types of equality tests. Eg, !== for ===, nev for eqv, etc. They would be used very frequently, I believe (and I have even tried to do so), and of course we get the nice parity. Yes and they should be strictly implicitly defined in term of the positive versions in such a way that you can't explicitly redefine them separately. I.e., $x !== $y should always mean exactly the same thing as !($x === $y). Maybe by a macro definition. To do otherwise would be very confusing as it would make such simple program transformations as: say foo if $x !== $y; into say foo unless $x === $y; And how about symmetry: say foo unless $y === $x; very unreliable. -- Affijn, Ruud Gewoon is een tijger.
Re: Run time dispatch on ~~
Larry Wall schreef: Dr.Ruud: Aaron Sherman: $_ ~~ $x Can that be written as .~~ $x? No, but you might just possibly get away with writing: .infix:~~($x) assuming that the $_.foo($x) SMD eventually fails over to foo($_,$x) MMD. But that doesn't seem to be much of an improvement over when $x. OK, thanks. Is it ever useful for an SMD to fail over to MMD? -- Affijn, Ruud Gewoon is een tijger.
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
Darren Duncan schreef: Dr.Ruud: say foo if $x !== $y; into say foo unless $x === $y; And how about symmetry: say foo unless $y === $x; Any equality or inequality operator is commutative, If $x and $y are not of the same type, and one or both of the involved types has its own (or overloaded?) 'deep equality operator', the choice (which implementation is used) can depend on the order. Not so long ago, there was an issue with Perl5 in this area (IIRC with '==' and undef). so it doesn't matter whether you have $x and $y or $y and $x, the result is the same. So you can use whichever order you want without it needing to be coded for. -- Darren Duncan -- Affijn, Ruud Gewoon is een tijger.
just laugh your heart out
As sometimes Perl6 to Perl5 is explained as C++ to C: Newsgroups: rec.arts.humor Subject: The truth about 'C++' revealed Date: Tuesday, December 31, 2002 5:20 AM On the 1st of January, 1998, Bjarne Stroustrup gave an interview to the IEEE's 'Computer' magazine. Naturally, the editors thought he would be giving a retrospective view of seven years of object-oriented design, using the language he created. By the end of the interview, the interviewer got more than he had bargained for and, subsequently, the editor decided to suppress its contents, 'for the good of the industry' but, as with many of these things, there was a leak. Here is a complete transcript of what was was said, unedited, and unrehearsed, so it isn't as neat as planned interviews. __ Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back? Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem. Interviewer: problem? Stroustrup: Yes, problem. Remember when everyone wrote Cobol? Interviewer: Of course, I did too Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty. Interviewer: Those were the days, eh? Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen. Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better. Stroustrup: Exactly. Well, the same happened with 'C' programmers. Interviewer: I see, but what's the point? Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity. [NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)] Interviewer: You're kidding...? Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn? Interviewer: You bet I do, that's what I used to do. Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too. Interviewer: I don't believe you said that... Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would. Interviewer: So how exactly did you do it? Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient. Interviewer: What? Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code? Interviewer: Well, never, actually, but... Stroustrup: There you are then. Mind you, a few tried, in the early days. There was this Oregon company - Mentor Graphics, I think they were called - really caught a cold trying to rewrite everything in C++ in about '90 or '91. I felt sorry for them really, but I thought people would learn from their mistakes. Interviewer: Obviously, they didn't? Stroustrup: Not in the slightest. Trouble is, most companies hush-up all their major blunders, and explaining a $30 million loss to the shareholders would have been difficult. Give them their due, though, they made it work in the end. Interviewer: They did? Well, there you are then, it proves O-O works. Stroustrup: Well, almost. The executable was so huge, it took five minutes to load, on an HP workstation, with 128MB of RAM. Then it ran like treacle. Actually, I thought this would be a major stumbling-block, and I'd get found out within a week, but nobody cared. Sun and HP were only too glad to sell enormously powerful boxes, with huge
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green schreef: === ...is equality-of-contents, basically meaning that the things you're comparing contain the same [...] values. How about strings; are normalized copies used with the === ? http://www.unicode.org/faq/normalization.html http://www.unicode.org/notes/tn5/ -- Affijn, Ruud Gewoon is een tijger.
Re: === and array-refs
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. /quote So $x === Sy stil holds. -- Affijn, Ruud Gewoon is een tijger.
Re: === and array-refs
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.
/quote
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.
Henry IV Henry â.£ 8 7 0
Henry IV Henry IV 8 8 1
How will the Str type do this?
--
Affijn, Ruud
Gewoon is een tijger.
Re: === and array-refs
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.
Henry IV Henry ?.? 8 7 0
Henry IV Henry IV 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: multi-line comments, C macros, Pod abuse
Stuart Cook schreef:
Larry Wall:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
commented-out code temporarily fails to compile.
How frequent does that happen?
And in that case s/if 0/\#/, as Luke mentioned.
And if the compile failure has to do with {}, use other braces.
But would the following work?
0 or q:to/END42/
...
END42
--
Affijn, Ruud
Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
Carl Mäsak schreef:
Ruud:
Carl:
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
for @array - $val {
say $.\t$val;
}
Or give the block a name (label), and have an index (or several
indexes, like some that are reset by redo an some that are not)
available, attached to that name.
That sounds like an interesting idea. Do you have a short snippet to
hint of what that would look like?
Maybe something like:
for @array - $val
{
say for.ix, \t$val;
}
for @array - $val NAME1:
{
say NAME1.ix, \t$val;
}
--
Affijn, Ruud
Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
Carl Mäsak schreef:
I suppose doing a map or a grep over @array.kv is possible:
pugs my @array = london bridge is falling down
(london, bridge, is, falling, down)
pugs map { Element $^a is called $^b }: @array.kv;
(Element 0 is called london,
Element 1 is called bridge,
Element 2 is called is,
Element 3 is called falling,
Element 4 is called down)
But it can hardly be blamed for clarity.
I find it very clear too. g
Also try a sparse array.
--
Affijn, Ruud
Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
Damian Conway schreef: [attribution repaired] Carl: But it can hardly be blamed for clarity. That's a little unfair. can hardly be blamed - can easily be praised g -- Affijn, Ruud Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
Damian Conway schreef:
Ruud:
Damian:
Carl:
But it can hardly be blamed for clarity.
That's a little unfair.
can hardly be blamed - can easily be praised g
Apologies to Carl if I misinterpreted. I read it as:
can hardly be blamed for (having) clarity
;-)
Nah, I was just joking; his but gave it away already.
I didn't agree that the map-approach Carl showed is not clear, but
prefer the pointy blocks version that you showed.
my @array = london bridge is falling down ;
for @array - $index, $value
{
say Element $_ is called $value
}
But I don't understand how the $index, $value pair gets its values; is
@array somehow turned into a hash with the index as the key?
With @array - $index, $value {}, is $_ an alias of $index?
--
Affijn, Ruud (should update his pugs, but on dialup now)
Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
Damian Conway schreef:
[for @array - $index, $value {...}]
No. There's no such magic. I simply screwed up. I should have written:
for @array.kv - $index, $value {...}
:-(
Ah, much clearer now. g
--
Affijn, Ruud
Gewoon is een tijger.
Re: Nested statement modifiers.
Paul Seamons schreef: The following is one more interesting case. say Ok then if $yes and $true unless $no or $false; Without nested modifiers you'd have either: say Ok then if $yes and $true and ! $no and ! $false; or say OK then unless ! $yes or ! $true or $no $or $false; And everybody knows you shouldn't use double negatives. $no or $false or $yes and $true and say OK then ; $no or $false or say OK then if $yes and $true ; -- Affijn, Ruud Gewoon is een tijger.
Re: Nested statement modifiers.
Paul Seamons schreef:
In the samples you gave I had to read the entire line to see
what the outcome of the code is.
I was not addressing reading skills, but just your you'd either have
... or One always needs to read the full line, but one doesn't
have to do that linearly or just from left to right.
Read Perl's or as skip if the previous was true, and speed-reading
such
constructs is in your bag.
There are plenty of cases where you too want the conditions up front.
A. $strong_objection1 or $strong_objection2 or
$half_a_reason1 and $half_a_reason2 and $weight *= 1.1 ;
B. $no_way 0.8 or $you_must_be_crazy 0.9 or
$let_s_try 0.6 and $you_never_know 0.5 and $weight *= 1.1 ;
C. $weight *= 1.1 if $let_s_try 0.6 and $you_never_know 0.5
unless $no_way 0.8 or $you_must_be_crazy 0.9 ;
D. unless $no_way 0.8 or $you_must_be_crazy 0.9
{
if $let_s_try 0.6 and $you_never_know 0.5
{
$weight *= 1.1
}
}
E. unless $no_way 0.8 or $you_must_be_crazy 0.9
{
$weight *= 1.1 if $let_s_try 0.6 and $you_never_know 0.5
}
Assuming all variants are alternatives, I prefer E.
A-E aren't alternatives if the value of the (last) evaluated expression
counts:
F. $strong_objection1 or $strong_objection2 !!
$half_a_reason1 and $half_a_reason2 ?? ($weight *= 1.1)
:: weight
:: weight ;
G. $strong_objection1 or $strong_objection2 ?? weight
::
$half_a_reason1 and $half_a_reason2 !! weight
:: ($weight *= 1.1) ;
H. $strong_objection1 or $strong_objection2 ?? weight
::
$half_a_reason1 and $half_a_reason2 ?? ($weight *= 1.1)
:: weight ;
Allowing for multiple nested modifiers allows the action to retain its
significance. After I sent the last email I came across a statement
in the code I was working on that would have phrased better if I
could use both an if and an unless. These things do come up - we
Perl 5 coders have just trained ourselves to do things another ways.
Or use a block. I am all for multiple nested modifiers, but not because
I need the action up front, I just happen to like the lean look.
$weight *= 1.1 if $half_a_reason1 and $half_a_reason2
unless $strong_objection1 or $ $strong_objection2 ;
unless $strong_objection1 or $ $strong_objection2
{
$weight *= 1.1
if $half_a_reason1 and $half_a_reason2 ;
} ;
The biggest setback I see to nested modifiers is that the order of
lexical scopes visually read on the screen are reversed in execution.
But that is already a problem with a single level statement modifier.
I don't think multiple levels introduces any more problem than is
already there.
It's just the same thing. Some people don't have problems using them,
many do.
Plus - if there are multiple modifiers then Perl poetry can get even
better. And everybody wins if Perl poetry is better. :)
say I'm ok
if $i_am_ok
if $you_are_ok
while $the_world_is_ok;
You can't even get near natural language. For example: in natural
language a double negation is often used to emphasize the negation.
--
Affijn, Ruud
Gewoon is een tijger.
Re: [svn:perl6-synopsis] r11965 - doc/trunk/design/syn
larry schreef: +Likewise, from the fact that list context flattens inner arrays and +lists, it follows that a reduced assignment does no special syntactic +dwimmery, and hence only scalar assigments are supported. Therefore + +[=] $x, @y, $z, 0 +[+=] $x, @y, $z, 1 + +are equivalent to + +$x = @y[0] = @y[1] = @y[2] ... @y[-1] = $z = 0 +$x += @y[0] += @y[1] += @y[2] ... @y[-1] += $z += 1 I assume that [=] $x, @y is equivalent to $x = @y[0] = @y[1] = @y[2] ... @y[-2] = y[-1] then. Or is a scalar required at the end? -- Affijn, Ruud Gewoon is een tijger.
Re: [svn:perl6-synopsis] r11965 - doc/trunk/design/syn
Larry Wall schreef: Dr.Ruud: larry: +Likewise, from the fact that list context flattens inner arrays and +lists, it follows that a reduced assignment does no special syntactic +dwimmery, and hence only scalar assigments are supported. Therefore + +[=] $x, @y, $z, 0 +[+=] $x, @y, $z, 1 + +are equivalent to + +$x = @y[0] = @y[1] = @y[2] ... @y[-1] = $z = 0 +$x += @y[0] += @y[1] += @y[2] ... @y[-1] += $z += 1 I assume that [=] $x, @y is equivalent to $x = @y[0] = @y[1] = @y[2] ... @y[-2] = @y[-1][_edited_] then. Yes. Or is a scalar required at the end? Yes, but @y[-1] is a perfectly fine scalar. Yes, but I meant it more at a 'source-filter' level. Suppose that you need to set everything to @y[0], I think you can code [=] $x, @y, @y[0]# looks clean, but does extra, # but maybe in an efficient order [=] $x, @y[1 .. *], @y[0] # hand-optimized? [=] $x, @y.reverse # or does .reverse copy? [=] $x, @y[reverse 0 .. *] # hi-brow? and what not. (Pardon my French.) -- Affijn, Ruud Gewoon is een tijger.
[OT] Unicode fonts (was: Re: Hash composers and code blocks)
Mark J. Reed: Aaron Sherman: Proposal: A sigil followed by [...] is always a composer for that type. %[...] - Hash. Unicode: ?...? @[...] - Array. Unicode: [...] ? - Seq. Unicode: ?...? [...] - Code. Unicode: ?...? |[...] - Capture. Identical to \(...). Unicode: ?...? $[...] - Scalar. Identical to item(value). Unicode: ?...? #[...] - A comment. Just seeing if you're paying attention ;) Are those supposed to be question marks up there (meaning up for discussion), or did something go awry in the email encoding (possibly on my end)? It took me a while to find a font that displays them: Code2000. http://en.wikipedia.org/wiki/Code2000 (shareware) See also: http://en.wikipedia.org/wiki/Free_software_Unicode_fonts http://en.wikipedia.org/wiki/Unicode_typefaces http://www.alanwood.net/unicode/fonts_windows.html -- Affijn, Ruud Gewoon is een tijger.
Re: S5: substitutions
Smylers schreef: in this particular case the particular behaviour involves _executing as Perl code something which the programmer never intended to be code in the first place_. That's crazily dangerous. I wouldn't mind eval() to be off by default, so to have to put a use eval in every block that needs it. -- Affijn, Ruud Gewoon is een tijger.
Re: class interface of roles
Jonathan Lang schreef:
role R does A does B does C { ... } # unordered composition
$x does A does B does C; # ordered composition
$y does A | B | C; # unordered composition
I'd like to see it done something like:
role R does A does B does C { ... } # unordered composition
$x does A does B does C; # ordered composition
$y does A does B does C; # unordered composition
And I was on the line of:
role R does A | B | C { ... } # unordered composition
$x does ( A, B, C ) ; # ordered composition
$y does A | B | C ; # unordered composition
but I would like early and late binding to be explicit.
Maybe the coder will use () around the run-time ones.
--
Affijn, Ruud
Gewoon is een tijger.
Re: named sub-expressions, n-ary functions, things and stuff
Smylers schreef:
my $whatever
= do { my $baz = $bar * 17; my $quux = $baz - 3; $baz / $quux };
($bar better not be 3/17)
Just a rewrite:
my $whatever
= do { my $quux = (my $baz = $bar * 17) - 3; $baz / $quux };
And maybe even something like:
my $whatever
= do { $.quux = ($.baz = $bar * 17) - 3; $.baz / $.quux };
(where quux and baz are topicals of the embracing do)
--
Affijn, Ruud
Gewoon is een tijger.
Re: Set-returning .keys
Smylers schreef: Ruud H.G. van Tol: Darren Duncan: TSa: set operations ... make them Bag operations to start with. I agree with ... making Set the main type and making Bag an extension built upon that, as complex is built upon num, etc. I don't think that will work out. Modification of a Set is more complex than modification of a Bag, so in that sense the Bag is the main type. Is this still the Perl 6 _Language_ group? The one where we consider what Perl 6 will do, and leave the implementation details to others? I don't consider much in this thread implementation oriented. In the part that you quote, I mentioned that putting a hierarchical order on Set vs. Bag has problems, because that order only applies to one side of them. The order was used for fall-back, to which I mentioned a context driven approach (like wantarray). -- Affijn, Ruud Gewoon is een tijger.
Re: Numeric Semantics
Luke Palmer schreef: When do we do integer/rational math and when do we do floating point math? That is, is 1 different from 1.0? Should 10**500 be infinity or a 1 with 500 zeroes after it? Should 10**10**6 run out of memory? Should say (1/3)**500 print a bunch of digits to the screen or print 0? These are just examples. Exponentials are the easiest to think about limit cases with, but the whole general issue needs precise semantics. A Numeric could have multiple faces: Integer, Rational, Float, etc. Some faces can have a Complex variant. A bitstring could flag which faces are actual (usable, non-dirty). Each face needs its own storage, for instance 1/2 could be stored as Integer 0 (or 1, or alternating between them), Rational 1 / 2 (or 2 ** -1), Float 1B-1, etc. Some conversions are without surprises, like from Integer to Float (because loss of precision is normal when going from Integer to Float, so even a difference of more than 1 is to be expected). From Float to (Big)Integer can result in an unexpected difference of 1. Or even in Inf. (just rambling) -- Affijn, Ruud Gewoon is een tijger.
Re: Map on a multislice
Joe Gottman schreef: When you call map on a multislice, does it do deep or shallow iteration? And with deep, there is the choice: depth first or not. -- Affijn, Ruud Gewoon is een tijger.
Re: [svn:perl6-synopsis] r13567 - doc/trunk/design/syn
Larry Wall schreef:
Dr.Ruud wrote:
I would expect
%hash.exists{$key}
Except $foo.bar{$key} is interpreted as $foo.bar().{$key}. Things
like exists and delete need to evaluate the key before calling
the method in question, not after.
OK.
with the shortcut
%hash.:{$key}
to test (at run-time) for existance of the element, and expect
%hash.:exists
to test (at compile time if possible) for the validity of 'exists',
more like
%hash.can('exists');
%hash.has('exists');
%hash.does('exists');
Why would you expect colon to do that? I don't see the prior art...
I was reading : as TEST (or indeed STATUS, or even STATE), and read the
part :exists a the STATUS (or validity) of exists(), which would
always be true (or 0) because exists() is in the hash-core.
So %table.:$key or %table.:{$key} would then be short for
%table.exists{key} (assuming exists() to be the default
TEST/STATUS/STATE-method for hash).
--
Affijn, Ruud
Gewoon is een tijger.
Re: Relief for rw/ro
Steve Lukas schreef: In between, I think 'variable' is too long, so: $code =~ s/variable/vari/g; I don't think it is too long, since most of the times you don't need to mention it. Could 'rw' be an alias? my rw @heredoc_stubs is context = (); my @heredoc_stubs is rw context = (); my @heredoc_stubs is context.rw = (); my @heredoc_stubs is context/rw = (); my @heredoc_stubs is context+w = (); -- Affijn, Ruud Gewoon is een tijger.
Re: [S09] Whatever indices and shaped arrays
David Green schreef: Jonathan Lang: (In fact, the semantics for @x[*+n] follows directly from the fact that an array returns the count of its elements in scalar context.) And @x[*] would be the same as @x[0..^*] or @x[0..(*-1)]. That's an elegance in its favour. In Perl5 a + can creep in, for example: $ perl -wle '$s = -123; $n = -123; print -$s; print -$n' +123 123 so maybe it is not a bad idea to keep treating a unary + as (almost) a no-op. -- Affijn, Ruud Gewoon is een tijger.
Re: [svn:perl6-synopsis] r14362 - doc/trunk/design/syn
[EMAIL PROTECTED] schreef: -Attempting to access an index outside a array's defined range will fail: +Attempting to access an index outside an array's defined range will fail: Idea for Perl6 test code: detecting (simple) typos in documentation. -- Affijn, Ruud Gewoon is een tijger.
Re: Indirect objects, adverbial arguments and whitespace
Markus Laker schreef: If I've got this right: mangle $foo :a;# mangle($foo, a = 1); mangle $foo: a;# $foo.mangle(a()); So these -- mangle $foo:a; mangle $foo : a; are ambiguous and, as far as I can tell from the synopses, undefined. So what's the rule: that indirect-object colon needs whitespace after but not before, and adverbial colon needs whitespace before but not after? The reason I ask is that I'm knocking up an intro to Perl 6 for C and C++ programmers. I expect some of Perl 6's whitespace rules to trip up people used to C++ (as they have me, in my clumsy attempts with Pugs), and I'd like to summarise all the whitespace dwimmery in one place. We were making fun of this: news:[EMAIL PROTECTED] -- Affijn, Ruud Gewoon is een tijger.
Re: pluralization idea that keeps bugging me
Jonathan Lang schreef: I'm not fond of the 'ox\soxen' idea; but I could get behind something like '\sox oxen' or 'ox\sen'. $n ox\s en $n\sone multiple no cat\s s fight\s s s ;) -- Affijn, Ruud Gewoon is een tijger.
Re: treatment of isa and inheritance
TSa schreef: Brandon S. Allbery: It occurs to me that this shouldn't be new keywords, but adverbs, i.e. ``is :strict Dog''. Great idea! And it leaves room for ':stricter' and ':strictest'. ;) -- Affijn, Ruud Gewoon is een tijger.
Re: What happened to err operator?
TSa (Thomas Sandlaß) schreef:
Larry Wall:
Another potential issue is that CATCH doesn't distinguish exceptions
coming from the current block from those coming from the subcall to
a(). So it could end up returning Failure from the current block when
you intended to force return of Failure from a(). Not sure what
to do about that...
I don't understand this issue. I think we have the fact that
*every* operator is at least conceptually dispatched and as
such everything in a block is at least one level down in the
call chain just as a() as a sub call is. This is why a CATCH
block inside the block is so natural to me.
If I understand your intention correctly you want to be able
to force a thrown exception from a() into a returned value
and proceed where this return value is supposed to show up
in the current block, right? The simplest solution that comes
to my mind is some form of goto to that position. Or is that
too inelegant? The point is how the CATCH block knows from
which subordinate scope the exception originates.
a() proceed: orelse b();
CATCH
{
... # make $! into return value
goto proceed;
}
This kind of needs to know the variable the return value of a()
is stored into. This is easy if orelse is checking $! anyway.
But does it? And is it possible to have labels in the middle
of a line as above?
Maybe the = should deliver the normal (=value) part of the
return-stash, and a different deliverer should be used to get other
information out of it.
--
Affijn, Ruud
Gewoon is een tijger.
