Re: run / qx/ etc.
On Tue, Apr 20, 2004 at 03:53:31PM -0400, Aaron Sherman wrote:
: In specific, here is a proposal for execution:
:
: multi run(string $command) returns(Process) {...} # Funky shell default
: multi run(Process $process) returns(Process) {...} # Relies on $process.cmdline
Eh? What does it mean to run a process that presumably is already running?
: multi run(Program $program, IO::Mode $mode=undef) returns(Process) {...}
:
: which gives us our process control, all nicely bottled up:
:
: my Process $p = run(find / -name null);
: say Spawned find $($p.getpid);
: $p.kill('TERM');
:
: But if you don't want that, you can always:
:
: run(find / -name null).wait;
:
: which might have an alias called system.
I'm trying to avoid system actually, since it's backwards on its
booleanness in Perl 5, and it would be confusing to just swap it.
: And if you provide mode:
:
: my Process $p = run(program=find / -name null, mode=r);
:
: Then you actually get back a:
:
: class ExecPipe is Process does IO::Handle {...}
:
: which lets you do:
:
: say Found null at: $p.getline;
:
: and which could have a wrapper:
:
: $x = readpipe(pwd);
:
: ahhh... simple.
Er, yeah...
: open2, open3, exec and all manner of other strange things should be
: simple aliases for complex run invocations.
The complicated interface should have a longer name name run. I was
thinking run was the new name of system, and possibly is context sensitive
on its I/O redirection.
: The reason for making Program an object? Why for this:
:
: run(Program(path=find,name=finding null,args=[/ -name
null],exec=true));
:
: which has the alias exec.
I kinda cringe to see exec=true when we just defined :exec to mean that...
: Making this as magical as Perl 5 system would be difficult, though, and
: I'm not sure you need to preserve that particular way of doing things.
Not sure which magic you're referring to. system() is pretty stupid,
other than a little optimization to bypass the shell when it can.
: I leave the definition of Program up to the imagination of the reader.
Oh, oh...
: Incidentally, if Process is a standard class, and happens to do:
:
: class Process {
: ...
: method prefix:~() { return ~($.getpid) }
: method prefix:+() { return $.getpid }
: ...
: }
:
: Then $$ is just a Process object, but behaves exactly as you always
: expected it to.
:
: $$.kill(ABRT)
:
: then does what you might expect, as does:
:
: say $$.cmdline;
Okay, but there is no $$ anymore. It'd be $*PID or $*PROC or some such.
Larry
A12: Conflicting Attributes in Roles
role A {has Cat $.x;}
role B {has Dog $.x;}
class Foo {does Cat; does Dog;}
my Foo $bar;
$bar.x; # Is this a Cat or a Dog?
=
Jonathan Dataweaver Lang
__
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
A12: syntax to call Attributes
How would I call attributes? Specifically, what if I'm calling a list attribute from a scalar object? my Dog $spot; my Dog @pack; $spot-@.legs; # INCORRECT (I hope) [EMAIL PROTECTED]; # INCORRECT? @spot.legs;# What if you also have @spot declared? = Jonathan Dataweaver Lang __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash
RE: run / qx/ etc.
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
On Tue, Apr 20, 2004 at 03:53:31PM -0400, Aaron Sherman wrote:
: In specific, here is a proposal for execution:
:
: multi run(string $command) returns(Process) {...} # Funky shell default
: multi run(Process $process) returns(Process) {...} # Relies on
$process.cmdline
Eh? What does it mean to run a process that presumably is
already running?
use strings :LC_CTYPE('x-en-US-gnu');
my $shell = new Process('/bin/bash');
my $ide = $shell-run('/usr/bin/emacs');
$ide-run('\M-xperl6-interactive\n');
$ide-run(-'END_PERL');
use Hash::halfdan;
%hash`access`tricks++;
END_PERL
$ide-run('\M-xkill-interactive\n');
$ide-run('\C-x\C-z');
$ide-wait(3);
$ide-kill('USR1')
unless $ide-done;
$shell-kill('HUP');
: multi run(Program $program, IO::Mode $mode=undef)
returns(Process) {...}
:
: which gives us our process control, all nicely bottled up:
:
: my Process $p = run(find / -name null);
: say Spawned find $($p.getpid);
: $p.kill('TERM');
:
: But if you don't want that, you can always:
:
: run(find / -name null).wait;
:
: which might have an alias called system.
I'm trying to avoid system actually, since it's backwards on its
booleanness in Perl 5, and it would be confusing to just swap it.
Let's use unary backtick as a cheap qx for atomic commands.
It's twice as ergonomic as the current implementation. :-) :-) :-)
: And if you provide mode:
:
: my Process $p = run(program=find / -name null, mode=r);
:
: Then you actually get back a:
:
: class ExecPipe is Process does IO::Handle {...}
:
: which lets you do:
:
: say Found null at: $p.getline;
:
: and which could have a wrapper:
:
: $x = readpipe(pwd);
:
: ahhh... simple.
Er, yeah...
: open2, open3, exec and all manner of other strange things should be
: simple aliases for complex run invocations.
The complicated interface should have a longer name name run. I was
thinking run was the new name of system, and possibly is
context sensitive on its I/O redirection.
'execute'?
: The reason for making Program an object? Why for this:
:
: run(Program(path=find,name=finding null,args=[/
-name null],exec=true));
:
: which has the alias exec.
I confess I don't understand what value making Program an object has in this
context. If you're going to exec, in the unix sense, then creating a Program
with exec=true cannot do anything except get ready for the run/exec call.
To my feeble mind, there's not much benefit there, unless you figure that
exec+run will catch some class of resource exhaustion error sooner?
I kinda cringe to see exec=true when we just defined :exec to
mean that...
When 'exec' is buried at the end of a hideously complex arglist, as in this
example, I'll take all the verbosity I can get. It helps my parser resync.
run(Program :pathfind :namefinding null :args[/ -name null] :exec)
That does read better with a little sorting, and of course a method:
Program
:namefinding null :exec
:pathfind :args[/ -name null]
== run;
Which brings up pipelining operators:
class Program {...}
multi *infix:(Program $p, String^IO::Handle $input) { $p.input =
$input; };
multi *infix:(Program $p, String^IO::Handle $output) { $p.output =
$output; };
multi *infix:|(Program $p, Program $q) { $p.output = '|$q'; }
multi *postfix:!(Program $p) is tighter(infix:and) { $p.run;}
Program
:namefinding null
:pathfind :args/ -name null -ls
| Program
:namesorting by size
:pathsort :args-k6d
File
:namenulls.txt
:modeoverwrite
!;
Self-documenting shell scripts? The id recoils in disgust.
: Making this as magical as Perl 5 system would be difficult, though, and
: I'm not sure you need to preserve that particular way of doing things.
Not sure which magic you're referring to. system() is pretty stupid,
other than a little optimization to bypass the shell when it can.
We've got operator overloading and macros. We can make C++ look like COBOL
by comparison.
Whether we want to do so is another question.
: I leave the definition of Program up to the imagination of the reader.
Oh, oh...
: Incidentally, if Process is a standard class, and happens to do:
:
: class Process {
: ...
: method prefix:~() { return ~($.getpid) }
: method prefix:+() { return $.getpid }
: ...
: }
:
: Then $$ is just a Process object, but behaves exactly as you always
: expected it to.
Beware of expecting too much *n*x in there. prefix:~() should return the
GUID.
;-)
:
: $$.kill(ABRT)
:
: then does what you might expect, as does:
:
: say $$.cmdline;
Okay, but there is no $$ anymore. It'd be $*PID or $*PROC or some such.
'is' this, 'does' that. What ever happened to line-noise?
=Austin
RE: A12: Conflicting Attributes in Roles
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
role A {has Cat $.x;}
role B {has Dog $.x;}
class Foo {does Cat; does Dog;}
my Foo $bar;
$bar.x; # Is this a Cat or a Dog?
A12
If, however, two roles try to introduce a method of the same name (for some
definition of name), then the composition of the class fails, and the
compilation of the program blows sky high--we sincerely hope. It's much
better to catch this kind of error at compile time if you can. And in this
case, you can.
/A12
Since classes are autogenerating accessors based in data members, it's
doubly reasonable to assume that the same solution will apply: conflict -
death.
=Austin
This fortnight's summary
The Perl 6 Summary for the fortnight ending 2004-04-18 The only problem with summarizing two week's worth of Perl 6 happenings is that there's twice as much stuff to summarize. Still, there's no way I could have made the time to write a summary last week so I'll take my lumps. I am exceedingly grateful that Apocalypse 12 (Objects) wasn't released the Thursday *before* Easter though, as it is I can clear the decks for the expected perl6-language explosion next week. We'll start with perl6-internals as usual. Initializers, finalizers and fallbacks There was some discussion of the various functions that get called by object initialization/destruction etc. Dan wondered what he'd been thinking when he declared that there would be distinct FINALIZE, DELETE and CLEANUP properties (instead of declaring that a function must be called (say) FINALIZE, you can mark any function with a FINALIZE property, and Parrot will recognise that as the function to call at finalization time). Andy Wardley quibbled about American/British spelling, but Tim Bunce pointed out that the 'ize' form is preferred by the Oxford English Dictionary (and your humble summarizer). Leo meanwhile made a (Warnocked) proposal for a new init scheme. http://tinyurl.com/2s2xp http://tinyurl.com/2dfj8 New SDL Parrot bindings Taking advantage of Parrot's new, improved object system, chromatic updated us all on his efforts to provide a shiny OO interface to the SDL library. Jens Rieks wondered about chromatic's implementation choices, and posted a few suggestions and questions. Dan reckoned he'd prefer it if the SDL bindings used Parrots internal events systems. The catch being that Parrot doesn't actually have an internal events system yet... Later in the fortnight, chromatic posted an initial release and promised to post his notes and slides from the Portland Perl Mongers meeting where he was showing it off. There's no sign of 'em yet though. http://tinyurl.com/265sg http://tinyurl.com/2kpax new method Jens Rieks and chromatic were unsure of the best name for a constructor method. They'd like to be able to write a method called new, but IMCC wouldn't allow it. Leo Tötsch pointed out that there's already a default constructor method: __init. However, chromatic wasn't too keen on it because he wanted to be able to pass arguments to the constructor. Leo pointed out that, although it wasn't officially supported, you could pass arguments in the same was as if you were making a normal parrot function call. Dan pointed out that our current initialization system is some way from being the final one (which will use properties to mark constructor methods). What we have now is more like an allocator than a real constructor. http://tinyurl.com/3gv6y Overriding __find_method in PASM? Noting that, according to PDD15, defining a method called __find_method should allow Perl 5 AUTOLOAD-like behaviour, chromatic wondered if it was workable yet and, if it wasn't, how he should go about adding it. Leo confessed that what was in the docs was a cut and paste error and AUTOLOAD behaviour hadn't yet been defined. He suggested a workaround using exceptions (which turned out to be overkill for what chromatic needed, but it looks interesting.) http://tinyurl.com/ypvze Language interoperability Randy W. Sims popped over from the Module-Build mailing list, where they've been discussing plugin architectures to allow for the modification and extension of Module::Build's capabilities. One of the desiderata is that, once the transition to Parrot is underway, it should be possible to write plugins in any language supported by Parrot. (Mmm... a build system written in Befunge, it's what the world's been crying out for I tell you). There are currently two competing schemes, one involving manipulating the class hierarchy at runtime and the other involving plugins held in particular directories and a formal API. Randy wondered if there were any technical reasons to choose one scheme or another. Dan reckoned that there were no particular technical reasons, but the inheritance based scheme rather offended his sensibilities, going so far as to say No way in hell it'll ever make it in as parrot's standard module building system if you do it [the inheritance munging solution]. http://tinyurl.com/33nsw Save the Return Continuation! The ongoing discussion about continuations seems to be fizzling slightly. Piers Cawley had proposed moving the return continuation out of P1 and held 'somewhere else' (possibly the control stack) and then, when a routine needed to do cunning things with the current continuation it could access it with some op (say get_current_cont). Dan reckoned he
Re: A12: Strings
On Tue, Apr 20, 2004 at 10:51:04PM -0700, Larry Wall wrote: Yes, that's in the works. The plan is to have four Unicode support levels. These would be declared by lexically scoped declarations: use bytes 'ISO-8859-1'; use codepoints; use graphemes; use letters 'Turkish'; Note these just warp the defaults. Underneath is still a strongly typed string system. So you can say use bytes and know that the strings that *you* create are byte strings. However, if you get in a string from another module, you can't necessarily process it as bytes. If you haven't specified how such a string is to be processed in your worldview, you're probably going to get an exception. You might anyway, if what you specified is an impossible downconversion. So yes, you can have use bytes, but it puts more responsibility on you rather than less. You might rather just specify the type of your particular string or array, and stay with codepoints or graphemes in the general case. To the extent that we can preserve the abstraction that a string is just a sequence of integers, the values of which have some known relationship to Unicode, it should all just work. : Is that right, or would there be a key_type property on hashes? More to : the point, is it worth it, or will I be further slowing down hash access : because it's special-cased in the default situation? Hashes should handle various types of built-in key strings properly by default. What is properly for string? Is it to hash the sequence of integers as if they're 32 bits wide even if they're less? Is that sufficient? Tim.
Re: A12: Conflicting Attributes in Roles
Originally sent to Austin alone by accident
Austin Hastings wrote:
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
role A {has Cat $.x;}
role B {has Dog $.x;}
class Foo {does Cat; does Dog;}
my Foo $bar;
$bar.x; # Is this a Cat or a Dog?
A12
If, however, two roles try to introduce a method of the same name (for some
definition of name), then the composition of the class fails, and the
compilation of the program blows sky high--we sincerely hope. It's much
better to catch this kind of error at compile time if you can. And in this
case, you can.
/A12
Since classes are autogenerating accessors based in data members, it's
doubly reasonable to assume that the same solution will apply: conflict -
death.
From one C6PAN module:
role Dog {
has $.collar;
...
}
From another C6PAN module:
role LawEnforcementOfficer {
method arrest { ... }
...
}
From a third C6PAN module:
class PoliceDog does Dog does LawEnforcementOfficer { ... }
I use PoliceDog in my production code, without a problem. I don't use
the collar attribute (it's unimportant in my application).
The author of the LawEnforcementOfficer role does an upgrade that fixes
an important bug but also.
role LawEnforcementOfficer {
method arrest { ... }
has $.collar;# for holding most recently arrested
...
}
So when my program fails to compile, who do I blame? How do I fix it
quickly, preferrably without creating local branches of the C6PAN modules?
=Austin
Re: A12: syntax to call Attributes
Jonathan Lang wrote:
How would I call attributes? Specifically, what if I'm calling a list
attribute from a scalar object?
my Dog $spot;
my Dog @pack;
$spot-@.legs; # INCORRECT (I hope)
[EMAIL PROTECTED]; # INCORRECT?
@spot.legs;# What if you also have @spot declared?
This question is a little bit like asking how you can detect a hard link...
Attributes themselves are inaccessible from outside the class. All you
can get at is their accessor (if they have one), which is a normal
method called the normal way:
$spot.legs;# Could be for $.legs, @.legs, or %.legs
Which actually brings up an interesting question:
class Silly {
has $.thing=1;
has @.thing=(2, 3);
has %.thing=(4 = 5, 6 = 7);
}
my $silly=new Silly();
say $silly.thing.class;#Int, Array, or Hash?
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: A12: Conflicting Attributes in Roles
On Wed, 2004-04-21 at 04:19, Buddha Buck wrote:
From one C6PAN module:
role Dog {
has $.collar;
...
}
From a third C6PAN module:
class PoliceDog does Dog does LawEnforcementOfficer { ... }
role LawEnforcementOfficer {
method arrest { ... }
has $.collar;# for holding most recently arrested
...
}
So when my program fails to compile, who do I blame?
Whoever didn't read the documentation for the appropriate roles. :)
How do I fix it
quickly, preferrably without creating local branches of the C6PAN modules?
* Add a disambiguatey method to PoliceDog that dispatches
appropriately. (Insert handwavey well you *could* do it this way or
you *might* do it that way.)
* Force the loading of a specific version of LawEnforcementOfficer.
-- c
Re: A12: syntax to call Attributes
On Wed, 21 Apr 2004, Brent 'Dax' Royal-Gordon wrote:
Which actually brings up an interesting question:
class Silly {
has $.thing=1;
has @.thing=(2, 3);
has %.thing=(4 = 5, 6 = 7);
}
I had assumed that'd be illegal: each of $.thing, @.thing and %.thing
autogenerates a method named thing. I would hope that is illegal, for my
head would hurt otherwise keeping track of what a particular thing
means.
We surely don't allow the following in the same class:
has @.thing is Array of Cat;
has @.thing is Array of Dog;
It seems to me that the $.thing/@.thing issue is similar (though the
sigil makes this easier for the compiler):
has $.thing is Scalar;
has @.thing is Array;
--Abhijit
Re: A12: Strings
On Wed, Apr 21, 2004 at 11:04:02AM +0100, Tim Bunce wrote: : Hashes should handle various types of built-in key strings properly : by default. : : What is properly for string? The way it oughta, whatever that is... I was aiming to set policy rather than implementation there. :-) : Is it to hash the sequence of integers : as if they're 32 bits wide even if they're less? Is that sufficient? That would be one way. The point being that the hash mustn't tell you that two strings are different when they would compare the same, even if they are in different internal representations to begin with. It's okay if the hash occassionally says two strings are the same when in fact they'd compare differently. The actual weakness is likely to be in the definition of comparison rather than the definition of the hash function, especially if we let people specify the standards of comparison for the hash keys. That says that the hash function has to either be weaker than the weakest specifiable comparison, or we have to be able to weaken the hash such that it doesn't lie about what might match. That sounds like research... Well, it's probably not that bad. Much like with other sorting problems, all you have to do is keep track of a canonicalized key in addition to the real key. The hash is always calculated off of the canonicalized key rather than the actual key. (Whether you choose to store or recreate the canonical key is one of those space/time tradeoffs that use less was originally intended to solve...) If Unicode makes your brain hurt, just think of it in terms of case sensitivity. We could have a hash that was case insensitive by always calculating the hash on a lower-cased key, and by doing comparisons between lower-cased keys (notionally, at least). So in Unicode terms, there are probably some speed benefits if you know your keys are already canonicalized to the form required by the comparison and hash functions. That implies that the state of canonicalization must be strongly typed (presumably dynamically in Perl). Canonicalization is one of those things you really don't want to do redundantly. Larry
Adding deref op [Was: backticks]
On Tue, Apr 20, 2004 at 10:55:51AM -0700, Larry Wall wrote: The flip side is that, since we won't use C` as an operator in Perl 6, you're free to use it to introduce any user-defined operators you like, including a bare C`. All is fair if you predeclare. Most languages won't even give you that... I just realized there's another operator that has no infix meaning yet, and so is free to use (and perhaps more visually pleasing): %hash\key (or $foo\bar\baz\42 ) vaguely reminiscent of DOS/Win32 paths :-D Just curious, when adding such an operator myself, would it be possible to make it work on both hashes and arrays, without making the op very slow? -- Matthijs van Duin -- May the Forth be with you!
Re: Adding deref op [Was: backticks]
On Wed, Apr 21, 2004 at 01:02:15PM -0600, Luke Palmer wrote:
macro infix:\ ($cont, $key)
is parsed(/$?key := (-?letter\w* | \d+)/)
{
if $key ~~ /^\d+$/ {
($cont).[$key];
}
else {
($cont).«$key»;
}
}
That does all the magic at compile time.
True, but what about $x\$y ? :-)
(which I'd want to work for consistency reasons.. so you can write
$foo\bar\$baz\42 instead of ugly mixing like $foo\foo{baz}\42 )
--
Matthijs van Duin -- May the Forth be with you!
Re: Adding deref op [Was: backticks]
On Wed, Apr 21, 2004 at 09:19:12PM +0200, Matthijs van Duin wrote:
On Wed, Apr 21, 2004 at 01:02:15PM -0600, Luke Palmer wrote:
macro infix:\ ($cont, $key)
is parsed(/$?key := (-?letter\w* | \d+)/)
{
if $key ~~ /^\d+$/ {
($cont).[$key];
}
else {
($cont).«$key»;
}
}
That does all the magic at compile time.
True, but what about $x\$y ? :-)
What about $x\n? The backslash already has
meaning in strings, yet interpolating hashed
values is a common need. There's a similar
problem inside a regex, where backslash would
be ambiguous. The ambiguity can be resolved,
perhaps, but the confusion would make \ a poor
choice.
--
Re: Adding deref op [Was: backticks]
On Wed, Apr 21, 2004 at 03:37:23PM -0400, John Macdonald wrote: What about $x\n? The backslash already has meaning in strings I use hash elements far more often outside than inside strings, so I could live with having to write $x«foo» for interpolated hash elements. Anyway, you're missing the point of my question. Since shorthand for hash elements has already been banned from the core by Larry, I'm now just exploring what is involved with adding it later on, independent of what actual syntax I'd use (a bashtick, backslash, or something else). -- Matthijs van Duin -- May the Forth be with you!
