Randal L. Schwartz writes:
| "Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes:
|
| Chaim It's the overloading of the ',' operator.
|
| Just like the overloading of the @ARRAY_NAME operator or the
| getpwuid() operator. Perhaps you are back to merely complaining about
| all
Damian Conway [EMAIL PROTECTED] writes:
Peter Scott [EMAIL PROTECTED] (I think -- Piers) writes:
Though a good post condition would benefit from some sort of
unconditional catch of return, I suppose. Perhaps allowing
continue on the outer sub block...
Argh, no! A good
On Wed, Aug 02, 2000 at 02:18:07PM +1000, Damian Conway wrote:
Though a good post condition would benefit from some sort of
unconditional catch of return, I suppose. Perhaps allowing
continue on the outer sub block...
Argh, no! A good postcondition is either invisible to the
On Tue, Aug 01, 2000 at 10:27:08PM +0300, Ariel Scolnicov wrote:
multimap operation list-of-lists # uurgh.
This made me think of something else that came up in a discussion with Larry
after the conference.
The discussion started off with the ability to do
for ($a,$b) (@list) { ... }
hi,
Why not some sort of functionality like LISP/Prolog i.e. working with lists.
("a",@x,"b",%y) - the list
head ("a",@x,"b",%y) # "a"
head(tile("a",@x,"b",%y)) #@x
head(head(tile("a",@x,"b",%y))) #$x[0]
head(tile(tile("a",@x,"b",%y))) #"b"
if you like it then "splice" etc...
Thus it was written in the epistle of Jeremy Howard,
J. David Blackstone said:
Prior to version 5, all implementations of Perl were designed with
only dynamic variables in mind. Perl5 provided lexical variables in a
backward compatible way. Perl6 should make lexical variables the
One argument *against* intra-token-sequence multiline comments is that they
are harder to see, and thus render readers of the code more prone to
misunderstand it. Is this worth really promoting?
The extant pod-based multiline comment solution does not suffer from this,
as it is quite easy to
John Porter wrote:
Michael Mathews wrote:
Using a two-character syntax to start and end a multiline comment seems to
be a good way to satisfy both the desired similarity to "#" and the desired
uniqueness to avoid collision with real single-line quotes. I would suggest
a (# many lines
Dan Sugalski [EMAIL PROTECTED] writes:
continuations, generators and co-routines.
Could someone point me to a reference on these, please? My CS text
collection's rather spotty and doesn't cover this stuff.
The Icon Programming Language
Ralph E. Griswold, Madge T. Griswold
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's namespace, but
probably save() or temp() would be better, or even savetemp() or tempsave()
or scopetemp().
How about deliver() or preserve()?
-Scott
--
Jonathan Scott
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS I think I'm missing the point. Why pull 'em out like that? Why not just put
DS the code in the body of the sub? Though a good post condition would benefit
DS from some sort of unconditional catch of return, I suppose. Perhaps
DS allowing
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's namespace, but
probably save() or temp() would be better, or even savetemp() or tempsave()
or scopetemp().
How about deliver() or preserve()?
I can slightly grok the
On Wed, Aug 02, 2000 at 09:15:38AM -0600, Tom Christiansen wrote:
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's namespace, but
probably save() or temp() would be better, or even savetemp() or tempsave()
or
"BCW" == Bryan C Warnock [EMAIL PROTECTED] writes:
BCW =head1 ABSTRACT
BCW Perl 6 should add a new pragma called Cimplicit.
BCW =head1 DESCRIPTION
BCW There should be an Cimplicit pragma that gives new life and meaning to
BCW void context constructs. In my case, I want it to print to the
Buddha Buck wrote:
The one concern I would raise about this is that a common use of
multi-line
comments is to dyke out code. As such, it is handy to have the start and
end markers different, and allow nesting
I see your point. At the risk getting too exotic how about:
#EOC;
some
comments
I believe that under the current proposal, any unqualified and
hitherto undeclared variables would be implicitly declared to be
lexicals in the current scope. This is to be contrasted with the
status quo, under which such variables are implicitly dynamics in
the current package.
I am not wholly
Since perl6 will/should have a new Configure methodology[1] there
could be a registry (hate that word) of all available function
calls[2], developed during the build processes. Then the core would be
able to infer a 'use' command.
chaim
[1] Where is the perl6-configure list? Did anyone request
"GB" == Graham Barr [EMAIL PROTECTED] writes:
GB On Tue, Aug 01, 2000 at 07:41:59PM -0700, Randal L. Schwartz wrote:
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes:
Chaim It's the overloading of the ',' operator.
Just like the overloading of the @ARRAY_NAME operator or the
getpwuid()
Scott wrote:
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's
namespace, but probably save() or temp() would be better,
or even savetemp() or tempsave() or scopetemp().
How about deliver() or preserve()?
How
On Wed, Aug 02, 2000 at 11:37:06AM -0400, Andy Dougherty wrote:
On Wed, 2 Aug 2000, Chaim Frenkel wrote:
If it is decided (and I hope not) that localtime and its kin are verboten,
it should not exists _at all_ in Perl6 and any existance at all would be
only as a support module for Perl5
How about contain() or detach() or revalue()?
I might just throw out that the operator "let" does the job in Lisp.
Also, how about renaming my() to local()? Will this be too confusing?
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
--
John Porter
On Wed, Aug 02, 2000 at 09:41:06AM -0600, Tom Christiansen wrote:
Well we should still have POSIX::localtime().
True, and hopefully in a more optimal form.
Were you planning on updating the Standard? :-)
Sure, everything is up for grabs right :)
Actually I meant the way the POSIX
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
I might suggest that one look to Python's use of locals() and
globals(). Currently, globals() is something like keys %{ __PACKAGE__
. "::"},
Tom Christiansen wrote:
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
Well, "var" is pretty short. And perhaps globals could be declared
with something like "var global". Extra
"RLS" == Randal L Schwartz [EMAIL PROTECTED] writes:
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes:
Chaim It's the overloading of the ',' operator.
RLS Just like the overloading of the @ARRAY_NAME operator or the
RLS getpwuid() operator. Perhaps you are back to merely complaining about
Graham Barr wrote:
But then went onto interators and something like
@list = interleave(@a,@b,@c);
which would interleave the lists given, and
foreach ($a,$b,$c) (interleave(@a,@b,@c))
sub interleave(\@;\@\@\@\@\@\@\@\@) {
my $m = -1;
for ( @_ ) { $m $#{$_}
At 10:30 AM 8/2/00 -0400, Michael Mathews wrote:
Okay, I'm impressed. 108 messages in my box this morning from the list.
Shows spunk.
But I'm concerned. Are you getting enough sleep?
Of course not. :)
Don't forget we've folks from England, North America, and Japan (that I
know of, and I only
On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote:
I used to be a C programmer myself (well OK, I was a C++ programmer...),
but I'd rather any day type "localtime-year" than "(localtime)[5]".
And what would you type instead of
(localtime)[3, 4, 5]
? localtime-(day, month,
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham You say "operator" and you are right. I think the issue is a sub
Graham can return either.
Really? How does a sub return "an array"?
(Unless you're about to mutter something about "lvalue subs" :) a sub
can return only an rvalue. An
"John" == John Porter [EMAIL PROTECTED] writes:
John Imho, this is A Bad Practice. Making it impossible would therefore
John be Good, existing-script-breakage not withstanding.
So you'll break $ARGV and @ARGV? Is that really OK?
And will you extend this to ensuring that scalars, arrays,
On Wed, Aug 02, 2000 at 09:42:09AM -0700, Randal L. Schwartz wrote:
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham You say "operator" and you are right. I think the issue is a sub
Graham can return either.
Really? How does a sub return "an array"?
There is a difference
sub
On Wed, Aug 02, 2000 at 10:43:37AM -0600, Tom Christiansen wrote:
sub mapf(;\@\@\@\@\@\@\@\@\@) {
Steal from lisp:
map
maap
maaap
mapp
mappp
maappp
dwim
:)
Graham.
Buddha Buck wrote:
The one concern I would raise about this is that a common use of multi-line
comments is to dyke out code. As such, it is handy to have the start and
end markers different, and allow nesting.
It nice to be able to bounce on % in vi, too:
=#{
comment
=#}
--
John
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham There is a difference
Graham sub abc { return (7,8,9) }
That's returning either a list or a comma operator result, depending
on context.
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning
Michael Mathews wrote:
At the risk getting too exotic how about:
#EOC;
some
comments
EOC
Just introduce a new function which is a bit bucket:
# works in perl5.
sub comment(@) { }
comment q{ comments... };
comment EOF;
comment
EOF
--
John Porter
Graham Barr [EMAIL PROTECTED] writes:
Well theres a difference there when you look at the op tree. That is a call
to a sub, whereas otherwise it is a op.
Isn't that an internals issue?
-- Johan
The existing pack and unpack methods are dependent upon a
simple yet complex 'format' structure, which is often
difficult to get right, and which carries no information
regarding the associated variable names.
I know what you mean, but it reads like "black yet
It nice to be able to bounce on % in vi, too:
=#{
comment
=#}
You easy to do this already:
=begin comment {
=end comment }
--tom
On Wed, 2 Aug 2000 12:29:41 -0400, John Porter [EMAIL PROTECTED] wrote:
H.Merijn Brand wrote:
If I could, I would VETO!
If I could, I would mandate this change. This is definitely in my
Top 10 List of Perl 5 Suckinesses.
So here we differ. That's what discussions are for.
This
Tom Christiansen wrote:
sub mapf(;\@\@\@\@\@\@\@\@\@) {
Steal from lisp:
map
maap
maaap
mapp
mappp
maappp
...
Should be feasible with an AUTOLOAD that takes a certain kind of regular
expression...
sub AUTOLOAD /^ma+p+$/ {
}
Some for the 'car' and
At 11:57 AM 8/2/00 -0400, John Porter wrote:
Tom Christiansen wrote:
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
Well, "var" is pretty short. And perhaps globals could be
On Wed, 2 Aug 2000 12:51:10 -0400, John Porter wrote:
At the risk getting too exotic how about:
#EOC;
some
comments
EOC
Just introduce a new function which is a bit bucket:
# works in perl5.
sub comment(@) { }
comment q{ comments... };
"Function"? Who needs a function?
Bart Lateur wrote:
END_OF_COMMENT;
This is comment!
And more...
END_OF_COMMENT
Apart from the warning "Useless use of a constant in void context", it
works.
Yes; but it was precisely that warning which I was intending to address.
Perhaps a better way would be a change in the semantics
Edwin,
This writeup certainly is a great first draft for this RFC. I'll have to track down
those references.
I was surprised by the read/write operations, but have no objection to them.
New/get/set and the individual data member access functions are the critical pieces,
as the I/O could be
Whoa! I'm far from convinced that I have a strong enough CS background
to understand half of what'll go on on this list. I've already
indicated on-list that I'd rather leave this position for someone else,
if there is someone else.
My $.02 worth ...
It's been my experience that the
"Randal L. Schwartz" wrote:
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning a copy of the contents
of @a in a list context, and the number of elements of @a in a scalar
context, using the "@a" operator. You still haven't "returned the
Peter Scott wrote:
At 02:53 PM 8/2/00 -0400, John Porter wrote:
Perhaps a better way would be a change in the semantics of scalar
literals in void context, to be silently ignored.
No! It's a major typo/bug-catcher.
Strange, my experience does not confirm that one whit.
--
John Porter
Brust, Corwin wrote:
messages.rfc - An RFC to discussing the wisdom of allowing run time error
and warning messages to be modified at run time
...
I want perl's error (and warning) messages to be specific to each program I
write.
Isn't this covered by locales?
--
John Porter
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Please explain what the utility of having unshared variables? I might
as well just fork().
TC The only sane situation is to have safety by default. Things should not
TC be shared unless you say they are.
Err, I understood his comment to
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
On Tue, 1 Aug 2000 23:43:24 -0500, Jonathan Scott Duff [EMAIL PROTECTED]
wrote:
(I, for one, support renaming local() to Something Better (if only I
know what that was))
Anything one chooses potentially conflicts with
Tad McClellan wrote:
or saveval()# indicates it is about _values_
tempval()
or myval() # my _value_, not my(variable)
or even pushpop() # maybe not :-)
pushval()
--
John Porter
http://msdn.microsoft.com/library/default.asp?URL=/library/prelim/csref/vcor
iCReference.htm
On Wed, Aug 02, 2000 at 03:34:56PM -0400, John Porter wrote:
Brust, Corwin wrote:
I want perl's error (and warning) messages to be specific to each program I
write.
Isn't this covered by locales?
Completely different beast. I don't claim to fully understand locales,
but that's not
Hey, this RFC stuff is fun!
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink [EMAIL PROTECTED] for now
Date: 2 Aug 2000
Version: 0 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
"VARIABLE used only once: possible typo"
Simon Cozens [EMAIL PROTECTED] writes:
On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
better, but I do mind making it optional.
If we're going to do line disciplines, we need a built-in stdio
On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote:
=head1 TITLE
Filehandles should use C* as a type prefix if typeglobs are eliminated.
I could go for this, given the `if typeglobs are eliminated' caveat.
Thus it was written in the epistle of Tom Christiansen,
Hearing no outright derision in response to my trial balloon, here it is as
an RFC:
=head1 TITLE
Filehandles should use C* as a type prefix if typeglobs are eliminated.
Nope. A filehandle is a singular whatzitz. It thus
Thus it was written in the epistle of Michael Mathews,
Ted Ashton wrote:
The qc()
proposal fits in well with the Perl "look-and-feel" and seems pretty
comfortable to me. If there are concerns about obfuscatory potential, a
use strict 'comments' could require that the qc( opening start
Graham Barr wrote:
The upcoming Python (v2.0) introduces a builtin called zip() that does
the same thing:
for a,b,c in zip(aa,bb,cc):
...
There are also question on how long the resulting list should be if
@a, @b, @c is not of the same length. I think zip() was defined
Ted Ashton wrote:
2) Also this proposition fails in one of my goals, which was to allow
arbitrary nesting of multiline comments. I believe this would be true for
any function based solution.
Negative. If you use paired delimiters you're ok.
qc( Here's a quick comment which actually
Glenn Linderman wrote:
$foo = $a + $b # can this be an in-line comment? # + $c * $d;
Note that with this scheme it would be possible to allow in-line comments
to be
multi-line comments, or possible to prevent that. I'd vote in favor of
keeping
in-line comments on a single line.
Note
Ted Ashton wrote:
Thus it was written in the epistle of Tom Christiansen,
Nope. A filehandle is a singular whatzitz. It thus mandatory takes
the singular prefix; to wit, $. What's next? Integer and float and
complex and string and char and bits prefixes?
(Weighing in with the
Glenn Linderman wrote:
qc( Here's a quick comment which actually contains
qc( another comment )
within it
);
This type of comment will not comment out arbitrary text.
In particular, it might have problems with text containing
mismatched (){}.
This is already an issue
The warning message "use of uninitialized value" should also
disappear, to be replaced with "use of undefined value", and the
warning for the purpose described in this RFC should be "use of
uninitialized variable C$x".
What about if there's only an expr, not a variable?
For example:
print
Wanted to get this out as an idea that could encompass lots of the
concerns I'm seeing about warnings and such:
=head1 TITLE
Warnings and Tainting should be reimplemented as pragmas.
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 2 Aug 2000
Version: 1.0
Mailing-List:
Michael Mathews wrote:
So this should work in Perl 6
code here;
#
# this is a single line comment
$foo = $a + $b # here's an in-line comment # + $c * $d;
#
more code here;
If starting in column 1 is going to be magic, you may as well
make the magic char #, so:
#
# this is
This seems like an acceptable variation on what has been suggested so far. I
deally one would be able to safely block comment any large section of a Perl
6 script and not worry about any other block comments within (the outermost
block comment takes precedence).
I still like this solution
What is wrong with
if (0) {
}
1) what if the block contains syntax errors?
2) what if the bloack contains unmatched braces?
3) this is not easier to type or remember than the currently available
workarounds.
What is wrong with
if (0) {
}
(and of course teaching op builder not to build them in this case).
Funny, I was going to mention that I always use
#if 0
...
#endif
in C for nesting, block comments. Which is rare anyway, rarer perhaps
than this discussion would seem to merit.
As in - maybe it's time for...
-Corwin
Corwin Brust Software Engineer
Alliance Data Systems
formerly Harmonic Systems, Inc.
701 Fourth Ave South, Suite-1600
Minneapolis, Minnesota 55415
Office (612) 672-3584
Mobil(612) 239-8073
Email[EMAIL PROTECTED]
Thus it was written in the epistle of Jon Ericson,
Ted Ashton wrote:
Thus it was written in the epistle of Tom Christiansen,
Nope. A filehandle is a singular whatzitz. It thus mandatory takes
the singular prefix; to wit, $. What's next? Integer and float and
complex and string and
Proposal: here-docs specified with regexes, and no special
meaning for newlines.
comment /EOC/; this is an arbitrary comment. EOC
Smack--the lexer cowers before you!
--tom
Tom Christiansen wrote:
comment /EOC/; this is an arbitrary comment. EOC
Smack--the lexer cowers before you!
Well, hey, while we're daydreaming... :-)
--
John Porter
Chaim Frenkel [EMAIL PROTECTED] writes:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote:
We may need that all variables are by default lexical.
Without the explicit declaration of cross-thread visible variables, doing
threading may well be
At 11:30 AM 8/2/00 -0400, Chaim Frenkel wrote:
Since perl6 will/should have a new Configure methodology[1] there
could be a registry (hate that word) of all available function
calls[2], developed during the build processes. Then the core would be
able to infer a 'use' command.
Yes. What I'd like
Hi Tom,
Of course you should consider that the programmer may be block commenting a
section of code precisely because it does contain sytax errors. I often do
so as a way of isolating hard to track bugs. I can't imagine how getting
more courteous error messages would be a Good Thing!
Lets face
Warnings and Tainting should be reimplemented as pragmas.
What part of warnings(3) and perllexwarn(1) are you in disagreement with?
Not yet fully-versed on everything having todo with 5.6, appears I made
a bit of an oversight (i.e., as you mention 'use warnings' is already in
5.6)! So while
I'm interested in how OO Perl 6 will be.
It's very hard to develop big project in a language without OO support,
so I think OO should be a very important part of Perl6.
Currently alot of languages support OO very well, e.g.
C++/Java/Python/JavaScript.
I know that Perl6 will support OO in kernel,
In message [EMAIL PROTECTED]
Gisle Aas [EMAIL PROTECTED] wrote:
The upcoming Python (v2.0) introduces a builtin called zip() that does
the same thing:
for a,b,c in zip(aa,bb,cc):
...
There are also question on how long the resulting list should be if
@a, @b, @c is not
On Wed, Aug 02, 2000 at 03:00:04PM -0400, Michael Mathews wrote:
Ted Ashton wrote:
The qc()
proposal fits in well with the Perl "look-and-feel" and seems pretty
comfortable to me. If there are concerns about obfuscatory potential, a
use strict 'comments' could require that the qc(
The way I see it Santa (aka Larry) has asked for our wish list. This is not
the time to dwell on all the ways we can make due with our old toys.
I still think saying :10,20s/^/##XXX## / is the cleanest and most
visually apparent block comment.
PS I'm all for a new list. How do I get one?
I see
Tom Christiansen wrote:
The warning message "use of uninitialized value" should also
disappear, to be replaced with "use of undefined value", and the
warning for the purpose described in this RFC should be "use of
uninitialized variable C$x".
What about if there's only an expr, not a
. You misunderstand; I am *not* addressing the
perennial complaint that the "use of uninitialized value" doesn't
identify the source of the undefined value.
Ok.
"symbol $main::x used only once" - "use of uninitialized variable
$main::x"
"use of uninitialized value" - "use of undefined value"
Updated RFC.
---
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink [EMAIL PROTECTED] for now
Date: 2 Aug 2000
Version: 0.2 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
"VARIABLE used only once:
Tom Christiansen wrote:
"symbol $main::x used only once" - "use of uninitialized variable
$main::x"
"use of uninitialized value" - "use of undefined value"
Perhaps then
"use of uninitialized value" - "use of undef as discrete value"
or
"use of uninitialized value" - "discrete
On Wed, Aug 02, 2000 at 12:22:10PM -0400, John Porter wrote:
sub interleave(\@;\@\@\@\@\@\@\@\@) {
...
}
sub mapf(;\@\@\@\@\@\@\@\@\@) {
...
}
I guess my question is, why do these need to be builtins?
sub push (\@@) { @{$_[0]} = (@{$_[0]}, @_[1..@_]); }
--
Addi Just imagine we
I thought that that was just the plan.
Form sub lists to collect ideas that needed hashing, if that hashing got
involved make sub-lists to reach consensus on those.
You have a nice thread handeling mail client, don-ch tom?
-Corwin
-Original Message-
From: Tom Christiansen
On Wed, Aug 02, 2000 at 01:48:36PM -0600, Tom Christiansen wrote:
Isn't this covered by locales?
Unicode and locales are immiscible.
In Perl 5. This is *by no means* a general statement.
ICU is, for instance, a Unicode locale library.
--
Gosh that takes me back... or is it forward? That's
No: lists are the plural whatzitzes, containing zero or more singular
whatzitzes. They are ordered. Arrays hold lists.
I tend to agree with Tom's argument here. open() is kind of funny
anyways. Why couldn't it work like this, similar to FileHandle:
$fh = open $filename;
print $fh
wei ye wrote:
I'm interested in how OO Perl 6 will be.
It's very hard to develop big project in a language without OO support,
so I think OO should be a very important part of Perl6.
Perl 5 supports OO quite well. Read the docs by typing 'perldoc section'
where section is one of:
On Wed, Aug 02, 2000 at 04:32:40PM +0100, Andy Wardley wrote:
This would permit the rationalisation and simplification of the syntax
required to access individual elements or slices of arrays and hash arrays,
while remaining backwardly compatible with Perl5 syntax.
This is the rationale?
On Wed, Aug 02, 2000 at 05:31:06PM -0400, Ted Ashton wrote:
But that, precisely, was my point: Arrays *and* hashes.
Scalars, hashes, arrays. There's actually more than one type of plural here,
gramatically:
scalars hashes arrays
singulardualplural
(Or am I the only one
"Randal L. Schwartz" wrote:
"Martyn" == Martyn Pearce [EMAIL PROTECTED] writes:
Martyn Possibly, although I must ask: since everything is up-for-grabs, I ask
Martyn (without implying any feeling one-way-or-tother):
Martyn How useful is the , operator in it's C-style statement separator,
"Steve" == Steve Fink [EMAIL PROTECTED] writes:
Steve We could add a 'then' keyword.
We have one. It's called "comma in a scalar context". :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Scalars, hashes, arrays. There's actually more than one type of plural here,
gramatically:
scalars hashes arrays
singulardualplural
(Or am I the only one left who did Ancient Greek? :)
Nope: pudge and larry, at least.
(and don't say, "because plural *means* more than
Thus it was written in the epistle of Tom Christiansen,
What about regexes?
$foo = qr/blech/;
Should that be /foo instead? :-)
Notice how even objects use $, not something else.
*chuckle* Ok, point conceded.
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist
If the prefix-less form of filehandles was absent from Perl 6, I would be
far less enthusiastic about my RFC. I agree; they're a kind of scalar.
(Just occurred to me that one could view the % prefix of hashes as denoting
a key-value pair by virtue of looking like two o's separated by a
Nathan Wiger writes:
: Is there any interest to do this in the community with tainting? Adding
: a 'use tainting' to Perl 6 (or 5.7, for that matter)?
Unfortunately, tainting is a data-flow/data-typing concept, and when
you try to implement data-flow/data-typing concepts with lexical
scopes, you
On Wed, Aug 02, 2000 at 02:51:20PM -0400, John Porter wrote:
Peter Scott wrote:
Filehandles should use C* as a type prefix if typeglobs are eliminated.
I missed previous discussion of this (if there was any),
but it's an idea I've already thought about.
It has my vote, fwiw.
I have to say
Peter Scott writes:
: If the prefix-less form of filehandles was absent from Perl 6, I would be
: far less enthusiastic about my RFC. I agree; they're a kind of scalar.
In fact, they're a kind of object.
: (Just occurred to me that one could view the % prefix of hashes as denoting
: a
1 - 100 of 158 matches
Mail list logo
