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.
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: 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: 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: [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: [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: 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: [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: [svn:perl6-synopsis] r13567 - doc/trunk/design/syn
[EMAIL PROTECTED] schreef:
Just glad someone's reading these things...
Of course we are. But it is hard to react when the syntax isn't in your
muscle memory yet.
From r13565:
+%hash.:exists{$key}
I would expect
%hash.exists{$key}
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');
--
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: 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: 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: 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: 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: 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.
[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: [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.
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: 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: 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: 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: 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: === 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: ===, =:=, ~~, 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.
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
[META] Re: [perl #39842] [PATCH] Win32 PLATFORMS update (r13309)
Will Coleda via RT schreef: Thanks, applied as r13316. Twice? 3c3 Xref: nntp.perl.org perl.perl6.internals:34222 --- Xref: nntp.perl.org perl.perl6.internals:34223 7c7 Received: (qmail 22397 invoked from network); 16 Jul 2006 15:09:07 - --- Received: (qmail 22778 invoked from network); 16 Jul 2006 15:09:09 - 9,10c9,10 by lists.develooper.com with SMTP; 16 Jul 2006 15:09:07 - Received: (qmail 19778 invoked by uid 225); 16 Jul 2006 15:09:07 - --- by lists.develooper.com with SMTP; 16 Jul 2006 15:09:09 - Received: (qmail 19794 invoked by uid 225); 16 Jul 2006 15:09:09 - 12c12 Received: (qmail 19773 invoked by alias); 16 Jul 2006 15:09:06 - --- Received: (qmail 19786 invoked by alias); 16 Jul 2006 15:09:08 - 18c18 by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sun, 16 Jul 2006 08:08:51 -0700 --- by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sun, 16 Jul 2006 08:08:52 -0700 20c20 id 4291BD3D3E; Sun, 16 Jul 2006 08:08:46 -0700 (PDT) --- id 24A7CD3D64; Sun, 16 Jul 2006 08:08:48 -0700 (PDT) 25c25 Message-ID: [EMAIL PROTECTED] --- Message-ID: [EMAIL PROTECTED] 36c36 Date: Sun, 16 Jul 2006 08:08:46 -0700 --- Date: Sun, 16 Jul 2006 08:08:48 -0700 Lately, I see more such doubles. -- 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.
Re: PGE and TGE vs. .namespace
Allison Randal schreef: Chip Salzenberg: The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) TGE and PGE both need a thorough going-over for the new namespaces implementation. I'm thinking they should act in an HLL-agnostic fashion, so it's possible to compile one grammar in, say, the Perl 6 HLL namespace, another in Ruby, another in Python, and another system-internal grammar into 'parrot'. Maybe an automagical namespace alias 'root' is feasible? -- Affijn, Ruud Gewoon is een tijger.
Re: 3 Good Reasons...
Michael Mathews schreef: [compile down to a *language independent* format] So does that mean I can write a module in Perl 6, deliver it to Mr. Customer as byte-code. Then Mr. Customer can decompile(?) it into Python (or JavaScript, or C, etc), edit it, and then compile it back into working byte-code again? No, compiling to bytecode is like a one way street: you will probably not remain recognizable when you drive it in the opposite way. It is less hard to go from Perl6-code to Python-code or rather v.v. But there is no need for all that. Think about the libraries compiled from C-code that are now linked with Perl5. You can do something similar with Parrot: create libraries that can be efficiently linked with code written in other languages (that compile to Parrot). Mixed language source code, even cleaner than the current Perl5 with Inline.pm, is another feasibility. -- Affijn, Ruud Gewoon is een tijger.
Re: 3 Good Reasons...
Michael Mathews schreef: [attribution repaired] Ruud: [attribution repaired] Michael: (Michael previously sent me an independent off-list reply; we're back on the list now) As I gradually learn how Parrot works, I see that perhaps the idea of decompiling byte-code into language ___ is only a pipe-dream. But the point still remains--using the fact that one *could* mix languages X, Y, and P into your company's source tree is a very weak argument for Parrot/Perl6. I would say it is a non-argument. Not really. Think about a Cobol-to-Parrot translator. You could for example use Perl (glue) to add GUI stuff to old Cobol programs. Just see it as a way to solve real problems. You don't have to use it yourself. I'll try to be more clear. The original question was seeking opinions on what the big gains were for companies to switch to Parrot/Perl6 (someday). My point was that saying it would allow a mixture of languages to be used in an application is, in my real-world experience, not something companies are currently seeking, plus you don't need to upgrade to do it, so it isn't really a selling point worth bringing up to your local IT Manager type person. Then don't use this point to sell it to that manager. it also means she now has to keep a Java/PHP/Perl programmer around and happy whenever one of three different languages might throw a buggie. No, it is not limited by that. Huh? Let me give an actual example. A major broadcasting company I was contracted with needed to change part of their gigantic code base that dealt with a data source of live sports scores (which were automatically displayed on air). The code was all Perl :-) except for one chunk in Python--so guess where the problem was. This had to be fixed FAST and no one in the office knew Python well enough to do it, including me (the guy who wrote the Python was long gone to work at Google). In the end it was decided to rewrite that chunk in Perl. I can tell you, there definitely was cursing in the office that day, and I doubt anyone there would see it as a plus to have the ability to mix languages more easily. I just wouldn't put it that way if I were trying to sell Perl6 to a business manager. I already knew from the start that you had a bad experience in this area. ;) Of course you don't want your car built partly with metric and partly with English measured parts. http://en.wikipedia.org/wiki/Metrication But that is not what this is about. The feature is not designed to crash a spacecraft, but of course somebody will still use it for that. In my experience Perl has an (undeserved) bad reputation in regards to large, long-term projects because it allows too much flexibility. That will not change. Really that means management has to do work to set and enforce standards, but those managers aren't going to be impressed by hearing Perl 6 makes it easy to mix lots of different languages together. Nevermind how cool/useful I personally think that is. I like it that Perl5 and C go so well together. I dislike Java, so I don't care for it. Let's just make Perl6/Parrot the ultimate Cobol shell as well. -- Affijn, Ruud Gewoon is een tijger.
Re: 3 Good Reasons...
Gabor Szabo schreef:
{Cobol etc.]
IMHO - and I really saw only a few such companies - these companies
have 0 automatic tests so it would cost them a lot of time and money
to test their application on the new and shiny Cobol compiler.
I once worked on tests for a national center of a bank, to monitor the
nightly runs of big money flowing. The Cobol programs ran on mainframes;
there were several IBM PCs, with character terminal emulation software,
connected to them.
On each PC there was a stack of C-programs, generated with yacc and lex.
When a fresh screen came up, a main program deducted the proper test for
it and ran it. When the test failed, the PC would start beeping and
flashing, to wake up the one operator that remained: this software
replaced a couple of people that once did the same tests with mental
arithmetic and a pocket calculator.
The terminal emulation software had a very raw INT-something-API (HLLAPI
IIRC), and IBM had updated the terminal emulation software but hadn't
updated the (never supported) linkable library layer for the API, so the
first thing I had to do was to create a replacement library. That took
only half a day, because the documentation of IBM was OK, and I could
generate much of the C-code with a few macros. I wondered why IBM hadn't
done that, it would have been a nice gesture.
http://www.webopedia.com/TERM/H/HLLAPI.html
Next I had to check the test programs, because they failed often. These
were full of strdups without frees and things like that, they were made
by a Pascal programmer. It took me two days to fix all those yacc/lex
sources, throwing away about 90% of them because there was a lot of
duplication. Basically such a program would check the layout of the
screen, copy a few numbers from it and do some calculations on them,
then store the result in a log. And of course it would bark when things
didn't add up.
Monitoring, regular expressions, character based: nothing much has
changed.
http://search.cpan.org/~grommel/Convert-IBM390/IBM390.pod
http://search.cpan.org/~ingy/Inline/Inline-API.pod
The Inline community will decide if your implementation of COBOL will
be distributed as the official Inline::COBOL or should use an alternate
namespace. :)
--
Affijn, Ruud
Gewoon is een tijger.
Re: Simple Print/Say Question
Chris Yocum schreef: print @array[0] ~ | ~ @array[1] ~ | ~ @array[2] . \n; First the Perl6-equivalent of $ = '|' ; and then say @array ; -- 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.
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.
[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.
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.
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: [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] 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] 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: 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: Parrot Shootout
Roger Browne:
Unfortunately I could only get to Ack(3, 6) before parrot aborted with
maximum recursion depth exceeded, at recursion depth 1000.
Alternative:
#!/usr/bin/perl
use strict;
use warnings;
use Memoize;
{ local ($,, $\) = (\t, \n);
sub ack {
return $_[1] +1 if 0 == $_[0];
return ack($_[0] -1, 1) if 0 == $_[1];
return ack($_[0] -1, ack($_[0], $_[1] -1));
}
memoize('ack');
my $base = 3;
print Ack($base, $_): , ack($base, $_) for (0..13);
}
--
Affijn, Ruud
Gewoon is een tijger.
Re: Parrot Shootout
Leopold Toetsch:
Dr.Ruud:
Roger Browne:
Unfortunately I could only get to Ack(3, 6) before parrot aborted
with maximum recursion depth exceeded, at recursion depth 1000.
Alternative: use Memoize;
Sure. And there is a (inline) memoized perl Ack already, which is one
of the fastest of all tests submitted.
The goal of these benchmarks is to run 'as is' with the same
algorithm.
Define the same algorithm.
(Some language could memoize when it is not explicitly told so.)
If there would be a volatile attribute for sub, to define that the sub
is non-memoizable (or that its runs are not cacheable), than the
'algorithm' would not need the use Memoize and memoize('ack') lines.
--
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: 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.
