Front page | perl.perl6.language |
Postings from November 2004
James Mastros wrote:
> Larry Wall wrote:
>
>> On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
>> : ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
>> : qx:noparse 'echo $VAR' ?
>>
>> I think we need two more adverbs that add the special features of qx
>> and qw,
>> so that you could write that:
>>
>> q:x/echo $VAR/
>>
>> where ordinary qx/$cmd/ is short for
>>
>> qq:x/$cmd/
>
>
> I think I'd like that much better if we consider execution and
> word-splitting to be the primary operations, and interpolation and
> noninterpolation the adverbial modifiers then the other way around,
> making that qx:q/echo $VAR/ or qx:qq/$cmd/. OTOH, I expect backticks to
> be rare enough that I wouldn't mind writing
>
> use Spawn 'spawn';
> spawn :capture :wait ($cmd);
> spawn :capture :wait ('echo $VAR');
>
> Much more clear, saves ` for other things, and allows for easy
> specification of the many adverbs of spawn (weather it returns the
> return status, the PID/FH set object, or output, if it waits right
> there, or runs in the background (and makes the return value lazy), if
> it replaces the current process (exec)...
I'd quite like that. Although I think spawn should be a builtin rather
than in a module, if it was in the core, and we were getting rid of
backticks.
Although I'm masochistic enough that I don't mind the idea of always
having to do execution with qx//, qx:q// or qx:qq// (running with other
suggestions, I'd guess that would be non-interpolating execution, then
the same again more explicitly, then interpolating execution) but I do
like the idea of spawn.
Kind of removes the idea of pulling in the output of other programs as a
fundamental part of the language though, for that it's nice to have an
executing, capturing quote. Perhaps an adverb to qx that makes it behave
like system() - I don't think it'd be a good idea to provide one that
makes it behave like exec(), although perhaps other people do.
qx:r/$cmd/
qx:s/$cmd/ # both of these give back return codes? Which one!
But then
qx:r:qq// might be messy.
Or even
qx:exitcode:interpolate//
Ouch.
This isn't very coherent, I'm just thinking out loud based on what other
people have said that I like.
>> But there are some things that would be completely ambiguous:
>>
>> %hash<foo><bar>
>
> Bracketing operator.
>
>> %hash<foo><baz()
>
> Very long bracket operator, which quite likely has a syntax error
> directly after it.
But might not have... there's a chance that could slip through, and I
don't like that for some reason.
>> : or maybe even we could see consistant to go after +<< +>> and alike,
>> and : make old < and > written as +< and +> (and then lt and gt
>> suddenly could : become ~< and ~> :)
>>
>> I think people would rise up and slay us if we did that. We're already
>> getting sufficiently risen up and slain over Perl 6.
>
> Could be worse. They could rise from the grave and eat us!
Who says they won't?
>> Well, yes, but sometimes the weights change over time, so it doesn't
>> hurt (much) to reevaluate occasionally. But in this case, I think I
>> still prefer to attach the "exotic" characters to the exotic behaviors,
>> and leave the angles with their customary uses.
>
> ...of which they have plenty already. Backtick has exactly one, and not
> an often-used one at that... I'm fine with axing it. Of course, there
> are a lot more people in the world then just me.
I'm fine with it too. I use it a fair bit but I think it's important to
have a very clear mark where you're going to an external program
Thread Previous
|
Thread Next