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
[PATCH] Fix 3 of the spawnw.t failures.
Further thoughts on the questions in comments invited. njs win32-exec.c.patch Description: Binary data
Re: [PATCH] Fix 3 of the spawnw.t failures.
Apologies for the wrong list. Should I resend to the correct one? njs
Re: Thunking semantics of :=
On Sat, 23 Apr 2005 21:00:11 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: On Sun, Apr 24, 2005 at 03:37:23AM +, Nigel Sandever wrote: : On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: : : Oh well. At least the same code can be salvaged to make iThreads : : Please. No iThreads behaviour in Perl 6. : : Nobody uses them and whilst stable, the implementation is broken in so many way. : : But worse, the underlying semantics are completely and utterly wrong. Are you confusing iThreads with pThreads? Or are you recommending we go back to the pThreads fiasco? I certainly am not advocating a shared-by-default, or everything-shared model. From what I've read, the trend in most modern implementations of concurrency is away from shared state by default, essentially because shared memory simply doesn't scale up well enough in hardware, and coordinating shared state is not terribly efficient without shared memory. If you are claiming that modern computer scientists are completely and utterly wrong in moving that direction, well, that's your privilege. But you should be prepared for a little pushback on that subject, especially as you are merely badmouthing something without goodmouthing something else in it's place. When I said iThreads, I was referring to the only defenition I can find for iThreads, the Perl 5.8.x implementation. The broken underlying semantics are 1) The fork-like, duplicate-everything-in-the-process-at-the-point-of-spawn. This makes spawning a thread heavier than starting a process in many cases. It makes using (the p5 implementation of) iThreads an exercise in frustration trying to avoid the semantics it imposes. 2) The shared-memory is really multiple-copies-with-ties. This removes 90% of the benefits of shared-memory, whilst doing nothing to make it easier to use. The user is still responsible for locking and synchronisation, but looses the ability to use either ties or object-semantics to encapsulate it. That forces every programmer to re-invent the techniques in every program as it is nearly impossible to write clean, effcient apis and put them into modules. The duplication and tied-updates makes using shared memory so slow and clumsy, that it can be quicker to freeze/transmit-via-socket/thaw shared data between processes, than to share a piece of memory within a process. 3) Using the low-level pthreads api as the basis for the user view of threading. This precludes the use of native thread features on any platform that has extended or better api, and forces the programmer to deal with the ultra-low- level at which that API is defined without any of the control that he would have if using it directly. Larry njs.
Re: Thunking semantics of :=
On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: Oh well. At least the same code can be salvaged to make iThreads Please. No iThreads behaviour in Perl 6. Nobody uses them and whilst stable, the implementation is broken in so many way. But worse, the underlying semantics are completely and utterly wrong.
Re: Blocks, continuations and eval()
On Thu, 21 Apr 2005 08:36:28 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: Hmm, maybe that's not such a bad policy. I wonder what other dangerous modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance. How about use RE_EVAL; # or should that be REALLY_EVIL? Larry
Re: Valid hash keys?
On Sun, 27 Feb 2005 02:20:59 -0700, [EMAIL PROTECTED] (Luke Palmer) wrote:
Luke Palmer writes:
Autrijus Tang writes:
Just a quick question: Is Hash keys still Strings, or can they be
arbitary values?
They can be declared to be arbitrary:
my %hash is shape(Any);
If the latter, can Int 2, Num 2.0 and Str 2 point to different
values?
That's an interesting question. Some people would want them to, and
some people would definitely not want them to. I think the general
consensus is that people would not want them to be different, since in
the rest of perl, 2 and 2 are the same.
I forgot an important concretity. Hashes should compare based on the
generic equal operator, which knows how to compare apples and apples,
and oranges and oranges, and occasionally a red orange to an apple.
That is:
3 equal 3 == true
3 equal { codeblock } == false
3 equal 3== true
I would have assumed a hash who shape was defined as CInt to perform the
hashing function directly on the (nominally 32-bit) binary representation Int
2.
Likewise, cmy % hash is shape(Double), would perform the hashing on the
binary
rep of the (nom.64-bit) Double value.
And Cmy %hash is shape(Ref), on the address of the key passed?
By extension, a C%hash is shape( Any ) would hash the binary representation
of
whatever (type of) key it was given, which would make keys of 2, 2.0, '2',
'2.0', (Int2)2 etc. all map to different keys.
If C%hash is shape(Any) maps all the above representation of 2 to the same
value, then Cmy %hash is shape(Any) becomes a synonym for
C%hash is shape(Scalar).
(is that the same as Cmy %hash of Scalar?).
If my auumption is correct, then that would imply that each type hash or
inherits a .binary or .raw method to allow access to the internal
representation?
Luke
Re: Junction Values
On Sat, 19 Feb 2005 18:42:36 +1100, [EMAIL PROTECTED] (Damian Conway) wrote: the Awesome Power of Junctions: As I tried to express elsehwere, this what I'm looking for. Instinctively, and for a long time since I first came across Q::S, I thought that the killer app of Junctions is there somewhere, I'm just not seeing it yet. I'd really like to see some practical demonstrations of the Awesome Power. Something that goes beyond producing a boolean result from a set of values that could equally be done using hyperoperators? Njs.
Re: Junction Values
On Sun, 20 Feb 2005 03:17:19 -0600, [EMAIL PROTECTED] (Rod Adams) wrote:
--020209010404060902000407
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Nigel Sandever wrote:
On Sat, 19 Feb 2005 18:42:36 +1100, [EMAIL PROTECTED] (Damian Conway) wrote:
The Awesome Power of Junctions:
Well, that was one of my stumbling blocks early on. They don't really
give you the power to do anything you couldn't previously do. They just
make certain things a lot easier to do.
But I'll take a whack at giving you something non-trivial to do without
junctions:
$re1 = /^ -[x]* x -[x]* $/; # match a string with exactly one
[SNIP]
And all seven of these can be used as any stored RE can:
if $x ~~ $re6 {...};
given $x {
when $re5 {...}
when 'santa' {...}
when ($re1 | $re3) $re3 {...}
}
SNIP]
So what have we gained here? The ability to join several RE's together,
into something that still acts like a single RE. Show me the equivalent
code without junctions, and then we'll compare the power of junctions.
By the power of a single good example, you can now count me amongst the
convinced.
btw, the examples above assume the ability to store a junction. So you
either have to 'use junctions;', or convince Larry to rescind that
restriction.
Patricks's arguement that there is no real difference between a scalar that
contains a Junction and a scalar that contains a coderef or any type of ref
when
it comes to requiring the programmer to know (or test for) what the scalar
holds, was enough to convince me that no additional pragmas are required for
junctions. Though I wouldn't object to Damian's cno autothreading.
My only problem was that I couldn't see the larger benefit of them. Your
example
above is sufficient to convince that being able to encapsulate not just a set
of
data, but /required result/ of *any* operations performed using that set data
did the trick for me.
I now view the junction
my $x = any( @values );
as roughly equal to:
my $junction = bless [ @values ], 'any';
and similarly for the other three. Simplistic, but enough for my mind to make
the transition.
Using the hyper operators, you would have to re-state the desired result for
each operation, but with a junction you've encapsulated it in.
HTH.
-- Rod Adams
Thanks for taking the time to produce your good example and so carrying me
along.
njs.
--020209010404060902000407--
Examine what is said, not who speaks.
Re: Junction Values
On Wed, 16 Feb 2005 12:17:35 +1100, [EMAIL PROTECTED] (Damian Conway) wrote: ..values tells you what raw values are inside the junction. The other kind of introspection that's desirable is: what raw values can *match* this junction. There would probably be a .states method for that. To see the difference between the two, consider: my $ideal_partner = all( any(tall dark rich), any(rich old frail), any(Australian rich), ); $ideal_partner.values would return the three distinct values in the junction: ( any(tall dark rich), any(rich old frail), any(Australian rich), ); But $ideal_partner.states would return only those non-junctive values that (smart-)match the junction. Namely, rich. I, and I think many others, have been trying to follow along on the discussions regarding junctions, and I have to say that for the most part, much of it goes insert graphic of open hand, palm down, waving to and fro above head. Any chance that you could provide one or two simple but realistic examples of using Junctions and their operators? I see individual snippets of use and they appear to make sense, but when I try envisage using them in code I have recently written, I find nothing leaping off the page at me as an obvious candidate. Thanks.
Re: Junction Values
On Wed, 16 Feb 2005 09:18:42 -0600, [EMAIL PROTECTED] (Patrick R. Michaud)
wrote:
On Wed, Feb 16, 2005 at 01:06:22PM +, Nigel Sandever wrote:
Any chance that you could provide one or two simple but realistic examples
of
using Junctions and their operators?
I'll give it a shot, but keep in mind that I'm somewhat new to this
also. :-)
First, junctions are an easy way to represent the relationships
any, all, one, or none. So, where we once had to say:
if ($x==$a or $x==$b or $x==$c or $x==$d) { ... }
we can now say
if $x == any($a, $b, $c, $d) { ... }
Similarly, where we once had to say
if (grep { $x == $^z } @list) { ... }
if (grep { $x == $^z } @list) == 0 { ... }
we can now say
if $x == any(@list) { ... }
if $x == none(@list) { ... }
I'd write the P5 none() case as
if ( grep { $x != $_ } @list ) { ... }
or
unless( grep{ $x == $_ } @list ) { ... }
which tends to reduce the sugaryness of the new syntax slightly.
And for fun, try writing the equivalent of
if $x == one($a, $b, $c, $d) { ... }
I'm also not entirely sure at this point whether that means
if( grep( { $x == $_ } $a, $b, $c, $d ) == 1 ) { ... }
or something different?
without a junction. (Okay, one can cheat with Cgrep.)
But most of those examples pretty clear and understandable. I'm not sure that I
see their convenience alone as a convincing arguement for the existance of
Junctions. I keep thinking that there is something altogether more
fundementally
useful and ...well... cleverer underlying their inclusion, but at this stage I
am not seeing it.
In this usage, they appear to be replicating functionality that is already
being
provided via the inclusion of the hyper-operators.
('scuse me if I skip the unicode and/or get the syntax wrong!)
if( $x == @list ){ ... } ## any?
if( $x != @list ){ ... } ## none?
if( ( $x == @list ) == 1 ) { ... } ## one?
if( ( $x == @list ) == @list ) { ... } ## all?
It would very much depend upon what a hyper operator returns in a boolean
context, but they /could/ be made to work as I've indicated I think.
If the hyper operator returned one boolean result for each comparison it made,
and if a list of boolean values in a boolean context collapsed to a count of
the
trues/1s it contained, I think those would work. You would also get the bonus of
if( ( $x == @list ) == 2 ) { ... } ## two() ( three(), ten() etc. )
if( ( $x = @list ) == @list/2 ) { ... } ## fify percent below...
But I think the promise of Junctions appears to come from using them in
conjunction with each other.
$x = any( @list1 );
$y = all( @list2 );
$z = none( @list3 );
if( $x = $y ) { ... }
if( any( $x != $y ) or all( $y == $z ) ) { ... }
except that I haven't got a clue what those mean?
I've sat and starred at the worked examples given elsewhere in this and the
other thread, and whilst I can follow how the results are derived when someone
lays them out for me--though I fell into the trap of accepting the one where
Damian made a mistake, which probably means I wasn't paying close enough
attention--when I get to the the last line and see that the answer it true (or
false), I look back at the original unexpanded statement and think:
Yes! But what does it mean? When and where is that going to be useful?
A programmer can easily use these without having to worry about the
notions of autothreading or superpositions or the like, and
their translations to English are fairly obvious. I suspect that
constructs like the above will be the majority of use for junctions.
Things start to get weirder when we start storing junctions into
variables, and/or passing those variables/junctions into subroutines.
But I think this is not *too* far removed from the idea of placing a
subroutine or a rule into a scalar -- i.e., using a scalar to represent
something more than a single-valued primitive type. Thus, just as one
can write
$x = new CGI;
$y = rule { \d+ };
$z = sub { ... };
and then use $x, $y, and $z later on for an object, rule, and sub
(which may have a variety of side-effects associated with them), it makes
sense that one can write
$w = any(@list);
and then use $w to refer to the junction later. And a programmer who
does this is taking on some responsibility for understanding that $w
isn't one of the trivial scalars anymore (same as for $x, $y, and $z).
However, one difference is that when one typically uses an object, rule,
or subroutine in a scalar there is some syntax that makes their nature
apparent. Some feel that Junctions might be just a bit too magical
in this respect (e.g., Luke has made some syntactic suggestions to try
make the existence/threading of a junction more apparent).
I see the dangers of scalars that aren't
Re: specifying the key Type for a Hash
On Sat, 04 Dec 2004 08:01:46 -0700, [EMAIL PROTECTED] (David Green) wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Larry Wall) wrote: S9 talk about it. We current have things like: my Cat %pet is shape(Str); and parameters to types are in square brackets, so it's more like: my %pet is Hash[:shape(Str) :returns(Cat)]; I still prefer shaped, for pronounceability. Although shape is a bit of a stretch for something that's really more like size, and even stretchier for describing hash keys. I'm not sure what better word we could use, though. is built # a constructive choice is determined # good for typing practice =P is bound # what if you're bound AND determined? is disposed# sounds like a destructor is composed# I kinda like this one is arrayed # oh, array in that other sense is reckoned# bet no other language has that as a keyword is cinched # it sounds so easy is confined# to quarters is walled # now we're just being silly (no offense to Larry) is earmarked # some people wouldn't hear of it is indexed # a bit better than is keyed (especially if it's your car) is sized # I think this was already rejected is like# works really well if your type happens to be 'Totally' is thus# very vague, but short Hm. On the other hand, imagining Type-shaped holes into which your hash keys fit *does* have a rather picturesque appeal... -David the thesaurus is your friend (sometimes) Green I probably missed teh comprehensive dismissal thread, but why not 'type'? my %pet is Hash[:type(Str) :returns(Cat)]; njs
Re: Synopsis 9 draft 1
On Fri, 3 Sep 2004 17:08:00 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: On Fri, Sep 03, 2004 at 05:45:12PM -0600, John Williams wrote: : On Thu, 2 Sep 2004, Larry Wall wrote: : : The argument to a shape specification is a semicolon list, just like : the inside of a multidimensional subscript. Ranges are also allowed, : so you can pretend you're programming in Fortran, or awk: : : my int @ints is shape(1..4;1..2); # two dimensions, @ints[1..4; 1..2] : : What happens when the Pascal programmer declares : : my int @ints is shape(-10..10); : : Does it blow up? No. : If not, does @ints[-1] mean the element with index -1 or the last element? The element with index -1. Arrays with explicit ranges don't use the minus notation to count from the end. We probably need to come up with some other notation for the beginning and end indexes. But it'd be nice if that were a little shorter than: @ints.shape[0].beg @ints.shape[0].end Suggestions? Maybe we just need integers with whence properties... :-) How about keywords clo and chi? Larry
