Re: embedding languages in Perl 6
On Wed, 20 Apr 2005, [ISO-8859-2] BÁRTHÁZI András wrote: I'm just wondering, if the following would be possible with Perl 6 or not? XML $a=elemselemContent #1/elemelemContent #2/elem/elems; [snip] The ideas coming from Comega, the next version of CSharp(?). Here's an intro about it: Some time ago I asked a somewhat related question that you can find under the subject Markup language-like features in Perl6?. It didn't raise much feedback, though. And I should have expanded on the subject, but never found the time to do so. Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, Re: Perl neq Python
-X's auto-(un)quoting?
Are the -X functions still going to be there? I definitely hope so! However, to come to the actual question, it has happened to me to have to do, in perl5 that is: perl -lne 's/^//;s/$//;print if -e' or (less often) perl -lne '$o=$_;s/^//;s/$//;print $o if -e' Ok: no much harm done (to my fingertips). But then, talking about huffmanization, could a standard adverb be provided for -X's to the effect of specifying that the passed filename is quoted, say in double (or if sensible in single) quotes: for I find that to be a common filelist format. Ideally, what I'd like to do is perl -lne 'print if -e :q' Michele -- Mary had a little lamb;/Its fleece was green as limes. And every even number greater than two/Is the sum of two primes. - Robert Israel in sci.math, Re: all math problems reduce to linguistics
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
Chip Salzenberg [EMAIL PROTECTED] writes: According to Michael G Schwern: In the same way that we have open() not fopen, fdopen, freopen... we can choose the safest and most sensible technique for determining the cwd and use that. And there is more than one open. Perl does have fopen/fdopen/freopen, but they're accessed through other techniques besides the name of the operator. For example, Perl spells Cfh = fdopen(5, r) as Copen $fh, =5). The unique technique is there, just pushed out of the operator name and into its parameters. And then there's sysopen(). This is exactly the point (I think) Schwern is trying to make. There is 'open', that will do most of the time. If a novice user asks how to open a file, you can say Well, just 'open $fh, $file'. If you want more than vanilla file access, there are all the other forms of open and open parameters. From the perspective of 'current directory' there should also be a simple and elegant way that will do in most cases. Advanced tricks can be made possible using separate modules and such. Maybe the basic problem is that 'current directory' is a system dependent file system location that is not a fixed string, although it usually can be represented as a string. Similar to a simple 'open', I think the most common use of 'cwd' (or whatever) is to return a file system location that can be returned to later, much in the sense of 'tell' and 'seek'. I think this can be implemented in a quite fail safe way on most platforms. -- Johan
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 04:32:41PM +0800, fayland wrote: It has been published at perl6.language, but have no reply. In perl v5.8.6 built for MSWin32-x86-multi-thread: my $i = 1; print $i++, ++$i; # 1 3 my $i = 1; print ++$i, $i++; # 3 2 in pugs: my $i = 1; say $i++, ++$i; # 1 3 my $i = 1; say ++$i, $i++; # 2 2 which is right?(I think perl5 is) or it's different between Perl5 and Perl6? I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. When I see code such as this, I usually encourage people to program Perl as if it had sequence points and undefined behaviour. This often results in explaining what they are, but maybe that's not such a great problem. See http://www.eskimo.com/~scs/C-faq/faq.html, especially sections 3.8 and 11.33 for details. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
default values for attributive parameters
Are default values supported for attributive parameters in an argument list?
I wish to convert these 2 subroutines to perl6:
sub foo {
my $self = shift;
$self-{foo} = defined $_[0] ? shift : undef;
}
sub bar {
my $self = shift;
$self-{bar} = defined $_[0] ? shift : $DEFAULT;
}
Is this correct?
method foo (?$.foo = undef) {};
method bar (?$.bar = $DEFAULT) {};
Thanks,
Carl
Re: default values for attributive parameters
Carl Franks skribis 2005-04-21 11:29 (+0100):
I wish to convert these 2 subroutines to perl6:
sub foo {
my $self = shift;
$self-{foo} = defined $_[0] ? shift : undef;
}
sub bar {
my $self = shift;
$self-{bar} = defined $_[0] ? shift : $DEFAULT;
}
Is this correct?
Those are weird methods. They're essentially write-only accessor methods
for their respective internal attributes (in perl 5 called properties).
method foo (?$.foo = undef) {};
method bar (?$.bar = $DEFAULT) {};
The fun thing is that
has $.foo;
has $.bar;
already gives you, for free and imlicitly, two lvalue accessor methods
that can be used for both reading and writing the value. You appear to
want a default that is used at set-time, which I find weird. More common
I think would be to provide a default that is used at the time of object
construction.
has $.foo;
has $.bar = $DEFAULT;
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
Johan Vromans skribis 2005-04-21 8:22 (+0200): This is exactly the point (I think) Schwern is trying to make. There is 'open', that will do most of the time. If a novice user asks how to open a file, you can say Well, just 'open $fh, $file'. If you want more than vanilla file access, there are all the other forms of open and open parameters. Just for the record, that's spelled $fh = open $file in Perl 6. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [pugs]weird thing with say ++$
Paul Johnson [EMAIL PROTECTED] writes: I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. Isn't this the old prefix-++ problem: @a = (++$i,++$i,++$i); print @a;# prints 3 3 3 -- Johan
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote: On Thu, Apr 21, 2005 at 04:32:41PM +0800, fayland wrote: It has been published at perl6.language, but have no reply. In perl v5.8.6 built for MSWin32-x86-multi-thread: my $i = 1; print $i++, ++$i; # 1 3 my $i = 1; print ++$i, $i++; # 3 2 in pugs: my $i = 1; say $i++, ++$i; # 1 3 my $i = 1; say ++$i, $i++; # 2 2 which is right?(I think perl5 is) or it's different between Perl5 and Perl6? I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. It certainly makes more sense to me that the answer would be 2 2. But however it ends up, so long as we know what the answer will be, we can utilize it effectively in our programs. -kolibrie
Re: [pugs]weird thing with say ++$
On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote: It certainly makes more sense to me that the answer would be 2 2. But however it ends up, so long as we know what the answer will be, we can utilize it effectively in our programs. The trick with this construct usually in C is that the C standard doesn't specify the order of evaluation of function arguments, so you can never be sure if you'll get the same result if you compile it other than on your development system (different compilers may evaluate them in a different order). The Pugs example given in the original post seems to me to be fairly sane, as it shows left-to-right evaluation. The Perl 5 example, as far as I can tell, shows left-to-right for the first case and right-to-left for the second case, which is just odd... please correct me if I'm wrong, but that seems the only way those answers could have been arrived at. So really, what needs to be said is how Perl 6 is supposed to evaluate the arguments to function calls, then we can know if the current behaviour in Pugs is correct.
Re: Blocks, continuations and eval()
On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote: We'll make continuations available in Perl for people who ask for them specially, but we're not going to leave them sitting out in the open where some poor benighted pilgrim might trip over them unawares. Sorry for replying so late, but I missed your reply somehow. I just want to ask a little clarification on this; exactly what kind of hiding are you considering for continuations? That is, do you just mean that there will not be a 'call/cc' primitive by default in the global namespace? I'm fine with that, as that's just one method of capturing the calling continuation. Larry -- wolverian signature.asc Description: Digital signature
Re: Blocks, continuations and eval()
On Thu, Apr 21, 2005 at 04:30:07PM +0300, wolverian wrote: : On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote: : We'll make continuations available in Perl for people who ask for : them specially, but we're not going to leave them sitting out in the : open where some poor benighted pilgrim might trip over them unawares. : : Sorry for replying so late, but I missed your reply somehow. I just want : to ask a little clarification on this; exactly what kind of hiding are : you considering for continuations? That is, do you just mean that there : will not be a 'call/cc' primitive by default in the global namespace? : I'm fine with that, as that's just one method of capturing the calling : continuation. I suspect it's just something like use Continuations; at the top to enable the low-level interface. There would be no restriction on using continuation semantics provided by other modules, because then the use of that other module implies whatever form of continuation it provides. My concern is primarily the reader of the code, who needs some kind of warning that one can get sliced while juggling sharp knives. If we were willing to be a little more Ada-like, we'd make it a shouted warning: use CONTINUATIONS; 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. Larry
Re: -X's auto-(un)quoting?
On Thu, Apr 21, 2005 at 10:18:17AM +0200, Michele Dondi wrote:
: Are the -X functions still going to be there? I definitely hope so!
Certainly. They're useful, and one of the things people love about Perl.
In fact, we're enhancing them to be stackable, so you can say
if -r -w -x $filename {...}
to and the conditions. Or maybe there's a better solution to that
now that we have junctions, on the order of
if $filename ~~ -r -w -x {...}
Then we also get our or for free. We'd just say that ~~ binds
the default of -X just as it does m// or s///.
The only fly in the ointment is that this is awfully ambiguous because
-X is a unary operator looking for an argument, and you're not giving
it one. But it might think the next thing is a sub ref starting with ''.
Ouch. Not sure where to go with that, other than require space or parens
when ambiguous.
: However, to come to the actual question, it has happened to me to have to
: do, in perl5 that is:
:
: perl -lne 's/^//;s/$//;print if -e'
:
: or (less often)
:
: perl -lne '$o=$_;s/^//;s/$//;print $o if -e'
:
:
: Ok: no much harm done (to my fingertips). But then, talking about
: huffmanization, could a standard adverb be provided for -X's to the effect
: of specifying that the passed filename is quoted, say in double (or if
: sensible in single) quotes: for I find that to be a common filelist
: format. Ideally, what I'd like to do is
:
: perl -lne 'print if -e :q'
It seems to me that -e «$_» would handle most of these cases, as long as
whitespace always comes in quoted so that you always end up with one word.
That seems more general than a special option to -X ops.
Larry
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: alarm() and later()
Larry Wall [EMAIL PROTECTED] wrote:
Assuming we
rehuffmanize kill to sendsignal or some such, we have:
signal is a verb as well as a noun.
sub alarm ($secs) {
{ signal $*PID, Signal::ALARM }.cue(:delay($secs));
}
It even reads pretty nicely: signal 4242.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: alarm() and later()
On Thu, Apr 21, 2005 at 01:51:36PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall [EMAIL PROTECTED] wrote:
: Assuming we
: rehuffmanize kill to sendsignal or some such, we have:
:
: signal is a verb as well as a noun.
:
: sub alarm ($secs) {
:{ signal $*PID, Signal::ALARM }.cue(:delay($secs));
:}
:
: It even reads pretty nicely: signal 4242.
The cultural problem is that C's ancient signal() sets a signal
handler rather than sending a signal. I figured as long as we were
trying to discourage the use of signals we might as well make it
something even longer, but clearer.
Larry
Re: -X's auto-(un)quoting?
On Thu, Apr 21, 2005 at 06:40:54PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-21 8:54 (-0700):
: if $filename ~~ -r -w -x {...}
:
: Just curious - would the following dwym?
:
: if (prefix:-r prefix:-w prefix:-x)($filename) { ... }
It might do what you mean. Personally, I would never mean that if I
could help it. :-)
: It seems to me that -e «$_» would handle most of these cases, as long as
: whitespace always comes in quoted so that you always end up with one word.
: That seems more general than a special option to -X ops.
:
: Wouldn't it be a good option to combine the filetest operators into one
: operator? It'd even be historically correct to call that test:
:
: test(:r :w, $fn);
Hmm. I think this works syntactically:
$file ~~ all(:r:w)
: I still like -r -w $fn much better than the binding and the ~~ things.
There's one minor problem with -r -w $file, which is that it evaluates
right-to-left, which is going to surprise some people who think they
want to say
-e -r $file
when they really mean
-r -e $file
But that doesn't really matter much unless you're so much into speed
that you think about falsifying the test without doing a stat().
Now the interesting thing about the ~~ approach is that it naturally
lends itself to
given $file {
when :x {...}
when :r:w {...}
when :r(0) {...}
when :u | :g{...}
default:
}
I suppose it's a little bit rude to grab all the pairs for testing
against all the strings, so maybe we have to say
given $file.test {...}
$file.test ~~ :r:w
or maybe
given $file.stat {...}
$file.stat ~~ :r:w
which leaves room for lstat if we need it, though I can't say I'm fond
of the Unix naming scheme here. If we borrow from IO::All maybe it's just:
given io($file) {...}
io($file) ~~ :r:w
BTW, I'm assuming the $file is either $filename or $filehandle there.
Larry
