apo 2
Those new properties thingies are looking powerful. Does this mean we
can now do:
sub decorate ($obj) {
$obj is ad_hoc_method(sub {...});
}
and expect C<$obj.ad_hoc_method(...)> to call the appropriate
subroutine?
--
Piers Cawley
www.iterative-software.com
Re: So, we need a code name...
On Thu, May 03, 2001 at 12:32:40PM -0700, Larry Wall wrote: > Since it's something underlying Perl, I'd suggest a decrement of > "Perl", which would of course be "Perk". The Java engine would have > to be "Perj", I guess, which seems fitting somehow. Shouldn't the Java engine be "Perk" (or perhaps "Perc") is that just too fitting? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, "Spoon"
Re: sandboxing
On Thu, May 03, 2001 at 03:53:53PM -0500, David L. Nicol wrote: > the larger question remains, is sandboxing something a language > should support at all, or is it best left to the OS to provide > a solid chroot facility? CPANTS will have to try and clunk a sandbox together and I have no illusions about how difficult this will be. On a sane Unix, yes we have chroot. But what about Windows? MacOS? VMS? EEEK! Not withstanding getting into trying to limit things like sockets, disk usage, etc... Sure, Unix has ulimits, ipchains, quotas, etc... but what about the DumbOS's and the AncientOS's? IMHO that should be the indicator of whether Perl needs to provide a particular sandbox feature. If we leave it up to the OS, how many OS's leave no way (or very difficult ways) to do it. And how radically different are the ones which provide it? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One But unluckily most Germans here are too smart. They all speak good English and won't be able to speak German to me. --Alex Chiu, Immortality Guy
Re: apo 2
On Thu, 03 May 2001 22:14:47 -0500, David L. Nicol wrote: >I am going to miss doublequoting being the default quoting for >here strings. I find that to be a very nice optimization and >would like to know more about the reasoning behind taking it >away. I was already panicking when I saw this message. Of course, I hadn't seen Apo 2 itself, and I was really reliefed when I did. For the record: I had assumed that double quotish interpretation for the here docs was going to disappear. Not so. It's just that in $heredoc = <<"END"; foofoo foo foo END the double quotes around the end marker, "END", will have to be included. They may no longer be dropped. >I worry that official standard p6 will be more difficult >to use than official standard p5. Heh? I *always* put quotes around them. But I hardly ever restrict myself to word characters in the end delimiter, anyway. I fail to see the problem. -- Bart.
Re: sandboxing
At 12:03 PM 5/4/2001 +0100, Michael G Schwern wrote: >Sure, Unix has ulimits, ipchains, quotas, >etc... but what about the DumbOS's and the AncientOS's? You'll want to be careful of the epithets there. For this stuff the world is really divided into single-user and multi-user OSes. Unix ranks down at the bottom of the list in comparison to most of the other multiuser OSes, both in terms of what limits can be placed and what tracking and accounting data is collected. Building a good sandbox with resource limits on a VMS system is trivial. I expect it may even be easier with IBM's big iron OSes. It's less trivial with Unix, but not bad. Beats me on WindowsNT, though I'd bet it's up to the task. The single-user OSes are more problematic. I don't know that MacOS (before OS X) provides the info we need but as of System 7.x it didn't. Nor Win9x, or AmigaOS. (Though for those we can still track memory usage) >IMHO that should be the indicator of whether Perl needs to provide a >particular sandbox feature. If we leave it up to the OS, how many >OS's leave no way (or very difficult ways) to do it. And how >radically different are the ones which provide it? Luckily the security sandbox features are all implementable from within perl. It's the resource limitation ones that are trickier, especially CPU time. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: sandboxing
On Fri, May 04, 2001 at 09:20:13AM -0400, Dan Sugalski wrote:
> Building a good sandbox with resource limits on a VMS system is trivial. I
> expect it may even be easier with IBM's big iron OSes.
I'm sure it is. I'm just worried about having lots of:
if( $^O =~ /VMS/ ) {
do some really scarey (to a Unix user) VMS hacks
}
elsif( $^O =~ /Big Iron/ ) {
do some different really scarey hacks
}
etc...
Obviously this will have to be done at some point, but I'd rather it
was encapsulated somewhere. Either inside Perl or in some core
sandbox/Safe module.
> It's less trivial with Unix, but not bad. Beats me on WindowsNT,
> though I'd bet it's up to the task.
>
> The single-user OSes are more problematic. I don't know that MacOS (before
> OS X) provides the info we need but as of System 7.x it didn't. Nor Win9x,
> or AmigaOS. (Though for those we can still track memory usage)
I'd prefer that when we think about the cross-platformness of Perl 6
we keep these troublesome OS's in mind as far as considering what Perl
should leave to itself and what it should leave for the OS to decide.
> Luckily the security sandbox features are all implementable from
> within perl. It's the resource limitation ones that are trickier,
> especially CPU time.
Memory limits we should be able to do, assuming Perl 6 continues to
have its own malloc.
CPU usage is a problem... we could provide two similar, but easier to
implement, features. Throttling (by sticking a tiny little sleep
between each opcode) and limited running (ie. kill yourself if you run
longer than X seconds). The latter we might be able to pull of
externally using SIGALRM, but not all systems have that.
Also things like limiting the number of open filehandles and sockets and
limiting network usage could be done inside perl.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
And Solaris must be destroyed.
-- Peter Miller
Re: apo 2
Piers Cawley wrote:
> sub decorate ($obj) {
> $obj is ad_hoc_method(sub {...});
> }
> and expect C<$obj.ad_hoc_method(...)>
And btw . . . Wouldn't
$thing has property
make more sense than
$thing is property
???
"Is" usually implies a generalization link,
not a specialization link.
--
John Porter
It's so mysterious, the land of tears.
Re: apo 2
Bart Lateur wrote: > I hardly ever restrict > myself to word characters in the end delimiter, anyway. Interesting -- I *always* use "EOF", because that's the only one vim knows a priori how to highlight correctly. :-/ -- John Porter It's so mysterious, the land of tears.
Re: apo 2
On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote: > And btw . . . Wouldn't > > $thing has property > > make more sense than > > $thing is property "$foo has true" doesn't flow as well as "$foo is true". Dunno quite what the other expected uses are. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Stupid am I? Stupid like a fox!
Re: sandboxing
> Memory limits we should be able to do, assuming Perl 6 continues to > have its own malloc. Well... Perl doesn't use it's own malloc *that* widely. E.g. Linux doesn't, since at least 5.005_03. FreeBSD doesn't. OpenBSD doesn't. Darwin doesn't. AIX doesn't. IRIX doesn't. Starting from 5.8.0 Solaris won't (at the behest of Alan Burlison and few others). The reason? Usually it has been the system malloc being (a) faster (I think the BSDs) (b) more robust under multithreading (IRIX). Also starting from 5.8.0 Tru64 or any other naturally 64bitall plaform won't (since the Perl malloc is not 64bitall-clean). > CPU usage is a problem... we could provide two similar, but easier to > implement, features. Throttling (by sticking a tiny little sleep > between each opcode) and limited running (ie. kill yourself if you run > longer than X seconds). The latter we might be able to pull of > externally using SIGALRM, but not all systems have that. Or setrlimit() for the systems that have that. > Also things like limiting the number of open filehandles and sockets and > limiting network usage could be done inside perl. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: sandboxing
On Fri, May 04, 2001 at 09:03:05AM -0500, Jarkko Hietaniemi wrote: > > Memory limits we should be able to do, assuming Perl 6 continues to > > have its own malloc. > > Well... Perl doesn't use it's own malloc *that* widely. Who knows what Perl 6 will do internally, but we'll probably have some sort of malloc wrapper at least. Anyhow, if you need to set a certain flag when compiling perl6 to allow certain sandbox features (I can see certain checks necessary being in very hot parts of the code) that should be ok. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One AY! The ground beef, she is burning my groin! http://sluggy.com/d/990105.html
Re: apo 2
At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote:
>On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote:
> > And btw . . . Wouldn't
> >
> > $thing has property
> >
> > make more sense than
> >
> > $thing is property
>
>"$foo has true" doesn't flow as well as "$foo is true". Dunno quite
>what the other expected uses are.
Maybe "has" and "is", used in this context, could be synonyms?
my NetFile $page has url("http://www.perl.com/";);
$page is constant;
or maybe
my Netfile $page has url("http://www.perl.com/";) is constant;
(can properties stack like that?)
I think it depends on the property whether "has" or "is" is grammatically
correct.
Or we could have a policy that all example-properties have the
"has-nature". Instead of:
$foo is true;
$foo is true(1);
$foo is true(0);
we would have:
$foo has truth;
$foo has truth(1);
$foo has truth(0);
Or some such...
Re: apo 2
Michael G Schwern wrote: > "$foo has true" doesn't flow as well as "$foo is true". But the general form, something like $thing is a_property or $thing is a_behavior flows considerably worse, IMHO. -- John Porter It's so mysterious, the land of tears.
Re: apo 2
Michael G Schwern writes:
> "$foo has true" doesn't flow as well as "$foo is true". Dunno quite
> what the other expected uses are.
$foo has truth; # :-)
This leads naturally to:
$foo has the_buddha_nature;
$foo has ten_days_to_live;
$foo has meddled_in_my_affairs_one_too_many_times! # ! as assertion
$elvis has left("the building");
Nat
RE: apo 2
From: Buddha Buck [mailto:[EMAIL PROTECTED]]
> At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote:
> >On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote:
> > > And btw . . . Wouldn't
> > >
> > > $thing has property
> > >
> > > make more sense than
> > >
> > > $thing is property
> >
> >"$foo has true" doesn't flow as well as "$foo is true". Dunno quite
> >what the other expected uses are.
>
[...]
>
>my Netfile $page has url("http://www.perl.com/";) is constant;
Maybe it is just my interpretation of Damian's OO-Perl book... but:
is => typing, inheritance, etc.
has => composition, aggregation, etc.
Re: apo 2
On Fri, May 04, 2001 at 09:47:18AM -0600, Nathan Torkington wrote:
> Michael G Schwern writes:
> > "$foo has true" doesn't flow as well as "$foo is true". Dunno quite
> > what the other expected uses are.
>
> $foo has truth; # :-)
>
> This leads naturally to:
>
> $foo has the_buddha_nature;
> $foo has ten_days_to_live;
> $foo has meddled_in_my_affairs_one_too_many_times! # ! as assertion
> $elvis has left("the building");
$foo has no future;
$we have fun_fun_fun;
$we are hopeless;
Okay, time to start working...
> Nat
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: apo 2
@pi are square; @dogs have fleas; @talks have stalled; -- John Porter
Re: apo 2
On Fri, 4 May 2001 10:49:48 -0500 , Garrett Goebel wrote: >> > > And btw . . . Wouldn't >> > > >> > > $thing has property >> > > >> > > make more sense than >> > > >> > > $thing is property >> > >> >"$foo has true" doesn't flow as well as "$foo is true". Dunno quite >> >what the other expected uses are. >Maybe it is just my interpretation of Damian's OO-Perl book... but: > >is => typing, inheritance, etc. >has => composition, aggregation, etc. Thinking as in VB again... I associate a property with "has", and a default property with "is". Something like: $label is "Click here"; $label has caption => "Click here"; Jeezes, this is weird stuff. -- Bart.
RE: apo 2
At 10:49 AM 05-04-2001 -0500, Garrett Goebel wrote:
>From: Buddha Buck [mailto:[EMAIL PROTECTED]]
> > At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote:
> > >On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote:
> > > > And btw . . . Wouldn't
> > > >
> > > > $thing has property
> > > >
> > > > make more sense than
> > > >
> > > > $thing is property
> > >
> > >"$foo has true" doesn't flow as well as "$foo is true". Dunno quite
> > >what the other expected uses are.
> >
>[...]
> >
> >my Netfile $page has url("http://www.perl.com/";) is constant;
>
>Maybe it is just my interpretation of Damian's OO-Perl book... but:
>
>is => typing, inheritance, etc.
>has => composition, aggregation, etc.
True, but those are basic OO concepts, which don't neatly apply to
property-lists (a very old Lisp concept that Perl6 is adopting).
Re: apo 2
On Fri, May 04, 2001 at 11:51:43AM -0400, John Porter wrote: > @pi are square; Pi are round. Cake are square. -- Tad McClellan SGML consulting [EMAIL PROTECTED] Perl programming Fort Worth, Texas
Re: apo 2
Edward Peschko writes:
: Anyways, my one curiosity that sticks out would be: why \Q as being a way to
: disambiguate? You could do the same thing with:
:
: print "$foo\[1]\n"
: vs
: print "$foo[1]\n";
Not good enough. Consider what this might means:
m/$foo\[a-z]\n/
Is it matching a literal [ or starting a character class?
What people need to realize is that the ugliness of \Q is a feature.
It's designed to stop you in your visual tracks.
But I really don't mind nested structures--the problem with ${foo[bar]}
was precisely that it *wasn't* nested right. So the people who still want
to use nesting can always use expression interpolation:
print "$( $foo )[1]\n"
which I think can reasonably be made to stop parsing at the right paren.
(Though a case could be made for continuing there too... However, I
expect that anything you could do outside the parens you could also
do inside, so there's no reason not to stop parsing there.)
Larry
Apo2: \Q ambiguity
In Apocalypse 2, \Q is being used for two things, and I believe this may be
ambiguious.
It has the current \Quote meaning admitibly \Q{oute} it is also being
proposed for a null token disambiguate context. As in $foo\Q[bar].
But if it is spliting $foo and {this is in curlies} this will be taken as
\Quoting the content of the curlies.
I think that \Q for quoting and \Q for a null token should be different.
And given that the null token is new this is what should use something new.
It may also be a good idea to allow alternative brackets in \Q{...} in
much the same way as one can use different symbols for s///. If what you
are quoting uses curlies, one might choose angle brackets, or square
brackets.
Richard
--
[EMAIL PROTECTED]
RE: apo 2
> >is => typing, inheritance, etc.
> >has => composition, aggregation, etc.
>
> True, but those are basic OO concepts, which don't neatly apply to
> property-lists (a very old Lisp concept that Perl6 is adopting).
"is" does seem to imply an OO is-a relationship. So lets run
with it!
If $foo is an object of type INTEGER, then $foo.bit calls a
method that compares the numeric value against 0 and returns
1 if not zero.
If $foo is true, then its method $foo.bit is expected to return
1.
In OO terms, when you override the behaviour of your methods, you
are usually subclassing. So perhaps the declaration "$foo is true"
should literally mean: "create an anonymous subclass derived from
$foo's class that overrides its .bit method to return 1; change
$foo's class to this new subclass" Multiple "is" declarations
would simply stack up the subclasses.
If "true" is a class with a single method "sub .bit { return 1 }",
then the subclass of $foo is creating by copying "true"'s methods.
So "$foo is myClass" simply means that we subclass $foo with a
clone of myClass. "constant" would be a class that overrides the
assignment operator.
On a slightly different note, I read that "my Dog $foo" doesn't
call a ctor. I do hope that "my URL $name; ...; $name="www.foo.bar"
does DWIM.
Dave.
p.s. I prefer to paint my bikeshed's true and false as .bool, not
.bit. In the hardware world, the distinction is important because
we often slip into negative logic.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
Re: Apo2: \Q ambiguity
Richard Proctor writes:
: In Apocalypse 2, \Q is being used for two things, and I believe this may be
: ambiguious.
:
: It has the current \Quote meaning admitibly \Q{oute} it is also being
: proposed for a null token disambiguate context. As in $foo\Q[bar].
Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge.
I'll have to think about it. Maybe quotemeta becomes \qm{} or some such.
Larry
Re: Apo2: \Q ambiguity
Larry Wall writes:
: Richard Proctor writes:
: : In Apocalypse 2, \Q is being used for two things, and I believe this may be
: : ambiguious.
: :
: : It has the current \Quote meaning admitibly \Q{oute} it is also being
: : proposed for a null token disambiguate context. As in $foo\Q[bar].
:
: Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge.
: I'll have to think about it. Maybe quotemeta becomes \qm{} or some such.
I guess that might also mean that \L turns into \ql{} and \U turns into
\qu{}. Hmm. That would mean that
$x = ql{$(EXPR)};
means the same thing as lc(EXPR). Interesting.
Don't panic, I'm just thinking out loud...
Larry
RE: Apo2: \Q ambiguity
From: Larry Wall [mailto:[EMAIL PROTECTED]]
> Richard Proctor writes:
> : In Apocalypse 2, \Q is being used for two things, and I
> : believe this may be ambiguious.
> :
> : It has the current \Quote meaning admitibly \Q{oute} it is
> : also being proposed for a null token disambiguate context.
> : As in $foo\Q[bar].
>
> Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge.
> I'll have to think about it. Maybe quotemeta becomes \qm{}
> or some such.
The problem with \Q quotemeta was the biggest thing to jump out at me when
reading A2... That is before my brain turned to mush. Seems like quotemeta
be serving its purpose if you have to consider escaping its contents...
What's the Perl6 equivalent to:
#!perl -w
# script.pl:
my ($match, $filename) = @ARGV;
local $/;
open FH, $filename;
$file = ;
print scalar @{[$file =~ m/(\Q$match\E)/gs]};
1;
__END__
file.txt contents:
{foo}\E{foo}\E{foo}
> script.pl {foo} file.txt
3
>
Re: Apo2: \Q ambiguity
At 11:10 AM 5/4/2001 -0700, Larry Wall wrote:
>Larry Wall writes:
>: Richard Proctor writes:
>: : In Apocalypse 2, \Q is being used for two things, and I believe this
>may be
>: : ambiguious.
>: :
>: : It has the current \Quote meaning admitibly \Q{oute} it is also being
>: : proposed for a null token disambiguate context. As in $foo\Q[bar].
>:
>: Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge.
>: I'll have to think about it. Maybe quotemeta becomes \qm{} or some such.
>
>I guess that might also mean that \L turns into \ql{} and \U turns into
>\qu{}. Hmm. That would mean that
>
> $x = ql{$(EXPR)};
>
>means the same thing as lc(EXPR). Interesting.
Have you considered allowing Unicode characters as alternatives to some of
the less pleasant looking bits? $foo<<1>> (where << and >> are the double
angle characters) as an alternative to $foo\Q[1] if the user's got the
characters handy?
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: sandboxing
At 02:46 PM 5/4/2001 +0100, Michael G Schwern wrote:
>On Fri, May 04, 2001 at 09:20:13AM -0400, Dan Sugalski wrote:
> > Building a good sandbox with resource limits on a VMS system is trivial. I
> > expect it may even be easier with IBM's big iron OSes.
>
>I'm sure it is. I'm just worried about having lots of:
>
> if( $^O =~ /VMS/ ) {
> do some really scarey (to a Unix user) VMS hacks
> }
Gack, no. No way. The functions we need will have platform-specific code
living in the right place--vms.c, solaris.c, hp.c, or whatever. The
function call signature stays the same and the right platform-specific code
is brought in at perl build time.
> > It's less trivial with Unix, but not bad. Beats me on WindowsNT,
> > though I'd bet it's up to the task.
> >
> > The single-user OSes are more problematic. I don't know that MacOS (before
> > OS X) provides the info we need but as of System 7.x it didn't. Nor Win9x,
> > or AmigaOS. (Though for those we can still track memory usage)
>
>I'd prefer that when we think about the cross-platformness of Perl 6
>we keep these troublesome OS's in mind as far as considering what Perl
>should leave to itself and what it should leave for the OS to decide.
We really can't leave much at all to the OS to decide. Most of the OS-level
safety measures are process-wide and many are undoable. (Which is good,
otherwise they're reasonably pointless as ways to restrict access) chroot()
for example won't help us much when executing code in a safe partition,
since we really want to be able to undo it when we're not in the partition.
That means we need to handle the restrictions from within the interpreter.
(And yes, I realize that C extensions can bypass it if they want)
> > Luckily the security sandbox features are all implementable from
> > within perl. It's the resource limitation ones that are trickier,
> > especially CPU time.
>
>Memory limits we should be able to do, assuming Perl 6 continues to
>have its own malloc.
Yep. Even if it doesn't we can jacket the system calls if we need to for
tracking purposes.
>CPU usage is a problem... we could provide two similar, but easier to
>implement, features. Throttling (by sticking a tiny little sleep
>between each opcode) and limited running (ie. kill yourself if you run
>longer than X seconds). The latter we might be able to pull of
>externally using SIGALRM, but not all systems have that.
We'd want an alternative opcode running loop for all this, and it could
easily enough check times, as could special opcodes. Long-running codes
could also check at reasonable breakpoints. (Still in trouble with C
extensions, but that's pretty much a guarantee)
>Also things like limiting the number of open filehandles and sockets and
>limiting network usage could be done inside perl.
Sure. Reasonably easily trackable from within a partition. We might want to
track this anyway for the debugger or statistical analyzer or something.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Apo2: \Q ambiguity
On Fri, May 04, 2001 at 03:05:12PM -0400, Dan Sugalski wrote: > Have you considered allowing Unicode characters as alternatives to some of > the less pleasant looking bits? $foo<<1>> (where << and >> are the double > angle characters) as an alternative to $foo\Q[1] if the user's got the > characters handy? I superficially like this idea, but then when the file gets passed to a user who doesn't have the relevant Unicode support you get $foo1, which isn't fun to support any more. -- DISCLAIMER: Use of this advanced computing technology does not imply an endorsement of Western industrial civilization.
Re: Apo2: \Q ambiguity
On Fri, 04 May 2001 15:05:12 -0400, Dan Sugalski wrote: >Have you considered allowing Unicode characters as alternatives to some of >the less pleasant looking bits? $foo<<1>> (where << and >> are the double >angle characters) as an alternative to $foo\Q[1] if the user's got the >characters handy? Until now, all characters with a special meaning for the syntax of the language, are in the ASCII range. I see no reason to change that. This is the case for most programming languages, with as a notable exception APL. -- Bart.
Re: Apo2: \Q ambiguity
At 11:33 PM 5/4/2001 +0200, Bart Lateur wrote: >On Fri, 04 May 2001 15:05:12 -0400, Dan Sugalski wrote: > > >Have you considered allowing Unicode characters as alternatives to some of > >the less pleasant looking bits? $foo<<1>> (where << and >> are the double > >angle characters) as an alternative to $foo\Q[1] if the user's got the > >characters handy? > >Until now, all characters with a special meaning for the syntax of the >language, are in the ASCII range. I see no reason to change that. This >is the case for most programming languages, with as a notable exception >APL. Yes, I know. I'm not asking that we have syntax characters that are exclusively Unicode, merely that some of the skankier bits have neater Unicode equivalents. If we're not going to allow Unicode identifiers then I withdraw the suggestion. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity
At 10:11 PM 5/4/2001 +0100, Simon Cozens wrote: >On Fri, May 04, 2001 at 03:05:12PM -0400, Dan Sugalski wrote: > > Have you considered allowing Unicode characters as alternatives to some of > > the less pleasant looking bits? $foo<<1>> (where << and >> are the double > > angle characters) as an alternative to $foo\Q[1] if the user's got the > > characters handy? > >I superficially like this idea, but then when the file gets passed to a >user who doesn't have the relevant Unicode support you get >$foo1, which isn't fun to support any >more. As opposed to "my $" as someone decides to use Katakana variable names? :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity
Dan Sugalski writes: : Have you considered allowing Unicode characters as alternatives to some of : the less pleasant looking bits? $foo<<1>> (where << and >> are the double : angle characters) as an alternative to $foo\Q[1] if the user's got the : characters handy? Actually, my first thought a year or three ago was to replace qw() with «», but we just aren't there with the Unicode editors yet. My keyboard seems to be missing a few of the characters, too. :-) I won't tell you what I had to go through just to get those two characters into this message, and they're still only in Latin-1. So my take is that people should be able to define their operators up into the Unicode range if that makes them happy, and they don't plan to ship their code widely in the next year or two. After that, once most of the artificial cross-cultural barriers are torn down, we'll be left with the real cross-cultural barriers, which will be a little harder to get over. Americans will be slow in picking up Kanji, I suspect. But the APL operators are foreign to just about everyone, so that handicaps us all equally. By the way, $¾ is not valid Perl, comments on Slashdot notwithstanding. Variables still have to start with a letter (or ideograph). It might well be the case that ¾ could be defined to return 0.75, however. Larry
Re: So, we need a code name...
> Too many dead parrot jokes? Too many lousy acronyms? > > Platform-Agnostic Rabidly Rapid Object Thrasher well, it doesn't have to be underlined by an acronym.. and if you don't like parrot, how about a play on the name w/'polly'? > Urque. > > Since it's something underlying Perl, I'd suggest a decrement of > "Perl", which would of course be "Perk". The Java engine would have > to be "Perj", I guess, which seems fitting somehow. The C# engine might > be "Peri" because it's around whether you like it or not. also - why does it have to be tied to perl (in name) at all? I like the idea that it would *not* be tied to perl, ie: it would be more generic if it was not named after it. How about 'prism' (ie: multiple languages from one underlying platform)? Ed
Apoc2 - concerns
There's a lot of good stuff in Apoc2, but I did have at least one
semantic concern. In it, there's this proposal:
: There is likely to be no need for an explicit input operator in Perl 6,
: and I want the angles for something else. I/O handles are a subclass of
: iterators, and I think general iterator variables will serve the purpose
: formerly served by the input operator, particularly since they can
: be made to do the right Thing in context. For instance, to read from
: standard input, it will suffice to say
:
: while ($STDIN) { ... }
I'm wondering what this will do?
$thingy = $STDIN;
This seems to have two possibilities:
1. Make a copy of $STDIN
2. Read a line from $STDIN
To be semantically coherent, it seems that the first one should be the way
it works, like with other variables. That is:
$FILE = open "; # or $FILE.readline
This gives you some niceties:
$STDERR = $STDOUT; # redirect
Or, it could be that simple assignment instead grabs the iterator:
$line = $FILE; # grabs $FILE.readline, which is next line
$DUP = $FILE.dup;# must call dup() to duplicate filehandle
If it's the latter, then <> is free. However, if it's the former then
we'll still need them. Personally, that latter one scares me a little,
but I'm open-minded.
-Nate
Re: Apo2: \Q ambiguity not a problem
Not a problem. \Q means quotemeta, except immediately following
a interpolated identifier. You want to start metaquoting immediately
after a curious interpolation? use \Q\Q.
I have been regularly, since I fingured out how, doing things like
print "the time is now ${\(~~localtime)}[go home!]"; # double-not
"scalar" golf hack
in p6 without "weird brackets" I supposed this becomes
print "the time is now $(+localtime)\Q[go home!]";
Right? So if I wanted to quotemeta this thing so I could let sh have it
safely, what in apo2 is preventing me from writing
print "the time is\Q now < $(+localtime)\Q[go home!] \E";
the only time there's an ambiguity is when the metaquoting starts
immediately
after the stopped variable identifier
print SH "echo the time is now `date` so go $destinations{first}\Q\Q
<$tainted> \E";
perl -le'print "\Q\Q\Q <<\E<\E< \E <"'
\\\ \\\<\\\<\\\<\<\ <
metaquote stacks -- why not use \E instead? it has the same issues, but
has
no effect at all currently, and E is for End_of_interpolble_specifier a lot
more than \Q does.
\Q\E is a safe zero-length noninterpolable in any context however, with
no side effect
Garrett Goebel wrote:
>
> From: Larry Wall [mailto:[EMAIL PROTECTED]]
> > Richard Proctor writes:
> > : In Apocalypse 2, \Q is being used for two things, and I
> > : believe this may be ambiguious.
> > :
> > : It has the current \Quote meaning admitibly \Q{oute} it is
> > : also being proposed for a null token disambiguate context.
> > : As in $foo\Q[bar].
> >
> > Hmm, yes, that's a problem. I'd forgotten about the quotemeta kludge.
> > I'll have to think about it. Maybe quotemeta becomes \qm{}
> > or some such.
>
> The problem with \Q quotemeta was the biggest thing to jump out at me when
> reading A2... That is before my brain turned to mush. Seems like quotemeta
> be serving its purpose if you have to consider escaping its contents...
> What's the Perl6 equivalent to:
>
> #!perl -w
> # script.pl:
> my ($match, $filename) = @ARGV;
> local $/;
> open FH, $filename;
> $file = ;
> print scalar @{[$file =~ m/(\Q$match\E)/gs]};
> 1;
> __END__
>
> file.txt contents:
> {foo}\E{foo}\E{foo}
>
> > script.pl {foo} file.txt
> 3
> >
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Parse, munge, repeat.
Re: Apoc2 - concerns
if we kept <> with their current meaning but added it as a handier whitespace quoter I would like that. p5: @things = < one two three four five>; _is_ currently a syntax error. In my mind. Not in my 5.005_03. however, where it appears to behave just like qw does, except that it does interpolation, which qw does not. Is the proposal, then, to abandon the interpolation within angle-quotes? Or just to give the feature some much-needed > perl -le '@things = < one two three four a$"a five>; print "@things"' one two three four a a five > perl -le '@things = qw< one two three four a$"a five>; print "@things"' one two three four a$"a five
Re: Apo2: \Q ambiguity
At 03:51 PM 5/4/2001 -0700, Larry Wall wrote: >Dan Sugalski writes: >: Have you considered allowing Unicode characters as alternatives to some of >: the less pleasant looking bits? $foo<<1>> (where << and >> are the double >: angle characters) as an alternative to $foo\Q[1] if the user's got the >: characters handy? > >Actually, my first thought a year or three ago was to replace qw() >with «», but we just aren't there with the Unicode editors yet. >My keyboard seems to be missing a few of the characters, too. :-) > >I won't tell you what I had to go through just to get those two >characters into this message, and they're still only in Latin-1. > >So my take is that people should be able to define their operators up >into the Unicode range if that makes them happy, and they don't plan to >ship their code widely in the next year or two. That's cool. I was just thinking it might not be a bad idea for us to set some equivalencies up in advance. If not, that's fine too. (I'll just slip them in while you're not looking... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity not a problem
David L. Nicol writes:
: Not a problem. \Q means quotemeta, except immediately following
: a interpolated identifier. You want to start metaquoting immediately
: after a curious interpolation? use \Q\Q.
The word "except" should be a red flag that you're trying to define an
exception. We're trying to reduce the number of exceptions these days,
at least in the areas where context sensitivity doesn't buy you power.
: I have been regularly, since I fingured out how, doing things like
:
:
: print "the time is now ${\(~~localtime)}[go home!]"; # double-not
: "scalar" golf hack
Er, if you've been doing things like that, then you must be fond of
syntax errors. Those are not "weird brackets", they're just dereference
brackets. Perl 5 keeps parsing the expression after ${}, so [go home!]
is a subscript.
The ~~ is a cute hack though.
Weird brackets are only of the form ${foo[bar]} or ${foo{bar}}. We're
not proposing to get rid of ${foo}[bar], except insofar as we're making
it do the same thing inside quotes as outside, which it doesn't right
now.
: in p6 without "weird brackets" I supposed this becomes
:
: print "the time is now $(+localtime)\Q[go home!]";
I think $() will end interpolation automatically (since you could
always put the subscript inside if you really want it), so the \Q
wouldn't be necessary. And you don't want + there unless you want it
numified, I suspect, though I could change my mind on that. The $()
already puts it in scalar context.
: Right? So if I wanted to quotemeta this thing so I could let sh have it
: safely, what in apo2 is preventing me from writing
:
: print "the time is\Q now < $(+localtime)\Q[go home!] \E";
:
: the only time there's an ambiguity is when the metaquoting starts
: immediately
: after the stopped variable identifier
I'm sorry, my eyes go crossed when I look at that, and the two \Q's
merge into one, which confuses me, in a stereoscopic sort of way.
: print SH "echo the time is now `date` so go $destinations{first}\Q\Q
: <$tainted> \E";
: perl -le'print "\Q\Q\Q <<\E<\E< \E <"'
: \\\ \\\<\\\<\\\<\<\ <
:
: metaquote stacks -- why not use \E instead? it has the same issues, but
: has
: no effect at all currently, and E is for End_of_interpolble_specifier a lot
: more than \Q does.
:
: \Q\E is a safe zero-length noninterpolable in any context however, with
: no side effect
We could leave \Q{} as metaquote and use \E for a expression stopper,
though that would be confusing to people used to the old \E, which is
dead, dead, dead, drive a stake through its heart, dead. (I hope...)
Larry
Re: So, we need a code name...
Edward Peschko writes: : also - why does it have to be tied to perl (in name) at all? Er, because we're writing it? : I like the idea : that it would *not* be tied to perl, ie: it would be more generic if it was : not named after it. Well, the fact that Tcl and Tk both start with T didn't stop people from abstracting it away. I think that has little to do with the name, but with how generally useful the platform is. : How about 'prism' (ie: multiple languages from one underlying platform)? Do a search for "prism" on Yahoo and then come back with a serious suggestion. There's even a "Prism programming language" out there. (And yes, I did do a search for "perk" before I suggested it.) New-age-techie words like "prism" are an attractive nuisance, and should be avoided if we want people to find our stuff. Larry
Re: Apoc2 - concerns
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
> : while ($STDIN) { ... }
> I'm wondering what this will do?
>$thingy = $STDIN;
> This seems to have two possibilities:
>1. Make a copy of $STDIN
This one. I see a filehandle in *boolean* context meaning "read to $_",
just like the current "while ()" magic we all know and occasionally
love. I'd expect $FOO.readln (or something less Pascalish) to do an
explicit readline to a variable other than $_
--
You want to read that stuff, fine. You want to create a network for such
things, fine. You want to explore the theoretical boundaries of free speech,
fine. But when it starts impacting *people* trying to *communicate*, then
that is where I draw the line. - Russ Allbery, http://www.slacker.com/rant.html
Re: Apoc2 - concerns
On Fri, May 04, 2001 at 07:34:24PM -0500, David L. Nicol wrote: > @things = < one two three four five>; > > _is_ currently a syntax error. In my mind. Not in my 5.005_03. > however, where it appears to behave just like qw does, > except that it does interpolation, which qw does not. And shell globbing, which should be a clue as to what it really means. :) -- teco < /dev/audio - Ignatios Souvatzis
Re: Apoc2 - concerns
> > I'm wondering what this will do? > >$thingy = $STDIN; > > This seems to have two possibilities: > >1. Make a copy of $STDIN > > This one. I see a filehandle in *boolean* context meaning "read to $_", > just like the current "while ()" magic we all know and occasionally > love. I'd expect $FOO.readln (or something less Pascalish) to do an > explicit readline to a variable other than $_ $STDIN.next is the current plan. Damian
Apoc2 - concerns
[apologies if this is a duplicate, but my mail's been dropping]
There's a lot of good stuff in Apoc2, but I did have at least one
semantic concern. In it, there's this proposal:
: There is likely to be no need for an explicit input operator in Perl 6,
: and I want the angles for something else. I/O handles are a subclass of
: iterators, and I think general iterator variables will serve the purpose
: formerly served by the input operator, particularly since they can
: be made to do the right Thing in context. For instance, to read from
: standard input, it will suffice to say
:
: while ($STDIN) { ... }
I'm wondering what this will do?
$thingy = $STDIN;
This seems to have two possibilities:
1. Make a copy of $STDIN
2. Read a line from $STDIN
To be semantically coherent, it seems that the first one should be the way
it works, like with other variables. That is:
$FILE = open "<$file";
$DUP = $FILE;# dup input stream
$line = <$FILE>; # or $FILE.readline
This gives you some niceties:
$STDERR = $STDOUT; # redirect
Or, it could be that simple assignment instead grabs the iterator:
$line = $FILE; # grabs $FILE.readline, which is next line
$DUP = $FILE.dup;# must call dup() to duplicate filehandle
If it's the latter, then <> is free. However, if it's the former then
we'll still need them. Personally, that latter one scares me a little,
but I'm open-minded.
-Nate
Re: Apoc2 - concerns
On Sat, May 05, 2001 at 11:13:40AM +1000, Damian Conway wrote: >> love. I'd expect $FOO.readln (or something less Pascalish) to do an > > $STDIN.next is the current plan. Ah, OK. Crystal ball was a bit cloudy there. -- Putting heated bricks close to the news.admin.net-abuse.* groups. -- Megahal (trained on asr), 1998-11-06
Re: Apoc2 - concerns
Simon Cozens writes:
: On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
: > : while ($STDIN) { ... }
: > I'm wondering what this will do?
: >$thingy = $STDIN;
: > This seems to have two possibilities:
: >1. Make a copy of $STDIN
:
: This one. I see a filehandle in *boolean* context meaning "read to $_",
: just like the current "while ()" magic we all know and occasionally
: love. I'd expect $FOO.readln (or something less Pascalish) to do an
: explicit readline to a variable other than $_
It would be $FOO.next, but yes, that's the basic idea. It's possible
that iterator variables should be more syntactically distinquished than
that. One could, I suppose, make up something about $
meaning the same thing thing as $FOO.next, for people who are homesick
for the angles, but I haven't thought that out, and don't even dare to
mention it here for fear someone will take it as a promise. Er, oops...
Larry
Re: Apoc2 - concerns
> : This one. I see a filehandle in *boolean* context meaning "read to $_", > : just like the current "while ()" magic we all know and occasionally > : love. I'd expect $FOO.readln (or something less Pascalish) to do an > : explicit readline to a variable other than $_ > > It would be $FOO.next, but yes, that's the basic idea. It's possible > that iterator variables should be more syntactically distinquished than > that. One could, I suppose, make up something about $ > meaning the same thing thing as $FOO.next, for people who are homesick > for the angles, but I haven't thought that out, and don't even dare to > mention it here for fear someone will take it as a promise. Er, oops... So, just to clarify, the thought is: print while ($FOO);# like Perl 5 $var = $FOO.next; # like Perl 5 $var = ; I assume that this is indicative of a more general iterator syntax, and subject to indirect objects? $FH = open "<$file" or die "Can't open $file: $!"; $line = next $FH; If so, I can live with that. -Nate
Re: Apo2: \Q ambiguity
Dan Sugalski writes: : That's cool. I was just thinking it might not be a bad idea for us to set=20 : some equivalencies up in advance. If not, that's fine too. (I'll just slip= : =20 : them in while you're not looking... :) Hmm. Harks back to the colonial era: "I claim these brackets in the name of Perl." Hmm. I guess the "We came in peace for all mankind" approach only works when you're quite sure nobody else is gonna claim it for themselves any time soon, which is much truer of the Moon than of Unicode. We hope. Larry
Re: Apoc2 - concerns
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote: > I'm wondering what this will do? > >$thingy = $STDIN; > > This seems to have two possibilities: > >1. Make a copy of $STDIN > >2. Read a line from $STDIN While perhaps inconsistent, I'd really rather it did #2. Here's the basic argument... compare how often you dup a filehandle with how often you read from one. Duping is swamped by several orders of magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line = $STDIN.next should still work normally. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Do you have a map? Because I keep getting lost in your armpits.
Re: So, we need a code name...
Has anyone suggested "Oyster", or is that too obvious? __ Matt Youell - "Think different, just like everyone else." [EMAIL PROTECTED] http://www.youell.com/matt/
Re: Apoc2 - concerns
> While perhaps inconsistent, I'd really rather it did #2. Here's the > basic argument... compare how often you dup a filehandle with how > often you read from one. Duping is swamped by several orders of > magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line = > $STDIN.next should still work normally. You know, I hear what you're saying, but it really makes the little hairs on my neck stand up. Just imaging trying to teach this: $a = $b;# assignment or readline? It's really spooky. You're changing what = does, indeed what method it calls (copy vs next), based on the contents of the variable. I'd much rather have to do: $a = next $b; Truthfully, I've always liked the <>'s (and personally don't think we need a qw alternative), so I'd rather we stay with: $a = <$b>; # same as next $b or $b.next Hey, maybe we can convince Larry... ;-) -Nate
Re: Apoc2 - concerns
From: "Michael G Schwern" <[EMAIL PROTECTED]>
To: "Nathan Wiger" <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 9:46 PM
> On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
> > I'm wondering what this will do?
> >$thingy = $STDIN;
> > This seems to have two possibilities:
> >1. Make a copy of $STDIN
> >2. Read a line from $STDIN
>
> While perhaps inconsistent, I'd really rather it did #2. Here's the
> basic argument... compare how often you dup a filehandle with how
> often you read from one. Duping is swamped by several orders of
> magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
> $STDIN.next should still work normally.
Here's what I'd like (in general interators):
1) Using in a scalar context gets the next value. $line = $STDIN;
2a) Using in a unknown-length list context gets all the values. @lines =
$STDIN;
2b) Using in a known-length list context gets enough values. ($line1,
$line2) = $STDIN;
3) Using on the LHS of a = outputs a value (or a bunch of values if RHS is a
list).
4) Using on the RHS of a := copies. $STDOUT := $STDERR;
5) Using with a $() operator won't get. if ($($STDOUT) eq $($STDIN)) {foo}.
(?)
That is, getting without somthing special gets values out of the iterator,
getting
with a := gets the iterator itself (: for inner), and $() derefs it to a
filenameish thing (?).
This leaves <> free, and I think the use of := agrees with what is planned.
It also avoids the use of a verbose .next (and the dot, which I still don't
like ).
-=- James Mastros
Re: Apoc2 - concerns
From: "Nathan Wiger" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, May 04, 2001 10:02 PM Subject: Re: Apoc2 - concerns > You know, I hear what you're saying, but it really makes the little hairs on > my neck stand up. Just imaging trying to teach this: >$a = $b;# assignment or readline? > It's really spooky. You're changing what = does, indeed what method it calls > (copy vs next), based on the contents of the variable. I'd much rather have > to do: >$a = next $b; I think that = should always be "get a value", and := should always be "get the thing itself". For normal things, the thing itself and it's value are the same, so := is equivlent to =. > Truthfully, I've always liked the <>'s (and personally don't think we need a > qw alternative), so I'd rather we stay with: >$a = <$b>; # same as next $b or $b.next > Hey, maybe we can convince Larry... ;-) I'd tend to agree. Especialy that we don't need a qw() alternative. However, I don't think Larry's in a convincable mood -- coughdotcough. -=- James Mastros
Re: Apoc2 - concerns
On Fri, May 04, 2001 at 07:02:14PM -0700, Nathan Wiger wrote:
> > While perhaps inconsistent, I'd really rather it did #2. Here's the
> > basic argument... compare how often you dup a filehandle with how
> > often you read from one. Duping is swamped by several orders of
> > magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
> > $STDIN.next should still work normally.
>
> You know, I hear what you're saying, but it really makes the little hairs on
> my neck stand up. Just imaging trying to teach this:
>
>$a = $b;# assignment or readline?
Well, overloading and tying can already do things like this, but
that's a weak argument at best.
I dunno, I think its natural enough that it won't seem jaring. And
after the nth time of having to type "while($line = $file.next) {"
you'll be wishing for it. Maybe other people use $_ more than I do.
I rarely use it.
Of course, if overloading is implemented well, as I expect it to be,
there's no reason you couldn't just have a special filehandle class
that redefines the copy constructor.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
List context isn't dangerous. Misquoting Gibson is dangerous.
Apoc2 - Context and variables
First off, before I forget to mention it, nice job on Apoc2 Larry! You are the man. I know alot of us on p6l can seem like harsh critics at times, but it's only because we love Perl so much. ;-) Anyways, in addition to the $file.next stuff, I'm curious about a few clarifications on the new semantics of arrays and hashes. Overall it looks outstanding. I'm interested in what happens with interactions: $a = @b; Does this: 1. Get the length (doesn't seem to make sense now) 2. Pull a reference to @b (like Perl5's "$a = \@b") 3. Get the first element of @b Similarly, how about: %c = @d; Does this: 1. Create a hash w/ alternating keys/vals like Perl5 2. Do the equivalent of "%c = \@d" in Perl5 3. Or the mystery meat behind Door #3 Also, I like the *@b prototype slurping idea a lot, but I do worry about potential confusion with the @*b special class notation. I'm wondering if the latter can't be @::b? -Nate
Re: Apoc2 - Context and variables
> I'm interested in what happens with interactions:
>
>$a = @b;
>
> Does this:
>
>1. Get the length (doesn't seem to make sense now)
No. length(@b) or @b.length() for that.
>2. Pull a reference to @b (like Perl5's "$a = \@b")
Yep. Scalar context eval of arrays, hashes, and subs produces a reference.
>3. Get the first element of @b
No. That's still:
($a) = @b;
...which may well grab *only* the first element, because the lvalue's
structure determines the rvalue's eval context (just like a sub's
parameter list determines its argument's contexts)
> Similarly, how about:
>
>%c = @d;
>
> Does this:
>
>1. Create a hash w/ alternating keys/vals like Perl5
>2. Do the equivalent of "%c = \@d" in Perl5
>3. Or the mystery meat behind Door #3
This one's still less-than-certain. Definitely either 1 or 3 though.
If option 3, it would be the equivalent of the Perl 5:
%c = map {($_=>undef)} @d;
Damian
Re: Apoc2 - concerns
Nathan Wiger writes:
: > : This one. I see a filehandle in *boolean* context meaning "read to $_",
: > : just like the current "while ()" magic we all know and occasionally
: > : love. I'd expect $FOO.readln (or something less Pascalish) to do an
: > : explicit readline to a variable other than $_
: >
: > It would be $FOO.next, but yes, that's the basic idea. It's possible
: > that iterator variables should be more syntactically distinquished than
: > that. One could, I suppose, make up something about $
: > meaning the same thing thing as $FOO.next, for people who are homesick
: > for the angles, but I haven't thought that out, and don't even dare to
: > mention it here for fear someone will take it as a promise. Er, oops...
:
: So, just to clarify, the thought is:
:
:print while ($FOO);# like Perl 5
:$var = $FOO.next; # like Perl 5 $var = ;
:
: I assume that this is indicative of a more general iterator syntax, and
: subject to indirect objects?
:
:$FH = open "<$file" or die "Can't open $file: $!";
:$line = next $FH;
:
: If so, I can live with that.
Yes, that's the reason it's C, and not something more specific
like C, which isn't even true in Perl 5 when $/ is mungled.
We do have to worry about the C loop control function though.
It's possible that in
FOO: while (1) {
next FOO if /foo/;
...
}
the C label is actually being recognized as a pseudo-package
name! The loop could well be an object whose full name is C.
Or something like that. But maybe that's a gross hack. Seems a bit
odd to overload C like that. Maybe we need a different word.
Larry
Re: Apoc2 - Context and variables
>>$a = @b; >> >>2. Pull a reference to @b (like Perl5's "$a = \@b") > > Yep. Scalar context eval of arrays, hashes, and subs produces a reference. Perfect. >> Similarly, how about: >> >>%c = @d; >> >> Does this: >> >>1. Create a hash w/ alternating keys/vals like Perl5 >>2. Do the equivalent of "%c = \@d" in Perl5 >>3. Or the mystery meat behind Door #3 > > This one's still less-than-certain. Definitely either 1 or 3 though. The more I was thinking about it, it seems like #1 makes a good amount of sense. If you think about it, you're talking likes-to-likes. When you assign scalars, you're copying the single values. When you're copying list data structs, you're copying multiple values. %a = @b;# same as Perl 5 @c = %d;# same as Perl 5 $e = $f;# same as Perl 5 $g = @h;# Perl 5 $e = \@c The real trick is what to do with these: %a = (%b, %c); %d = (@e, @f); Or, horrors: %i = ($j, %k, @l); ($m, @n, $o) = (@p, $q, %r); Jeez, this is getting complicated. ;-) -Nate
Re: Apoc2 - concerns
> We do have to worry about the C loop control function though.
> It's possible that in
>
> FOO: while (1) {
> next FOO if /foo/;
> ...
> }
>
> the C label is actually being recognized as a pseudo-package
> name! The loop could well be an object whose full name is C.
> Or something like that. But maybe that's a gross hack. Seems a bit
> odd to overload C like that. Maybe we need a different word.
I don't want to get accused of too much bikeshed-painting :-), but seems
like "more" would work:
$line = more $FOO;
This also connotes generalized incrementing, so it serves that purpose too.
And, hey, there's "less" for decrementing too!
-Nate
Re: So, we need a code name...
> : also - why does it have to be tied to perl (in name) at all? > > Er, because we're writing it? > > : I like the idea > : that it would *not* be tied to perl, ie: it would be more generic if it was > : not named after it. > > Well, the fact that Tcl and Tk both start with T didn't stop people from > abstracting it away. I think that has little to do with the name, but with > how generally useful the platform is. true, but names are important, if for nothing but psychological reasons. For example, I think that the ruby/python/whatever folks would be more motivated to develop a version of their language under if the name of the underlying technology was language neutral > : How about 'prism' (ie: multiple languages from one underlying platform)? > > Do a search for "prism" on Yahoo and then come back with a serious > suggestion. There's even a "Prism programming language" out there. > (And yes, I did do a search for "perk" before I suggested it.) fair enough, but just to be clear I *did* do a search on prism. I just was too lazy to go past the 'category' matches (where there was no entry for a prism programming language). I suppose I should have been put off by the 235 entries though in the category page.. > New-age-techie words like "prism" are an attractive nuisance, and > should be avoided if we want people to find our stuff. hm. I suppose you wouldn't be into mangling the name (ex: prysm), or into something longer like 'palimpset'... or 'pisa' (which I'm beginning to like better).. Ed
Re: Apoc2 - Context and variables
On 5/4/01 11:09 PM, Nathan Wiger wrote: > The real trick is what to do with these: Note: stabbing wildly here... :) > %a = (%b, %c); %a = (stringify(\%b) => \%c); # Perl 5-ish %a = (%b.str => %c); # Perl 6 equiv. > %d = (@e, @f); %d = (stringify(\@e) => \@f); # Perl 5-ish %d = (@e.str => @f); # Perl 6 equiv. > Or, horrors: > > %i = ($j, %k, @l); %I = ($j => \%k, stringify(\@l) => undef); # Perl 5-ish %I = ($j.str => %k, @l.str => undef); # Perl 6 equiv. > ($m, @n, $o) = (@p, $q, %r); ($m, @n, $o) = (\@p, \@$q, \%r); # Perl 5-ish ($m, @n, $o) = (@p, $q, %r); # Perl 6 equiv. :) > Jeez, this is getting complicated. ;-) ...or maybe simpler? We'll see... :) -John
Re: Apoc2 - Context and variables
On Fri, May 04, 2001 at 11:23:12PM -0400, John Siracusa wrote:
> On 5/4/01 11:09 PM, Nathan Wiger wrote:
> > The real trick is what to do with these:
>
> Note: stabbing wildly here... :)
>
> > %a = (%b, %c);
>
> %a = (stringify(\%b) => \%c); # Perl 5-ish
> %a = (%b.str => %c); # Perl 6 equiv.
>
> > %d = (@e, @f);
>
> %d = (stringify(\@e) => \@f); # Perl 5-ish
> %d = (@e.str => @f); # Perl 6 equiv.
>
> > Or, horrors:
Horrors is right. The default perl5 behaviour is *useful*. I use the %b=(%a,%c)
metaphor all of the time.
Why not just keep it simple? And perl5-ish. Two contexts, scalar and list,
hashes NOT a context of its own. If
%a = @b;
does
%c = map{ ($_ => undef ) } @a;
then it both confuses things and gets rid of lots of regular expression tricks,
example:
%environment = (`env` =~ m"(.*?)=(.*)\n"sg);
Ed
Re: Apoc2 - Context and variables
On 5/4/01 11:47 PM, Edward Peschko wrote:
> Horrors is right. The default perl5 behaviour is *useful*. I use the
> %b=(%a,%c)
> metaphor all of the time.
I believe you can get the Perl 5 functionality by throwing a few *
characters in there somewhere...
> Why not just keep it simple?
Based on Apoc. 2, I'm not sure the Perl 6 isn't just as simple. It's just
different.
> And perl5-ish. Two contexts, scalar and list,
> hashes NOT a context of its own. If
>
> %a = @b;
>
> does
>
> %c = map{ ($_ => undef ) } @a;
>
> then it both confuses things and gets rid of lots of regular expression
> tricks,
> example:
>
> %environment = (`env` =~ m"(.*?)=(.*)\n"sg);
I may be misunderstanding pairlist vs. list context here, but I'd imagine
you could keep that type of functionality in Perl 6 with an explicit
keyword. Perhaps:
%environment = list (`env` =~ m"(.*?)=(.*)\n"sg); # Guessing
It seems to me that pairlist context will have enough benefits to outweigh
the extra care that must be taken to do Perl 5-ish stuff like the above.
-John
Re: Apoc2 - Context and variables
> Horrors is right. The default perl5 behaviour is *useful*. I use the %b=(%a,%c) > metaphor all of the time. > > Why not just keep it simple? And perl5-ish. Two contexts, scalar and list, > hashes NOT a context of its own. I agree. But what to do with: (%a, %b) = (%c, %d); Surely that shouldn't act too differently from: %a = (%c, %d); It seems either the list should be flattened or not. Maybe we need a new flattening operator. I don't think the proposed := by itself would do everything we need to do. Maybe we need a way to say "flatten these together". I'm going to throw out a new ":" op here: %a = (%b, %c); # same as %a = %b %a = (%b : %c);# flattened like Perl 5 (%a, %b) = (%c, %d); # kept separate (%a, %b) = (%c : %d); # %a slurps all of flattened %c and %d, # %b gets nothin' This allows you added functionality to flatten stuff as you see fit: (%a, %b) = (%c : %d, @e : @f); (@a, @b) = ($c : $d : $e : $f, @g : $f); Hmmm... I kinda like that... Am I missing anything? -Nate
Re: Apoc2 - Context and variables
On 5/5/01 12:06 AM, Nathan Wiger wrote: > Maybe we need a way to say "flatten these together". > I'm going to throw out a new ":" op here: [snip] > Hmmm... I kinda like that... Am I missing anything? Maybe the fact that Larry's already claimed the colon? :) -John
Apoc. 2 and . vs. ->
As a . doubter form the earlier threads, I'd just like to say that Apoc. 2 has gone a long way towards making me feel better about . as the method call thingie...both by explaining all the neat things . does in Perl 6, and by avoiding the potentially distressing introduction of the replacement string concatenation operator ;) -John
Re: Apoc2 - Context and variables
> Maybe we need a new flattening operator. I don't think the proposed := by > itself would do everything we need to do. Maybe we need a way to say > "flatten these together". I'm going to throw out a new ":" op here: > >%a = (%b, %c); # same as %a = %b >%a = (%b : %c);# flattened like Perl 5 >(%a, %b) = (%c, %d); # kept separate >(%a, %b) = (%c : %d); # %a slurps all of flattened %c and %d, > # %b gets nothin' > > This allows you added functionality to flatten stuff as you see fit: > >(%a, %b) = (%c : %d, @e : @f); >(@a, @b) = ($c : $d : $e : $f, @g : $f); > > Hmmm... I kinda like that... Am I missing anything? Of course, we could use the concatenation operator for this instead: (%a, %b) = (%c ~ %d, $d ~ $e); although to make an admittedly paintshed argument, ~ is placed in such a horrid position on the keyboard that it is really awkward to type... Ed
Re: Apoc2 - concerns
At 07:56 PM 5/4/2001 -0700, Larry Wall wrote: >Nathan Wiger writes: >: > : This one. I see a filehandle in *boolean* context meaning "read to $_", >: > : just like the current "while ()" magic we all know and occasionally >: > : love. I'd expect $FOO.readln (or something less Pascalish) to do an >: > : explicit readline to a variable other than $_ >: > >: > It would be $FOO.next, but yes, that's the basic idea. It's possible >: > that iterator variables should be more syntactically distinquished than >: > that. One could, I suppose, make up something about $ >: > meaning the same thing thing as $FOO.next, for people who are homesick >: > for the angles, but I haven't thought that out, and don't even dare to >: > mention it here for fear someone will take it as a promise. Er, oops... >: >: So, just to clarify, the thought is: >: >:print while ($FOO);# like Perl 5 >:$var = $FOO.next; # like Perl 5 $var = ; >: >: I assume that this is indicative of a more general iterator syntax, and >: subject to indirect objects? >: >:$FH = open "<$file" or die "Can't open $file: $!"; >:$line = next $FH; >: >: If so, I can live with that. > >Yes, that's the reason it's C, and not something more specific >like C, which isn't even true in Perl 5 when $/ is mungled. I dunno. Color me unconvinced--I do use the <> enough in non-while context (and in non-implied while context) to make the whole idea of next feel rather... nasty. And $FOO.next? Yuck. Reading lines/records in is one of the most fundamental things one can do in a computer language (especially perl) and having to jump through OO hoops to do simple things just feels like a step in the wrong direction. Conceptual elegance and orthogonality are nice enough, but we have enough of those languages. (If I wanted Eiffel, I know where to find it) Or is this a subtle ploy to make sure we ship with a working perl 5 parser? :-P Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apo2: \Q ambiguity
At 06:40 PM 5/4/2001 -0700, Larry Wall wrote: >Dan Sugalski writes: >: That's cool. I was just thinking it might not be a bad idea for us to >: set some equivalencies up in advance. If not, that's fine too. (I'll just >: slip them in while you're not looking... :) > >Hmm. Harks back to the colonial era: "I claim these brackets in the >name of Perl." Hmm. I guess the "We came in peace for all mankind" >approach only works when you're quite sure nobody else is gonna claim >it for themselves any time soon, which is much truer of the Moon than >of Unicode. We hope. I expect that's true, though in the context of the perl 6 parser it's not a huge deal--just because someone else claims it doesn't mean much, as it'll be claimed in a different parser module. Seems reasonable to make some claims for perl, though. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re[2]: Apoc2 - concerns
Dan Sugalski writes: > I dunno. Color me unconvinced--I do use the <> enough in non-while context > (and in non-implied while context) to make the whole idea of next feel > rather... nasty. And $FOO.next? Yuck. Reading lines/records in is one of > the most fundamental things one can do in a computer language (especially > perl) and having to jump through OO hoops to do simple things just feels > like a step in the wrong direction. Conceptual elegance and orthogonality > are nice enough, but we have enough of those languages. (If I wanted > Eiffel, I know where to find it) Amen. /acy
Re: Apoc2 - concerns
On Fri, May 04, 2001 at 07:56:39PM -0700, Larry Wall wrote: > Nathan Wiger writes: > : > : This one. I see a filehandle in *boolean* context meaning "read to $_", > : > : just like the current "while ()" magic we all know and occasionally > : > : love. I'd expect $FOO.readln (or something less Pascalish) to do an > : > : explicit readline to a variable other than $_ > : > > : > It would be $FOO.next, but yes, that's the basic idea. It's possible > : > that iterator variables should be more syntactically distinquished than > : > that. One could, I suppose, make up something about $ > : > meaning the same thing thing as $FOO.next, for people who are homesick > : > for the angles, but I haven't thought that out, and don't even dare to > : > mention it here for fear someone will take it as a promise. Er, oops... > : > : So, just to clarify, the thought is: > : > :print while ($FOO);# like Perl 5 > :$var = $FOO.next; # like Perl 5 $var = ; > : > : I assume that this is indicative of a more general iterator syntax, and > : subject to indirect objects? > : > :$FH = open "<$file" or die "Can't open $file: $!"; > :$line = next $FH; > : > : If so, I can live with that. > > Yes, that's the reason it's C, and not something more specific > like C, which isn't even true in Perl 5 when $/ is mungled. > > We do have to worry about the C loop control function though. I don't know. If it had to be written as $FH.next then there should be no ambiguity. Graham.
Re: Apoc2 - concerns
On Sat, May 05, 2001 at 02:46:46AM +0100, Michael G Schwern wrote:
> On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
> > I'm wondering what this will do?
> >
> >$thingy = $STDIN;
> >
> > This seems to have two possibilities:
> >
> >1. Make a copy of $STDIN
> >
> >2. Read a line from $STDIN
>
> While perhaps inconsistent, I'd really rather it did #2. Here's the
> basic argument... compare how often you dup a filehandle with how
> often you read from one. Duping is swamped by several orders of
> magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
> $STDIN.next should still work normally.
How would you pass a handle to a subroutine, or store it inside
a hash or array ?
sub my_read {
my $fh = shift; # whoops
}
I don't think it should do a dup(), but we do need to pass file handles around
Graham.
Re: Apoc2 - concerns
> >:$FH = open "<$file" or die "Can't open $file: $!"; > >:$line = next $FH; > >: > >: If so, I can live with that. > > > >Yes, that's the reason it's C, and not something more specific > >like C, which isn't even true in Perl 5 when $/ is mungled. > > I dunno. Color me unconvinced--I do use the <> enough in non-while context > (and in non-implied while context) to make the whole idea of next feel > rather... nasty. And $FOO.next? Yuck. You know, I was just thinking about this, and I agree with Dan. Actually, there's some big problems in trying to get rid of <> and make Perl do the "right thing" in boolean context (like the while loop example). Consider: $FH = open " a shortcut to the proposed new general-purpose-iterator concept? So: $line = $FOO.next;# yuck, I agree with Dan $line = next $FOO;# better... $line = <$FOO>; # aaah :-) print while ($FOO); # infinite, assuming $FOO defined print while ($FOO.next); # while reading the file print while (<$FOO>); # still my favorite Otherwise, it seems like there's a lot of Black Magic with calling next() automatically, and for something as fundamental as I/O that makes me really nervous. -Nate
Re: Larry's Apocalypse 1
In lists.projects.perl.language, you wrote: >It's likely to work better in Perl 6. To mean what it currently >means, you'll probably have to write something like: > >@foo[0] := ; > >The colon here is not functioning merely to make the assignment look >like Pascal. It means, in this case, the following operator is >intended to work on arrays, not scalars. Hence, :+ would be pairwise >array addition. Why a colon? It has no particular connection to arrays that I can see, and it will confuse people who know what := means in Pascal. An (ugly) alternative might be @= or @+ which at least have a connection to the @ sign in the array name and could be read as "array assignment" and "array addition". K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ Anyone who wants to can call themselves a pervert or a queer, but slut is a compliment you have to earn.
