I was asked to repost this here. I didn't realize perl6-language was up
yet. My bad, sorry. :-)
-Nate
Original Message
Subject: Re: perl 6 requirements
Date: Mon, 31 Jul 2000 19:57:42 -0700
From: Nathan Wiger <[EMAIL PROTECTED]>
To: Chaim Frenkel <[EMAIL PROTECTE
I can't find the full original thread, but somewhere it was suggested
that $^O be removed because it's the same as $OSNAME. Again, I'm against
this, I use it all the time.
However, this got me thinking. Here is an idea I'd like to see: The
existence of a $^T variable for controlling tainting in t
Ariel Scolnicov wrote:
>
> Unfortunately, this would mean your example above doesn't quite work.
> One possibility is to say that $^T controls taint *checking*, but not
> tainting itself[1]!
This is actually a good distinction that's worth some more discussion.
One could set the implementation s
> I'd rather not have multiple characters. A option hash or even a longer
> namespace would be more readable.
>
> $Perl::Warnings{undef} = 1;
> $Perl::Tainting = 1;
I would argue that's what "use English" is for. Personally, I like the
shortcut of $^W et al.
-Nate
Alan Burlison wrote:
>
> Steve Simmons wrote:
>
> > I'd prefer that we break these vars out into a set of hashes with
> > appropriate names:
> >
> > $PERL_CORE{warnings} vs $^W
> > $PERL_CORE{version} vs $^V
> > $PERL_FORMATS{name} vs $^
> > $P
> C is, at times, less than logical. Witness the localtime fun: some of it's
> zero-based, some of it's one-based, and some of it's -1900-based. All from the
> same function. The localtime concept is needed, the localtime brain damage is
> really not.
I agree completely. I take issue with changin
> > I disagree with keeping the same name as a Unix function, but having a
> > radically different calling sequence or return value. If you want a
> > new interface, *name* a new interface.
>
> Amen!
Agreed, completely. I posted a follow-up under "Re: date interface" that
some might be interest
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-
> >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 wh
> 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 "so
> Reimplement Warnings and Tainting as Pragmas
> Nathan Wiger <[EMAIL PROTECTED]>
You can delete this one. 'use warnings' is already in 5.6 (sorry!) and
tainting looks near-impossible (thanks Larry for the insight!). I might
(after tons of research) resubmit some
ce is safe). Depending on how open() and filehandles are implemented
in Perl6, this might be a useful thing ($fh->untaint ?).
-Nate
Larry Wall wrote:
>
> Nathan Wiger writes:
> : Is there any interest to do this in the community with tainting? Adding
> : a 'use tainting'
> Um, what stops open returning undef on failure (and setting $!), so I could do
>
> $fh = open $filename or die "open $filename failed: $!\n";
Exactly. You don't lose anything because open() will still return "true"
(a handle) or "false" (undef).
-Nate
Tom Christiansen wrote:
>
> >Except that you can test for failure by checking to see if $fh is defined.
>
> Let your true be true and your false be false.
>
> open($fh, "<", $filename) || die;
>
> --tom
Not sure I agree with that. I think one point of confusion / perceived
difference betw
Tom Christiansen wrote:
>
> >Not sure I agree with that. I think one point of confusion / perceived
> >difference between filehandles, open(), and basically every other
> >builtin is that all the others *return* what you want.
>
> tie and bless and chop and chomp also all act upon their argumen
> Yes, but then each of those has to be explained specially. People
> *expect* assignment to "autovivify", as it were. But open() et al
> are essentially a 3rd syntax for constructors, and that's about one
> syntax too many, give or take a few.
I agree with this. I think of open() a lot more li
=head1 TITLE
Modify open() and opendir() to return filehandle objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Version: 1.0
Mailing-List: perl6-language
=head1 ABSTRACT
Currently, open() and opendir() are given handle arguments, whose values
are tw
Please don't reply to this one or threadlists will be screwed up! Reply
to the second (auto-generated) one later in the perl6-language mailbox.
(Hit the button a second before Nat's email! Oh, well...)
Nathan Wiger wrote:
>
> =head1 TITLE
>
> Modify open() and opendir(
Job Description
Perl 6 Language Individual Contributor
Nathan Wiger <[EMAIL PROTECTED]>
The goal of my position is not to really do any one thing, but rather to
try and contribute ideas and, when possible, actual code across a broad
range of topics. This includes writing RFCs, leading disc
Tom Christiansen wrote:
>
> >On Thu, Aug 03, 2000 at 06:40:30AM -0600, Tom Christiansen wrote:
> >> >Modify open() and opendir() to return filehandle objects
> >>
> >> Here are some things that that will be a problem for:
>
> >I did not see any that would be a problem.
>
> It's not as convenien
> I have retained the title of "Lexical variables made default,"
> because I still feel that that is the primary purpose of this change
First off, I think this is a great idea in principle. However, I don't
think it goes nearly far enough in the implementation. I'd like to
propose something rad
> sysopen() should probably be included in the list as well.
Good point.
-Nate
> What lexical scope should $x be _implicitly_ declared in? Maybe, just
> maybe, we need a my $x at the top to tell us it is outside the scope of the
> first reference. Otherwise we get three different lexical variables, and an
> undefined value warning at run time.
You're right, great point. T
> Are you saying they don't look Perlish now?
>
> And no, all you guys, I'm not trying to shoot down a monadic,
> object-returning open. Please don't assume that.
As funny as it sounds, yes. Mind you, they're not really too weird. But
compared to how most other functions have turned out working
> In fact, you may as well go the whole way and say that all IO is done via
> optimised IO objects (ie include sockets etc). IO::File and friends
> without the overhead. All of the current open functions simply pass these
> objects around.
I'll stick this in there, definitely. This is just what I
> if (want 'hash') { return %hash } # rather than eq
I like this alot.
-Nate
> I'd've written that more like
>
> $data_axed = chop($var);
> $charcount = chomp($var);
>
> Or something. People really do find those two functions confusing.
> Is this something we'd like to address by having versions that don't
> take LVALUES?
I don't know. It is true that this is s
> The suggestion was the open() return a filehandle object, so may
> I suggest
>
>$fh = open("| cat -v | sort | lpr") or die ;
>$pid = $fh->pid;
I like. I'll add it.
Version 2's gonna be *huge*...
-Nate
> I think I'd prefer that ->pid return 0 only to the child of a fork,
> but undef on a handle that were not the product of a fork, irrespective
> of direction.
Great analysis. I think this sounds like an excellent idea.
> Some related issues:
>
> 1) Did Larry or did he not mention somethin
> Fair enough. If we were going to do it I would like to see it extend to:
>
> sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
>
> }
Is there an RFC for this yet? If not, I think there needs to be. I think
this would be really cool.
Because it has opportunity for bloat, I would suggest i
> You've taken the wrong approach. If you're writing a big program then
> there should be *no* default scope. Any variable access is an error
> unless that variable was my()ed or our()ed. That's basically what
> 'strict' gives us.
Fair enough. I've heard several good analyses against my idea,
> =head1 TITLE
>
> Keep default Perl free of constraints such as warnings and strict.
I second this. If the current definition of "lexical" remains unchanged
(which I strongly suspect it will), I think Perl should remain loosely
typed by default. Make people add
use strict;
use warnings;
> Besides, named arguments will solve this (in fewer chars even :-)...
>
>$user = 'nwiger';
>sub whois ($user) {
># ...
>}
>
> Damian
Great point. I'll "settle" for that (it's what I'm looking for anyways).
:-)
So will these be "automatically-my()ed"? Or wil
> Nathan Wiger wrote:
> > Because it has opportunity for bloat, I would suggest it should be in a
> > pragma:
> >
> >use strict 'prototypes';
>
> Bloat? What bloat? I don't want to *bloat* all my programs by sticking
> a zillion pragmas in
> 1. put their hands up to write the "up for grabs" RFCs
I'll grab:
unlink() renamed
I believe the "Renaming line noise" one is already covered in RFC 17.
The localtime() one's still coming, I promise! It'll be good (I hope),
lots of great input.
> I'm *very* close to suggesting a "strict"
> Another note: your examples with:
>
> local ($^T) = 0;
> $ENV{PATH} = read_config_file();
> local ($^T) = 1;
>
> is only using local() to confuse; it should be written with a block,
> correctly restoring the old value of $^T.
Sorry about that - I contemplated taking it
> Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
I don't like giving up low-level control either, but imagine something
like this:
$port = shift || 2345
> IME, I find it more dangerous to do behind-the-scenes hand holding than
> to simply teach them the hows and whys of the "right way."
Exactly.
> The key word above is "encourage". You're not really encouraging
> anything - you're now having the language mandate particular constructs,
> withou
Tom Christiansen wrote:
>
> >> Thats just because IO::Socket is done wrong
>
> >Maybe we should address this? If we're keeping syscalls just because a
> >possible replacement module is just written wrong, we should fix this.
>
> Why would we ever remove a syscall!?!?
Sorry, wrong verbage. I me
Johan Vromans wrote:
>
> What would be the semantics if 'my' were left out? Would it be
> equivalent to:
>
> sub whois ($) {
> local($user) = @_;
> }
No. I'd say it should inherit the default global scope. This is
*consistent* within Perl. Here's the choices as I see it:
1.
Suggestion: Can we manually renumber this "RFC 0"? This should be the
first one at the top of the list, not buried somewhere within. my($.02).
-Nate
Perl6 RFC Librarian wrote:
>
> This and other RFCs are available on the web at
> http://tmtowtdi.perl.org/rfc/
>
> =head1 TITLE
>
> Perl shoul
> I say this as a Unix weenie, albeit a Unix *user* rather than a Unix
> *programmer*. I'm quite used to navigating the Unix filesystem but,
> having never braved Unix systems programming, had no conceptual link
> between deleting/"rm"ing files, and the term "unlink". It tooks me
> quite a bit o
Sorry for the broadcast, but anyone else having problems with perl6-rfc?
I sent two separate RFC's in from separate mail servers but haven't seen
anything happen with them. It's been a good hour, too.
Thanks,
Nate
Ignore this, I'm an idiot. I thought perl6-rfc was totally automated.
Sorry.
-Nate
Nathan Wiger wrote:
>
> Sorry for the broadcast, but anyone else having problems with perl6-rfc?
> I sent two separate RFC's in from separate mail servers but haven't seen
> anything
> I would plea for autosubscribing perl6-language list members to every
> sublist that gets spawned. The reason is continuity.
Yes, I strongly agree with this! Especially since I'm subscribed from
two different addresses and now chair two lists. I really like it if the
discussion wouldn't start w
Personally, I don't think I've ever used any of these, but I really
don't want to speak for everyone.
Maybe an RFC "Functions and Variables to Remove in Perl 6" ?
-Nate
Jonathan Scott Duff wrote:
>
> Here in my pre-caffiene morning trance it occurs to me that a few of
> the "fringe" features o
I think this is a good candidate for recording why we decided not to do
something.
Did we even reach consensus on how to do this? Put a Status: header in
VERSION?
For recording purposes, maybe once the Status: line is added we should
add an additional section. Maybe STATUS, JUSTIFICATION, POSTMO
> If $object is typed (my Date $object), then want() will be able to detect the
> difference.
I actually just put in an additional RFC on this as well. Check it out
for more details when it comes out.
Basically, as I said in the date() RFC, we'll be able to work this out
somehow, I'm sure.
-Nat
> > The C<$time> specifier can be followed by a C<$timezone> argument,
> s/<$time>/<$format>/
Ooops! Thanks. :-)
> Allow numeric (e.g. minutes? seconds?) displacement?
> This would also allow
>
> $tomorrow = date(undef,undef,24*60*60);
Good call. The function could use a string as a timezon
> shadow $/ = "\n";
>
> seems to have the right implications to me.
Personally, I like this by far out of all the suggestions I've heard.
"save" seems to say "save THIS value" (the one you're setting, not the
global one you can't see). "hide" is a little too general (hide what in
what?). But
> Returning an object is the most generally useful. Converting it to a
> string on the fly when you need a string, works best for me.
That's exactly what my RFC says. :-)
-Nate
> Yes! Yes!
>
> How about using a float (fractional second) instead of $msec, $nsec.
Works for me (it's for you anyways). ;-)
-Nate
> I don't see in here how an object tells the difference between being in
> scalar context and being in string context.
Think tie(). It wouldn't necessarily be the object that makes the
decision.
> for anything that wants to take such a relatively odd action.
As Spider notes, this isn't really
> Larry's commented (in p5p) on his own experience in trying to
> have properly "stringified" objects. He wound up with a bunc of
> classes doing exactly what you suggest, which is using the
> existing overload mechanism *for just that one operation*. He
> speculated then that this particular on
> The error was not here but in:
>
>__ < 2 + __ * atan($pi/__) or die __
>
> That should of course have been:
>
>__ < 2 + __ * atan2($pi, __) or die __
Can I make one observation? Maybe I'm the only one.
I find the __ *really* hard to follow. I've been trying to keep up with
this disc
> Just as simply,
>
> - $foo is the variable 'foo'
> - ^foo is the placeholder 'foo'
> - $_ is the default variable
> - ^_ is the default placeholder
Yeah, I personally can read this much clearer. Peter also mentions that
__ is hard to distinguish from _, unless they're right next to each
other,
> I'm ashamed that this feature would mess with my (bad?) habit of
> re-writing "$pw" to just $pw on the assumption that whoever wrote
> it didn't know what the hell he was doing. Would anybody else be
> caught like that?
I'm not sure it would. I think if we did it right all of these could
potent
> Or just STRING. It's a verb to, you know ;-)
Yeah, I think this is best. SCALAR isn't real accurate anyways. I'll
change it in v2.
-Nate
> What about C ?
Here's yet another one - how about "here"?
{
here $/ = "\n"; # what it is in here
}
Not really any confusion on this - $/ is "\n" 'in here', but maybe
something else outside.
Unlike "hide" or others, this doesn't connote it's necessarily any
different from somew
> $zot **= ^foo# "what's that binary op doing there..
> # ..oh, that's a placeholder"
I think this is a valid way of looking at it. If you think about it, *
for typeglobs is the same symbol as * for multiplication. But the parser
can figure it out based on context. I don't se
> >{
> > here $/ = "\n"; # what it is in here
> >}
>
> But it isn't "here" that's the problem. If we just wanted to change
> the value "here", we could use my(). The problem is that local()
> changes the value for somewhere else as well as here. Other names
> suggested (like "sh
> There's two potential solutions here:
> 1- Use '_'
> 2- Use '^', but increase the strictness of sub calls
>
> I'd be happy with both. I'm with Damian that '__' looks cool, but I
> understand that people typing in perl from a magazine (do people still do
> that?) might get confused (mmm... comfy
> > There's two potential solutions here:
> > 1- Use '_'
> > 2- Use '^', but increase the strictness of sub calls
>
> > The second suggestion specifically relies on us deciding that barewords are
> > always evil, so that :
> > $a = foo; # Error! Evil bareword! Return to firey depths of hell!
> Probably not with tie, but with function calls in general, sure. We can do
> some flow control analysis on the subs and propagate it outwards so we
> might know, for example, that:
>
>sub foo {
> my (@vars) = @_;
> return scalar @vars;
>}
>
> doesn't change its args or any gl
ainting via the $^T variable
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 31 July 2000
Version: 1
Mailing List: perl6-internals
Number: 1
=head1 Abstract
Currently, Perl requires that tainting be invoked along with the Perl
interpreter, via the -T switch. It would be n
> I like this, but I'd like to see this, inter-thread queues, and events all
> use the same communication method. Overload filehandles to pass events
> around instead, so:
>
>my $thing = <$handle>;
>
> could read a record from a file, or get an event from the event queue, or
> receive some d
> > But it isn't "here" that's the problem. If we just wanted to change
> > the value "here", we could use my(). The problem is that local()
> > changes the value for somewhere else as well as here.
>
> Well, as has been pointed out, special^Wlocalized variables are
> scoped in time, not space,
> With the proliferation of special subroutine names (BEGIN, END, INIT,
> CHECK, etc.) the all capital subroutine names available to the
> programmer has steadily shrunk. Rather than stealing subroutines from
> the programmer, we should create a space just for Perl.
>
> sub *BEGIN {
>
> If you're going to use a convention, rather than a syntax, then the current
> convention of all CAPS reserved to Perl is easier to understand, more
> pleasing to the eye, and backwards compatible.
Good point. Maybe we're getting a little "fix-happy". :-)
-Nate
> > As for the "need a verb" argument, my() and our() aren't verbs either.
>
> They're also lexical rather than dynamic. Dynamic things need action
> words (verbs) IMHO.
A valid distinction. Though, "now" has an action-like ring to it, even
though it's not truly a verb. "NOW this var is this v
> > > Also, I would vote for a method to return the Julian date (yes I am an
> > > astronomer...) :-)
>
> But surely not as a part of the core language?
Exactly. In fact, I'm going to chop a lot of the original proposal out.
It's too bloated for core.
There's a lot of cool time/date stuff, but
> So is this a consensus?:
>
> It is proposed that Perl introduce a new prefix '^', which indicates a
> placeholder. This can be used in any of the following ways:
> - ^identifier: named placeholder
> - ^_: anonymous placeholder
> - ^0, ^1, ...: positional placeholder.
I think this sounds go
> I'd agree to the contrapositive: if we have named placeholders, I don't see the
> need for positional ones too. But I'm willing to be convinced. The below, with
> positional only, is total gibberish, as Ken points out.
To most, probably, but I say let the user decide. Like Jeremy points
out:
> I am intrigued by the idea of a "scalar" context, and
> a "string" context though.
A string context is a special type of scalar. This distinction already
exists in Perl:
$one = $two; # scalar (not string)
print "$one";# string (and scalar)
-Nate
> While I think Time::Object is a really great module, and following these
> discussions I'm thinking of adding a date() function to it
Aaah! Please don't. :-) Name it something else, por favor (or at least
wait until this is finalized and make the interface the same).
> date arithmetic...not so
> How usable is this ?
>
> I may be missing something, but if every variable mentioned in an anonymous
> block is assumed to be declared with my, then how do you access or modify
> the value of any variable outside the block ?
>
> Graham.
I knew someone was going to ask this; after I sent it I r
> Second, as it seems common for someone learning perl to expect
>
> $without_newline = chomp($previous_form);
This proposal seeks to make things more consistent, which is good, but
at the expense of being less usable, which is bad. For example, these:
chomp;
chomp(@file);
chomp($val
> fluid-let should *really* be called `now'),
Agreed (about the `now' part)
> Will this also apply to `use scope 'subs''?
No. Only subs are affected, which is a clear and easy dividing line I
believe.
> I, for one, will *never* use such a construct. It provides the user
> with the dangers of
> while($x)
> {
> $y += foo($x);
> $x = bar($x);
> $big_global_variable = analyze($y,$x);
> }
>
> This leaves you with three variables that may or may not be dependent
> on the upper scope for resolution by default.
As the RFC is written, only *anonymous* blocks are auto-
> > Do you mean the whole thing, or just the `blocks' part?
>
> Any feature which subverts "use strict" by attempting to declare my
> variables for me. In this case -- `blocks'. But also `subs' scope,
> since that makes anonymous subs useless.
As the RFC notes:
=head2 Incompatibility with s
> On Tue, Aug 08, 2000 at 02:18:07PM -, Perl6 RFC Librarian wrote:
> > Hooks will have to be put in Perl's string context so that if something
> > is an object, then that object's C method is called
> > automatically. If no C method is defined, then it should simply
> > return undef (instead o
> I think, if you look in the archives and the Camel, you'll find that turns
> out not to be the case.
I really don't like putting words in other people's mouths, so I'll
refrain. However, I have read comments from Larry and others in Camel
and perl5-porters that say something akin to this:
1
> > All Perl core functions should return objects
> >
>
> Yuck. Why not use the proposed want() and return hash-refs or slices,
> when appropriate.
No reason you couldn't do that too. This just affects scalar contexts.
-Nate
> It means a lot more code to write (and debug) for the things that
> return these objects, and that means parts of perl will be
> slower, take longer to write, and take up more space.
Point taken. I don't think internals should be ignored altogether, just
that they shouldn't be the driving force
> I think a stringified reference is worth seeing, moreso than a simple undef,
> for debugging purposes if nothing else.
Debugging is great, but I don't think this is the way to do it. The
reason is some objects might have a STRING method while others don't, so
you'll only get partial access to s
> I do agree that the internals shouldn't drive the language (otherwise a
> crack team of Ninja would've already taken care of that Conway guy... :),
> but neither can they be completely ignored.
Agreed. Which reminds me, we should call off those Ninja... :-)
> Honestly, I'd rather you put toge
> I think this is a bit heavy-weight for core.
Agreed. General-purpose timezone support is scheduled for a swift and
painless death in the next version of RFC 48. Only the local timezone
and GMT will be included in the RFC, same as now.
I wish it could happen, but too many people have brought up
> @array = ( a=>1, b=>2, 'c', 3 );
Isn't this just an array of hashrefs in in disguise? Or am I missing
something?
I don't see a problem for adding more ways to do something, my only
problem would be if the "key" and "value" builtins were the only ways to
get to the data. You should be a
How would this take into account stuff like this:
sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644);
The "O_RDWR|O_CREAT" part is what I'm talking about here. This is a
constant w/o suffix. We'll either have to:
1. Change it to $O_RDWR|$O_CREAT or $O{RDWR}|$O{CREAT}
Maybe for error
> > Replace localtime() and gmtime() with date() and gmtdate()
>
> I think to be politically acceptable to all that should be utcdate()
Me too. Actually, this was my first choice, believe it or not.
The problem is, many people on this list claimed that GMT != UTC, and
that machine time is only
> I know other languages call it zip, but personally I dislike
> that name as zip() is commonly used with reference to compression.
Ditto, I really dislike zip() and unzip(). They're PC and even UNIX
commands on several platforms now, increasing confusion.
Here's two names: mix() and unmix(). It
> well, if it is only a string, why use . as the separator? use something
> else like : and no one will try any fancy math tricks on it.
Agreed. I like :, it's a common separator.
Also, how about just $@->id? Shorter and I would argue the "unique_" is
really redundant (id's are usually unique, h
> So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan',
> 'Feb') or qw(dummy Jan Feb)... oh well.
Far better, use the new builtin object methods:
$d = date;
print "today is ", $d->date('%A'); # Friday
> Apparently, neither is hour. And why not, pray? I'd like to see t
> The difference is how they group:
>
> @unzipped_list= unzip(3, (1,2,3,4,5,6)); # ([1,3,5],[2,4,6])
> @partitioned_list = partition(3,(1,2,3,4,5,6)); # ([1,2,3],[4,5,6])
Let me make an observation, having done tons of matrix stuff: We're
going to wind up with 200 functions, all of wh
> Adding support for (modified) Julian Date will be much more
> generic and remove dependency on unix epoch with little
> extra code.
To me, the real question is which date() should we use:
$date = date $seconds_since_epoch; # uses time()
$date = date $modified_julian_date; # non-Unix
Andy-
Wow, this is a huge RFC. I read it, but could you please explain briefly
how this is different from a special type of package syntax?
It seems to me the . Java notation is the biggest salient feature of the
RFC. Looks like the rest is just a modification/reinvention of Perl's
current packa
Chaim Frenkel wrote:
>
> >>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
>
> NW> Also, how about just $@->id? Shorter and I would argue the "unique_" is
> NW> really redundant (id's are usually unique, hence the
> point: the convention of the upper case name indicates that they
> probably will be called automatically. "import" does not adhere to that
> convention.
Don't get me wrong, I'm all for it. I just thought the RFC glossed over
some important details so was trying to clarify some facts. They shoul
> How about any variable created in UPPER case is a constant?
Well, Perl does something similar now, just that they're not readonly.
But as everyone knows messing with @ISA, %ENV, BEGIN, FETCH, etc, etc,
etc will definitely alter your program.
Do we really need constants in Perl? I've always won
> Still, your matrix/unmatrix idea is intruiging... I'd be interested to see
> this fleshed out further (particularly to n-dimensional tensors, which is
> where I find generic functions hard to specify)...
What the heck! I'll try to produce something on it this weekend. By
Monday for sure.
If an
1 - 100 of 392 matches
Mail list logo
