Re: [perl #58474] Re: Match bug, $0 empty
Hi! I think this bug is the same as #58352. Yes, it is. I try to say that when I And excuse me again -- open ticket #58352 about that problem. excuse my bad English ( And thus it can be worked around, for the time being, doing this: ... Ok! I will use it; Ilya
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Sep 1 13:00:02 2008 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 35 new + 658 open = 693 Created this week: 9 Closed this week: 11 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 58250 [TODO] Generate callgrind output 58188 [TODO] Parrot_find_encoding_converter 58176 [PATCH] dotnet exceptions 58108 [BUILD] languages/Makefile 'test' target has too many deps 58090 [PATCH] [pdd27mmd] Deprecate mmd_create_builtin_multi_meth_2 58070 [RFC] Disallow .local declarations in long-style call statement 2 - 3 weeks old 58050 Segfault in make testr for t/compilers/imcc/syn/hll.t:2 57902 [PATCH] PLATFORMS update -- Solaris is broken 3 - 4 weeks old 57776 [BUG] PIO_buf_read segfault 57728 [TODO] avoid 2038 bug if we haven't already. 57680 [CAGE] Problems in find_write_record 57678 [CAGE] Poor Man's Deadlock Detection 57676 [CAGE] Check for shared status of STM handle 57638 [IMCC] old-style PASM registers no longer supported. 57610 [PATCH] Resumable exceptions 4 - 5 weeks old 57436 [RFC] Change .get_results to not return message, just exception 57432 [DEPRECATED] [PDD19] .HLL_map with comma 57426 [TODO] [PDD19] Implement new .HLL directive 5 - 6 weeks old 57236 [TODO] pbc_to_exe --install pbc1 [pbc2...] 6 - 7 weeks old 57120 [BUG] examples/library/ncurses_life.pir broken 57088 Tcl's [lsort] failure (aka inferior runloop problem) 56972 Error in link 7 - 8 weeks old 56782 [TODO] question in getNameForKey in Getopt::Obj 56712 [BUG] --optimize causes perl6 to segfault during make 8 - 9 weeks old 56634 [RFC] future direction for config 56622 [BUG?] 'isa' opcode returns inconsistent results 56614 [TODO] Config hash should be marked read-only 9 - 10 weeks old 56458 Failure to promote RetContinuation objects 10 - 11 weeks old 11 - 12 weeks old 12 - 13 weeks old 13 - 14 weeks old 14 - 15 weeks old 15 - 16 weeks old 54236 [TODO] Allow Parrot Hashes to have PMC keys 16 - 17 weeks old 17 - 18 weeks old 18 - 19 weeks old 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues PlatformSeverity Tag Lang aix0abandoned 05005threads 0 Amber 0 All1fatal 1bounce0 BASIC 0 bsdos 0High 0Bug 109 bc 0 cygwin 2low 0compiler 0 befunge 0 cygwin_nt 0medium1configure 4 bf 0 darwin 8none 1core 2 cola0 dec_osf0Normal3dailybuild0 forth 0 dgux 0unknown 0docs 3 jako0 dos0Wishlist 3duplicate 0 Lisp0 dynixptx 0 install 2 lolcode 0 freebsd5 library 0 m4 0 generic0 notabug 0 ook 0 gnu0 notok 0 perl6 2 HPUX 2 ok0 plot0 irix 0 Patch42 punie 0 irix64 0 regex 2 pynie 0 Linux 1 sendToCPAN0 python 0 lynxos 0 Todo319 ruby0 mac0 unknown 0 scheme 0 machten0 utilities 0 tcl 1 macos 0 wontfix 0 urm 0 MacOS X9 Zcode 0 mswin322 netbsd 1 next 0 openbsd2 os20 os390 0 other 0 powerux0 qnx0 riscos 0 sco0 Solaris7 sunos 1 svr4 0 svr5 0 sysv 0 unicos 0 unicosmk 0 unix 0 unknown0 uts0 vms0 VOS0 Win32 10 --- Ticket Status By Version New or OpenResolved --- Requestors with most open tickets Paul Cochrane 220 Will Coleda71 Patrick R. Michaud 32 chromatic 28 Klaas-Jan Stol 26
Re: [perl #58474] Re: Match bug, $0 empty
Илья (): I think this bug is the same as #58352. Yes, it is. I try to say that when I And excuse me again -- open ticket #58352 about that problem. No problem -- there was a bit of lag on the mailing list, that's all. I got your self-reply after I wrote my reply, even though you sent it before. (Also, It's partly a good thing that the same bug is reported many times -- it gives Rakudo implementors a hint that many people in parallel are running up against the same bug. In this case, it also gave me a chance to tell you how we are currently directing around the problem. Win-win.) // Carl
Re: [perl #58424] Named regex, token and rule don't work outside of a grammar
Patrick R. Michaud wrote:
On Thu, Aug 28, 2008 at 08:32:41AM -0700, Carl Mäsak wrote:
r30590:
$ ./perl6 -e 'regex a { b }; b ~~ a'
too few arguments passed (0) - 2 params expected
[...]
I've also added tests for this in t/spec/S05-metasyntax/regex.t.
(S05 is not entirely clear as to whether this should actually work.
IMHO, there's noreason for it not to. Storing anonymous regexes in
scalar variables already works.)
$ ./perl6 -e 'my $a = regex { b }; say b ~~ $a'
b
For now I'm going to claim that Rakudo has this one correct. The
difference between the first and second examples above is that in
the scalar variable example, the $a variable passed to infix:~~
contains the regex sub itself, whereas in the first example the
a regex is being invoked as a 0-argument listop prior to calling
the smart match.
I'm not quite sure. To quote S03:
The first section contains privileged syntax; if a match can be done
via one of those entries, it will be. These special syntaxes are
dispatched by their form rather than their type.
[...]
$_X Type of Match Implied Match if (given $_)
=== = ===
Any Code:($) item sub truth X($_)
So what does the Code mean? A code object? or the name of a sub?
Since it says that the first dispatch is based on the form, I could
imagine that ~~ has some kind of macro semantics, actually.
CC'ing p6l in the hope of some clarification.
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: how much detail can I get from caller.want?
HaloO, John M. Dlugosz wrote: Perhaps the supplier of the CPAN module for the nth function could also include, besides the actual function, an optimization pattern plug-in that locates the idiom in the parse tree and replaces the expression with a call to nth. Wouldn't a dispatch target postcircumfix:[ ]:(LazySortedList,Int) suffice when the sort would return such a thing? Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: [svn:parrot-pdd] r30622 - trunk/docs/pdds/draft
Bob Rogers wrote: Allison Randal wrote: +Monkeypatching is certainly possible, but not encouraged. Cool; a new term in Allison-speak! ;-} As much as linguists love creating new words, I can't claim credit for this one: http://en.wikipedia.org/wiki/Monkey_patch More later, Allison
Re: [svn:parrot-pdd] r30622 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED] Date: Mon, 01 Sep 2008 20:31:18 +0200 Bob Rogers wrote: Allison Randal wrote: +Monkeypatching is certainly possible, but not encouraged. Cool; a new term in Allison-speak! ;-} As much as linguists love creating new words, I can't claim credit for this one: http://en.wikipedia.org/wiki/Monkey_patch I didn't mean to imply that you had invented it, merely that you had incorporated it into your own working vocabulary. -- Bob
Re: how much detail can I get from caller.want?
On Mon, Sep 01, 2008 at 05:52:28PM +0200, TSa wrote: HaloO, John M. Dlugosz wrote: Perhaps the supplier of the CPAN module for the nth function could also include, besides the actual function, an optimization pattern plug-in that locates the idiom in the parse tree and replaces the expression with a call to nth. Wouldn't a dispatch target postcircumfix:[ ]:(LazySortedList,Int) suffice when the sort would return such a thing? I suspect that warping the semantics of sort to support lazy readout will tend to adversely affect the performance of a normal sort (in an O(n²) kind of way), so I would rather optimize for sorting the entire list (the common case) and leave the top-n kinds of cases to a more specialized algorithm. (I would consider the problem posed in the OP to be somewhat artificial in any case.) All that being said, it's possible that, once we've written a sort routine without taking laziness into account (using, say, quicksort), the normal laziness of lists will kick in and essentially turn all of the partition calls into a kind of unbalanced heap algorithm. In any case, the sort algoritm may choose to eagerly evaluate as many elements as it likes in a batch in order to stay in the cache. In the limit, the algorithm may eagerly sort the entire list if it feels like it doesnt want to share the cache with anyone else. More generally, Perl 6 programs are not allowed to depend on strict laziness because strict laziness assumes a uniform memory access model that is unrealistic both in the current world of caching and the future world of NUMA. Strict laziness makes it much more difficult to do speculative execution on some of your spare multicores if other parts of your program are depending on whether something has been evaluated yet or not, and parts of your program disagree on that subject. Maybe quantum computers will allow such superposed entanglements, but Dr Von Neumann doesn't seem to like 'em. Yeah, I know, FP thinks it has the Correct Answer to that, but until someone invents a quantum computer that can lift monads, we have to worry about side effects sooner or later... :) Larry
Re: how much detail can I get from caller.want?
On 2008 Sep 1, at 15:20, Larry Wall wrote: On Mon, Sep 01, 2008 at 05:52:28PM +0200, TSa wrote: John M. Dlugosz wrote: Perhaps the supplier of the CPAN module for the nth function could also include, besides the actual function, an optimization pattern plug-in that locates the idiom in the parse tree and replaces the expression with a call to nth. Wouldn't a dispatch target postcircumfix:[ ]:(LazySortedList,Int) suffice when the sort would return such a thing? I suspect that warping the semantics of sort to support lazy readout will tend to adversely affect the performance of a normal sort (in an O(n²) kind of way), so I would rather optimize for sorting the You might want to take a look at the sort used by ghc (not the one in the Haskell Prelude) before committing to that. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: What happened to err operator?
On Sun, Aug 31, 2008 at 04:28:36PM -0500, John M. Dlugosz wrote: Has the err operator, as a low-precidence version of //, been removed? Yes. It's not mentioned in S03, and the semantics of orelse is different. Is orelse supposed to be a direct replacement, meaning if you ignore the parameter thing then it doesn't change anything? You can use it the same way, but if you think of // and orelse as the same operator at different precedence, it's not quite the reality. I don't believe there is such a thing as a defined-or operator. I think of // instead as a default operator, and as such it's primarily useful at a precedence tighter than infix:=, and it almost never cares about *why* the left side is undefined. The orelse operator is aimed at logic programming, not defaulting, and in logic programming the right side can often have additional dependencies on the left side. It's almost an accident that both operators care about whether the left side is defined. (This is also why there is no tight version of andthen.) Of course, there's more to it than that. Politically, it's a kind of compromise between p5p and me. I hated their dor operator, and p5p by and large hated the err operator. The result was that we switched to orelse and they dropped dor. So the preceding paragraph can be construed as a mere rationalization of why the sausage came out of the sausage factor green this time. :) Larry
Re: how much detail can I get from caller.want?
On Mon, Sep 01, 2008 at 03:40:39PM -0400, Brandon S. Allbery KF8NH wrote: On 2008 Sep 1, at 15:20, Larry Wall wrote: On Mon, Sep 01, 2008 at 05:52:28PM +0200, TSa wrote: John M. Dlugosz wrote: Perhaps the supplier of the CPAN module for the nth function could also include, besides the actual function, an optimization pattern plug-in that locates the idiom in the parse tree and replaces the expression with a call to nth. Wouldn't a dispatch target postcircumfix:[ ]:(LazySortedList,Int) suffice when the sort would return such a thing? I suspect that warping the semantics of sort to support lazy readout will tend to adversely affect the performance of a normal sort (in an O(n²) kind of way), so I would rather optimize for sorting the You might want to take a look at the sort used by ghc (not the one in the Haskell Prelude) before committing to that. Yeah, but then I'd have to learn Haskell yet again. :) In any case, Haskell can depend on the absence of side effects in a way that Perl can only mandate by fiat. That's the price Perl pays for being mundane. Larry
Re: [svn:parrot-pdd] r30622 - trunk/docs/pdds/draft
Bob Rogers wrote:
+{{ There seems to be an implied basic assumption here that language
+interoperability is the responsibility of the language
+implementor. It is not. We cannot require that language
+implementors design and implement their languages according to some
+global specification.
If you are not happy with that assumption, then I'm surprised you
bothered to commit this draft at all, even as a starting point.
Design is a process. If you don't understand what I'm getting at, then
it means I haven't explained it well enough yet. And, revising the draft
to help you understand also produces a design document, so it's doubly
useful.
Even
then, surely, it must *still* be the responsibility of the language
implementor not to introduce gratuitous barriers to interoperability?
As a case in point, consider keyword (named) parameters in Lisp.
Kea-CL does not use Parrot named parameters to implement key, partly
for ANSI compliance and partly for efficiency. This currently makes it
problematic (though not impossible) for other languages to call Lisp
functions that accept keywords. You can either say I'm a bad boy for
not fully using Parrot features and require me to design and
implement ... according to some global specification, forcing me to
solve the performance vs. compliance vs. interoperability tradeoff in
each sub, or allow me to do my own thing internally and accept the need
for glue around the edges (which in turn requires compliance with
another specification).
Well, my main question from that is what it is about Parrot named
parameters that don't work for Kea-CL. (It may be something we can fix.)
But, what I expect from Kea-CL with a unique parameter-passing style is
that your libraries clearly document how to call the subroutines. That's
all. If people find libraries written in your language too obtuse to
bother with, then they simply won't use them.
There are an awful lot of musts in the draft, where there should be
only free will.
Another example is object system metamodel compatibility. I am not
an expert on metamodels, but all the ones I *think* I know make it very
hard for me to imagine inheritance across language boundaries without
some very careful design and coding on the part of language implementors
on both sides of the boundary. (Who will no doubt be grateful for some
global specification to help them in that work. ;-)
The interoperability infrastructure is the vtable functions. You can
have absolutely any metamodel you want, just provide a minimal set of
functionality so Parrot can instantiate objects from your class, invoke
methods, and get and set attribute values.
Inheritance across language boundaries works by proxying and delegation.
It's true that a class in one language won't know how to, for example,
look up a method in a parent class from another language. So, it can't
poke directly into the parent and do the lookup, but it can ask the
parent to do the lookup. Poking directly into the parent breaks
encapsulation anyway, generally a bad idea.
Do you really think that Parrot can subsume all object system metamodels
well enough to provide all the infrastructure? Just the CLOS and Perl 6
MOPs are each complicated enough on their own; I'm tempted to advocate
$n^2$ metamodel interfaces in order to break the problem down into
manageable chunks. (And, not incidentally, push the problems onto the
people who understand them.)
If you mean Do you think Parrot can build an enormous and complex
interoperability infrastructure that handles all possible language
semantics now and in the future?, the answer is absolutely not, and
let's avoid that like the plague. The point is to keep it as barebones
as possible, and leave each language to implement whatever custom
behavior they need behind the vtable function interface.
+{{ It's not possible to define a sub that can't be called externally
--allison }}
Not now, true. Except that we currently support .sub foo :anon ...
for compilation-unit scoping. Are you saying you object to language
scoping of subs?
Sure, but if that scoped sub was returned as a subroutine object to
another language, it could be invoked as a subroutine by that language.
+{{ Exporting is very much a Perl idea, not much applicability for exporting
+outside of Perl. --allison}}
Eh? I think we are having another terminology issue. By export I
meant make public. Perl is not the only language to use this term;
just off the top of my head I can think of CL and Erlang.
Ah, by export I mean inject into the caller's namespace (Perl
terminology). Any subroutines stored in a namespace are already public,
so I'm not sure what you meant.
I *could* represent CL strings explicitly as vectors of characters
instead of using the String type. But that would mean that I couldn't
use the wealth of Parrot string ops, and would be inviting more
interoperability problems to boot. Ditto
[svn:perl6-synopsis] r14578 - doc/trunk/design/syn
Author: larry Date: Mon Sep 1 17:02:00 2008 New Revision: 14578 Modified: doc/trunk/design/syn/S02.pod Log: added Rat type to list of immutables, mbiggar++ Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Sep 1 17:02:00 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 8 Aug 2008 + Last Modified: 1 Sep 2008 Number: 2 - Version: 136 + Version: 137 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -885,6 +885,7 @@ Int Perl integer (allows Inf/NaN, arbitrary precision, etc.) Str Perl string (finite sequence of Unicode characters) Num Perl number +Rat Perl rational Complex Perl complex number BoolPerl boolean Exception Perl exception
[svn:perl6-synopsis] r14579 - doc/trunk/design/syn
Author: larry
Date: Mon Sep 1 18:12:53 2008
New Revision: 14579
Modified:
doc/trunk/design/syn/S04.pod
Log:
clarify that statement introducers may not use function syntax, which is
reserved for user functions of the same name
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podMon Sep 1 18:12:53 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 19 Aug 2004
- Last Modified: 16 July 2008
+ Last Modified: 1 Sep 2008
Number: 4
- Version: 68
+ Version: 69
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -645,9 +645,10 @@
establish a dynamic scope without necessarily establishing a lexical
scope. (You can always establish a lexical scope explicitly by using
the block form of argument.) As statement introducers, all these
-keywords must be followed by whitespace. You can say something
-like Ctry({...}), but then you are calling it using function call
-syntax instead, in which case the CCode argument must be a block.
+keywords must be followed by whitespace. (You can say something
+like Ctry({...}), but then you are calling the Ctry() function
+using function call syntax instead, and since Perl does not supply
+such a function, it will be assumed to be a user-defined function.)
For purposes of flow control, none of these forms are considered loops,
but they may easily be applied to a normal loop.
Re: [svn:parrot-pdd] r30622 - trunk/docs/pdds/draft
From: Allison Randal [EMAIL PROTECTED] Date: Tue, 02 Sep 2008 01:15:18 +0200 Thank you for responding so promptly; I doubt I will be able to return fire on your schedule. Bob Rogers wrote: As a case in point, consider keyword (named) parameters in Lisp. Kea-CL does not use Parrot named parameters to implement key . . . Well, my main question from that is what it is about Parrot named parameters that don't work for Kea-CL. (It may be something we can fix.) I will answer this now, since you ask, and because I had written it up for the previous post and then decided that it was too much detail. Please see below. But, what I expect from Kea-CL with a unique parameter-passing style is that your libraries clearly document how to call the subroutines. That's all. If people find libraries written in your language too obtuse to bother with, then they simply won't use them. Yes. If I do nothing else, then this corresponds to option c below, which meets my criteria for too obtuse. There are an awful lot of musts in the draft, where there should be only free will. Guilty as charged. My intent is usually must do X in order to maximimize interoperability, but that is not clear. Should is much better. And the rest will have to wait until I have more time. -- Bob To explain why I think it is inevitable that language implementors will have to shoulder at least some of the burden, let me describe an interoperability problem that affects Kea-CL (and ANSI-compliant Common Lisp implementations in general). The ANSI spec says two things about keyword parameters [1] that constrain how they can be implemented in Parrot: 1. Keyword parameters are typically named by symbols in the KEYWORD package, but are permitted to be named by any object; such objects are tested for identity when binding keyword parameters. Therefore, the symbols :foo and frobboz::foo are distinct as keyword parameter names, even though they might stringify the same [2]. 2. At the point of call, there is no distinction between different kinds of parameters. For example, in the call (test-function foo bar :start1 17) the last two arguments could supply values to a single keyword parameter named :start1, or to the third and fourth positional parameters. Or the whole thing could be a single rest (slurpy) parameter; the compiler is not allowed to guess here [3]. Because Parrot named parameters are handled as a separate class of parameter, and are always named by strings, that presents a severe problem. An implementation can choose to: a. Punt on ANSI compliance, mapping Lisp keywords onto Parrot named parameters. I don't think this possible, since there's no way to tell at the point of call. b. Adopt a hybrid approach and declare keyword parameters as Parrot named parameters, adding some extra processing logic to handle conversion; i.e. all functions support both protocols. If the named parameters are filled by a non-Lisp call, add them to any rest list; if an rest list has keyword values that are not yet supplied, stuff the values in the named parameters. This ought to work (I haven't tried it), but entails a certain amount of extra overhead, even for the Lisp-to-Lisp case. c. Use the straightforward Lispy implementation (i.e. by ignoring Parrot named parameters altogether) and insist that the caller supply key arguments using Lisp symbols as positional parameters. Any caller would have to do the equivalent of (intern FOO (find-package KEYWORD)) just to look up the parameter name for :foo. (This is the current unsatisfactory state of affairs). d. Use the straightforward Lispy implementation (i.e. by ignoring Parrot named parameters altogether) and plan to provide a wrapper for each API function that has keywords for foreign calling. My proposal is about option d, because I think that is the best option for Lisp, and I think it should work well for other languages, too. [1] http://www.lispworks.com/documentation/HyperSpec/Body/03_dad.htm [2] But stringification is not a CL concept anyway. Coercion to string is usually tied up with printing, but printing yields different results depending on context. [3] Some compilers optimize based on prior knowledge of the definition being called, but that is not strictly legal, and always requires a non-default level of optimization.
