Re: reduce metaoperator on an empty list
On Tuesday 07 June 2005 08:08, Larry Wall wrote: Okay, I've made up my mind. The err option is not tenable because it can cloak real exceptions, and having multiple versions of reduce is simply multiplying entities without adding much power. So let's allow an optional identvalue trait on operators. If it's there, reduce can use it. If it's not, reduce returns failure on 0 args. Built-in addition will have an identity value of 0, while multiplication will have an identity value of 1. String concatenation will have . The table of Iverson's chosen identities in J is at http://www.jsoftware.com/books/help/dictionary/d420.htm He uses _ for +Inf and __ for -Inf and does cover and . We can go as far as having -Inf on [] and +Inf on [], but maybe that means we have to define values that are positive and negative infinity on strings so we can get [gt] and [lt] indentity values. Those might be useful in any event. My Second System alarm is going off. What is the result of (-Inf)~(+Inf) or whatever the syntax would be? Or indeed (-Inf)~$String for any string? I know what it means to say that +Inf is the identity for a numeric min function, and -Inf for max, but an infinite string value baffles me. It would have to satisfy -Inf le , right? But with no values in between? When considering what extensions to make in APL and J, Iverson always asked what identities could be preserved at the boundaries. Thus if C is identical to A,B (APL catenation) with neither A nor B empty, then f/C is identical to (f/A)f(f/B). So using identity elements, we can extend this identity to some functions, and to arrays within their domains. What identities did you have in mind for string infinities? What sort of reduction can you do on Hello, ~(+Inf)~world? How does it print? What good is it at all? -- Edward Cherlin Generalist activist--Linux, languages, literacy and more A knot! Oh, do let me help to undo it! --Alice in Wonderland http://cherlin.blogspot.com
Re: Ordered Hashes -- more thoughts
At 4:05 PM -0400 6/8/05, Tolkin, Steve wrote: Summary: An ordered hash that does not support deletes could cause a user visible bug. At a minimum it should support the special case of delete that is supported by the Perl each() operator. Details: This Week in Perl 6, May 25, 2005-May 31, 2005 http://www.perl.com/pub/a/2005/06/p6pdigest/20050602.htmlhttp://www.perl.com/pub/a/2005/06/p6pdigest/20050602.html has a brief discussion of Ordered Hashes with this link http://groups-beta.google.com/group/perl.perl6.internals/browse_frm/thread/86466b906c8e6e10/24a935c5c2c71aa8#24a935c5c2c71aa8http://groups-beta.google.com/group/perl.perl6.internals/browse_frm/thread/86466b906c8e6e10/24a935c5c2c71aa8#24a935c5c2c71aa8 where Dan Sugalski says: I'd just pitch an exception if code deletes an entry ... Perhaps this is OK, because this code is intended for internal use only. But people like to reuse code, and if anyone writes an ordered hash module on top of this code it will have a bug. Which is why it ought not get reused. The whole point of the original ordered hash was to support lexical pads as fast as possible while still allowing by-name lookup for introspective code. Doing anything that compromises fast array-based lookup would be ill-advised for that. If it makes sublclassing tough, well... subclassing continuations is likely going to be problematic too, but that's fine. Reuse is good but everything doesn't need to be reusable. Special purpose data structures are just fine too. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #36223] [PATCH]Loop Preheader
# New Ticket Created by Curtis Rawls # Please include the string: [perl #36223] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36223 This patch adds a new function, natural_preheader(), to cfg.c. This function finds and returns the preheader of a loop, if one exists. The preheader of a loop is the only predecessor of the loop's header outside of the loop, and the header is the only successor of the preheader. Therefore, the preheader's code always executes immediately before entering the loop body. The preheader is useful in the Loop-Invariant Code Motion optimization. -Curtis Rawls preheader.patch Description: Binary data
Re: Musing on registerable event handlers for some specific events
Gaal Yahas wrote:
On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote:
There will certainly be an event manager for all sorts of events floating
around in Perl 6. The main trick will be to hide this from the people
who aren't interested. The other trick will be to actually spec it,
since up till now I've assumed that it should be specced by the people
who are actually into that sort of thing. Looks like you're one of
them. :-)
There's the touchy issue of what minimum compatibility level we're
promising to deliver on all platforms. This is an issue in pugs already,
where Windows GHC isn't compiled with POSIX libraries so we're stumped on
the interface for even relatively basic things, such as how (or whether)
File.open might offer O_EXCL.
Is part of the vision something like the explicit cross-platform nature
of Java? Will I be able to write Perl6 code with a certain flag that
possibly limits my choice of modules/builtins, but which promises me
identical behavior on all supported platforms?
To take a notorious example, you mentioned fork() -- if this event manager
becomes part of Perl6, does that mean we're required to emulate fork()
on win32?
Your point is well taken. Hell, even I was debating generalising even
further from fork to preload. As in, having Perl emit an event which
says Hey everybody, now would be a _really_ good time to load
everything in, because after we $whatever, it's going to be a lot more
expensive to load them in at run-time that to just load them now and
benefit from copy-on-write/threads/whatever.
Sort of a disable run-time loading and load stuff now event.
The reason I wanted a ten lines of code solution is so that the
fork()-on-win32 issue is less of a problem.
If perl itself ONLY does (in p5 term)...
Some::EventManager-fire('prefork') if $INC{Some/EventManager.pm};
..then it would matter less whether or not fork ever happens on Win32.
The preload.pm module would simply register with Some::EventManager for
a different set of events depending on which platform it is on.
prefork.pm as it exists for P5 today doesn't _really_ care about fork().
What it _really_ wants to know is Should I run-time load or not? Tell
me when we need to stop run-time loading.
Some::EventManager might be part of the core, but it certainly wouldn't
be loaded by default. It's just a normal module that gets loaded when
someone needs to use it.
I'm a minimalist. I want something to does the absolute least amount of
work needed to let me know about events I simply can't find out about
any other way, and that perhaps we can add additional events to later.
I certainly DON'T want something big enough and heavy enough to be able
to write Aspect.pm on top of.
Re: Musing on registerable event handlers for some specific events
: If it can be done in less than 10 lines lines of code, to get the most : minimal hooks into the core, I'd like to see it done. 10 lines? I laugh in your general direction. No really. In perl itself, I just to see... throw Event(CORE::prefork) if $Event::Manager::VERSION; ...or something equally simple. Fair enough Event::Manager itself might be a little larger... but even then it shouldn't need to be more than a couple of dozen lines. prefork.pm is currently about 30-40, and you should only need the hashified version of it.
Re: reduce metaoperator on an empty list
On Tuesday 07 June 2005 22:35, Sam Vilain wrote:
Let's look at the type of one of the many `reduce' variants in
Haskell;
foldr1 :: (a - a - a) - [a] - a
This is the Perl6ish;
sub reduce( ::Code{( ::(someType), ::(someType) ) returns
::(someType)} $func, Array of ::(someType) ) returns
::(someType);
ie, the function $func supplied must take and return arguments
of a single type. So you have come to the same conclusion as
the FP folk :-).
I agree with that from the APL, J, Haskell, and FP directions and
several more.
That means that we have to straighten out the functions that can
return either a Boolean or an item of the argument type.
Comparison functions = = = != should return only Booleans,
IMHO, and the same for the string functions lt and gt and the
rest. It also means that we need primitive functions (operators)
like max and min that only return one of the arguments, and that
can also be used with a reduction operator (metaoperator).
--
Edward Cherlin
Generalist activist--Linux, languages, literacy and more
A knot! Oh, do let me help to undo it!
--Alice in Wonderland
http://cherlin.blogspot.com
Re: Empty hash
On Thu, 2 Jun 2005, Stuart Cook wrote:
On 6/1/05, Luke Palmer [EMAIL PROTECTED] wrote:
Should {} be an empty hash rather than an empty code?
Given that an empty hashref is probably much more useful than an empty
block, I propose that {} be an empty hash and {;} be an empty block.
Speaking of which, maybe this may be getting in the too-extreme
territory, but taking into account that a hash _is_ a function, it
wouldn't be that bad to blur the distinction between a hash and code, from
a UI perspective. How should one do it? Oh, but then I don't have the
slightest idea...
Michele
--
DAX ODIA ANCORA
- Scritta su diversi muri milanesi
Re: return() in pointy blocks
Luke Palmer [EMAIL PROTECTED] writes:
On 6/8/05, Piers Cawley [EMAIL PROTECTED] wrote:
In other words, it outputs:
Foo
Foo
# dies
Yep. My mistake.
If that works, then I think it means we can write:
sub call-with-current-continuation(Code $code) {
my $cc = - $retval { return $retval }
$code($cc);
}
Which I personally think is rather cute. Even if I can't quite bring myself
to
believe it's that simple...
Yeah, that's pretty. But that will bite people who don't understand
continuations; it will bite people who don't understand return; it
will even bite people who understand continuations, because they can
be made in such an awkward form so easily.
Having worked through the little and seasoned Schemers, I'm actually at the
point where I can happily think that 'return' is deep scary magic. What I
*want* is a 'proper' continuation, but this would have been close enough for
government work until the real ones came along.
Currently call/cc is done like this:
sub call_with_current_continuation(code) {
code(?CALLER_CONTINUATION);
}
But that might be broken in pugs at the moment.
Doesn't that call code with the continuation of the caller of
call_with_current_continuation, when it *should* call code with the
continuation of call_with_current_continuation?
Re: return() in pointy blocks
Larry Wall [EMAIL PROTECTED] writes: On Wed, Jun 08, 2005 at 10:51:34PM +, Luke Palmer wrote: : Yeah, that's pretty. But that will bite people who don't understand : continuations; it will bite people who don't understand return; it : will even bite people who understand continuations, because they can : be made in such an awkward form so easily. Right--we don't want mere mortals to be able to get at continuations quite that easily, whether they think they want them or not. Shame. If you go monkeying with continuations without knowing what they do, then of course you deserve everything you have coming to you, but is that really any reason for making them hard to get at when you *do* need them? I'm not denying that they should be hard to get accidentally, but it would be good to know how to get them deliberately.
Re: Musing on registerable event handlers for some specific events
On Wed, 8 Jun 2005 18:57:30 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: On Wed, Jun 08, 2005 at 11:04:30PM +0300, Gaal Yahas wrote: : On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote: : To take a notorious example, you mentioned fork() -- if this event manager : becomes part of Perl6, does that mean we're required to emulate fork() : on win32? Perl 5 manages it, and Perl 6 is expected to emulate Perl 5 when fed Perl 5 code. It's one of the reasons Parrot is aiming to support an ithreads model in some fashion or other, I expect. But it's okay if the Pugs interpreter punts on this for now. If the only reason for using the ithreads model is to allow fork() to be emulated using the same mechanism as is used in P5 -- please don't. The reason for supporting fork() is (mostly) to allow unix fork() exec() idioms to operate on Win32, but mostly they don't anyway because Win32 doesn't support the other components required (signals SIG_CHLD etc.; COW) required to allow those idioms run transparently. The p5 fork() emulation is barely usable, and has so many caveats that there will never be the possibility of transparent portability of programs that use fork() to Win32. It will always be necessary to test for platform and make special provisions. And the only instances where the fork emulation does work reasonably well are those that are doing fork() exec(). But thin about that. The emulation, spawns a thread, duplicates all the code and all the data from the main thread and then...Starts a new process. All that copied code and data is never used because all the spawned thread does is sit and wait for the new process to die. Other uses of fork() like alarm(), also don't work in Win32. Cygwin manages to perform a proper fork(). The code isn't even that complicated. Larry
Re: reduce metaoperator on an empty list
Edward Cherlin wrote:
That means that we have to straighten out the functions that can
return either a Boolean or an item of the argument type.
Comparison functions = = = != should return only Booleans,
I'm not sure but Perl6 could do better or at least trickier ;)
Let's assume that = = when chained return an accumulated
boolean and the least or greatest value where the condition was
true. E.g.
0 2 3 returns 0 but true
1 2 1 returns 1 but false
4 5 2 returns 2 but false
Then the reduce versions [] and [=] naturally come out as min
and strict min respectively.
Is it correct that [min] won't parse unless min is declared
as an infix op, which looks a bit strange?
if 3 min 4 { ... }
--
TSa (Thomas Sandla)
Re: Musing on registerable event handlers for some specific events
Nigel Sandever wrote: On Wed, 8 Jun 2005 18:57:30 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: On Wed, Jun 08, 2005 at 11:04:30PM +0300, Gaal Yahas wrote: : On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote: : To take a notorious example, you mentioned fork() -- if this event manager : becomes part of Perl6, does that mean we're required to emulate fork() : on win32? Perl 5 manages it, and Perl 6 is expected to emulate Perl 5 when fed Perl 5 code. It's one of the reasons Parrot is aiming to support an ithreads model in some fashion or other, I expect. But it's okay if the Pugs interpreter punts on this for now. If the only reason for using the ithreads model is to allow fork() to be emulated using the same mechanism as is used in P5 -- please don't. I'll second that. While each version of p5 makes progress towards fork() on Win32 being moderately useful, I still find that only reliable way to do automated multi-processing is to whip out Win32::Process and start a new interpreter with special I'm a child process arguments. -- Rod Adams
Re: reduce metaoperator on an empty list
HaloO Larry, you wrote: : Might I add that it should read : : $var = (op.does(identval) ?? : op.identval($value) :: undef) op $value; : : The rational is, that op is subject to MMD, so the .identval method : should be dispatched as well. Actually op.identity($value) reads : quite natural and self documenting if the parameter is required. I don't think there's a double dispatch there. What do you mean with double dispatch? A single MMD on two arguments or two dispatches after each other? I think op just knows it can default its left argument to an existing attribute value if it (somehow) knows it's part of an assignment op. There's not a lot of payback in getting all abstract here, as far as I can see. Let's assume that op is overloaded for two completely unrelated types A and B, which are both defining their respective identity elements but !(A.identval =:= B.identval). How should the op multi method object pick the correct one *without* looking at $value's type? Or does the indentval role force their takers to provide all infix ops with a test for undef args and a fallback to the respective identity value? If that is the case, the test for the role is superfluous. Or is the intent to enforce a unique identity value for each operator like 0 for + and 1 for *? There's actually a second problem. Will the op.does(identval) condition be true or false if the op multi contains some targets with and some without an identval? Finally I don't understand how the knowledge about a pending assignment eases the choice problem for the multi. Note that the choice of assignment operator depends on the return value of the operator and the type of which the lhs is undef. Regards, -- TSa (Thomas Sandlaß)
Re: using rules
On Sun, Jun 05, 2005 at 05:11:55PM +0200, BÁRTHÁZI András wrote:
Thanks, it helped me!
More questions. ;) It seems to me, that the following constructs not
yet(?) implemented in Pugs. Is it true?
I'll note briefly here that questions regarding implementation (in Perl 6
or Pugs) generally belong on perl6-compiler, not on perl6-language.
Built-in rules:
sp
alpha
etc.
Rule modifiers (:i modifier after the name of the rule):
rule xxx :i {
anything
}
It works well w/o :i.
The rules engine is part of PGE (which Pugs incorporates), and
is not yet complete. We'll be adding more features and built-in
assertions as time progresses. At the moment I'm getting the
grammar class hierarchies ironed out so that I can then properly
add the built-ins.
Pm
Re: reduce metaoperator on an empty list
On Thu, Jun 09, 2005 at 06:41:55PM +0200, TSa (Thomas Sandlaß) wrote:
Edward Cherlin wrote:
That means that we have to straighten out the functions that can
return either a Boolean or an item of the argument type.
Comparison functions = = = != should return only Booleans,
I'm not sure but Perl6 could do better or at least trickier ;)
Let's assume that = = when chained return an accumulated
boolean and the least or greatest value where the condition was
true. E.g.
0 2 3 returns 0 but true
1 2 1 returns 1 but false
4 5 2 returns 2 but false
Then the reduce versions [] and [=] naturally come out as min
and strict min respectively.
Is it correct that [min] won't parse unless min is declared
as an infix op, which looks a bit strange?
if 3 min 4 { ... }
The natural method of implementation would imply that the
final is returned:
0 2 3 returns 3 but true
1 2 1 returns 1 but false
4 5 2 returns 2 but false
The application of each stage of the chain has to remember
the right hand value (for the next stage of the comparison)
as well as the accumulated boolean result. When the boolean
result is true, that has and = returning the max, and and
= returning the min - the opposite of what you asked above.
When the numbers are not in the desired order, it would be
nice to shirtcircuit and not continue on with the meaningless
comparisons as soon as one fails - which means that the max
or min value could not be known.
Whatever is chosen, though, still has to make sense for other
chained comparisons:
$v != $w $x $z == $z
cannot sensibly return either the max or the min (which would
it choose?).
I'd be inclined to have the result be val but true/false
where val is the right hand operand of the final comparison
actually tested. When a consistant set of operators is used
(a mixture of , =, and ==; or a mixture of , =, and ==)
- then a true boolean result also provides the max (or min
respectively) value, while a false boolean result provides
the value of the first element that was out of order.
--
Non-deterministic programming in Perl 6
So, the return in pointy sub thread got me thinking about useful uses of return
in pointy subs that involve being able to return multiple times. And this is
what I came up with, it's an implementation of 'choose':
my give_up = sub { fail Ran out of choices }
sub choose ([EMAIL PROTECTED]) {
my old_give_up = give_up;
my $try = - @choices {
if [EMAIL PROTECTED] { give_up = old_give_up; give_up }
else {
my ($choice, @newchoices) = *choices;
give_up = - { return $try(@newchoices) }
$choice;
}
}
$try(@all_choices);
}
How do you use that I hear you ask:
my $x = choose(1,3,5);
my $y = choose(1,5,9);
# say Trying $x * $y; # Uncomment for an insight into how this works.
give_up unless $x * $y == 15;
say Found $x * $y = 15;
Yes, that is an artificial example.
If you can't use a returning pointy block more than once, then this becomes:
sub callcc (Code block) { block(?CALLER_CONTINUATION) }
my give_up = sub { fail Ran out of choices }
sub choose ([EMAIL PROTECTED]) {
callcc - cnt {
my $try = - @choices {
if [EMAIL PROTECTED] { give_up = old_give_up; give_up }
else {
my ($choice, @newchoices) = *choices;
give_up = sub { cnt($try(@newchoices)) };
$choice;
}
}
$try(@all_choices);
}
}
Tracing the flow of control in both these examples is left as an exercise for
the interested reader.
The only catch is, neither of them works in Pugs. Yet.
Re: reduce metaoperator on an empty list
TSa (Thomas Sandlaß) wrote: Let's assume that op is overloaded for two completely unrelated types A and B, which are both defining their respective identity elements but !(A.identval =:= B.identval). How should the op multi method object pick the correct one *without* looking at $value's type? Your mistake is in thinking that the identity trait is on the operand type. It isn't; it's on the operator itself. Or is the intent to enforce a unique identity value for each operator like 0 for + and 1 for *? Almost. Remember that overloaded operators are also distinguishable by their operand types, so you can specify separate identity values for Cinfix:+(Num, Num) and Cinfix:+(Matrix, Matrix). There's actually a second problem. Will the op.does(identval) condition be true or false if the op multi contains some targets with and some without an identval? The op will have already been selected by the MMD mechanism before that question is asked. Finally I don't understand how the knowledge about a pending assignment eases the choice problem for the multi. Note that the choice of assignment operator depends on the return value of the operator and the type of which the lhs is undef. The MMD mechanism sorts out which op is required, either by looking at the static type of the lhs variable, or by treating the undef as a coercion (Manhattan distance = 1) Damian
Re: reduce metaoperator on an empty list
Edward Cherlin wrote: You haven't convinced me, but rather than flog a dead horse, I'll just suggest that we both reserve the right to say I told you so when there are several years' worth of Perl 6 code out there, and we see how common our respective examples are. No need to wait. There is a ton of APL and J code to inspect. Having predefined identity elements for reductions on empty arrays is widely exploited. I would be more convinced by this body of experience if I felt that the wide exploitation of implicit identity elements actually helped improve the predictability and maintainability of programs written in those languages, neither of which is renowned for its accessibility to ordinary programmers. ;-) Damian
Re: Ordered Hashes -- more thoughts
From: Dan Sugalski [EMAIL PROTECTED] Date: Wed, 8 Jun 2005 16:22:35 -0400 At 4:05 PM -0400 6/8/05, Tolkin, Steve wrote: . . . Dan Sugalski says: I'd just pitch an exception if code deletes an entry ... Perhaps this is OK, because this code is intended for internal use only. But people like to reuse code, and if anyone writes an ordered hash module on top of this code it will have a bug. Which is why it ought not get reused. The whole point of the original ordered hash was to support lexical pads as fast as possible while still allowing by-name lookup for introspective code. Doing anything that compromises fast array-based lookup would be ill-advised for that. If it makes sublclassing tough, well... subclassing continuations is likely going to be problematic too, but that's fine . . . Maybe the problem lies in thinking of this as an ordered hash when it really functions as a keyed array. People expect to be able to delete hash entries, but not always array entries. So a name change might make inability to delete less of an issue. -- Bob Rogers http://rgrjr.dyndns.org/
Re: reduce metaoperator on an empty list
TSa (Thomas Sandla) wrote:
I'm not sure but Perl6 could do better or at least trickier ;)
Let's assume that = = when chained return an accumulated
boolean and the least or greatest value where the condition was
true. E.g.
0 2 3 returns 0 but true
1 2 1 returns 1 but false
4 5 2 returns 2 but false
An interesting idea, but seems a bit heavy..
Is it correct that [min] won't parse unless min is declared
as an infix op, which looks a bit strange?
if 3 min 4 { ... }
Sure. Again there is a Haskell example to heed closely here; for instance, the
function:
divMod :: (Integral a) = a - a - (a, a)
Can be written as either;
divMod 42 9
or:
42 `divMod` 9
The reverse direction is ();
(+) :: (Num a) = a - a - a
(+) 7 5
7 + 5
Sam.
