>> > > Perl isn't a programming language - Perl's grammar is much more like
>> > > a natural language than a computer one.
>> >
>> > Well, $I wonder if anyone except @computers can find it natural to put a
>> > f... $dollar_sign in front of every $noun you use.
>>
>> Grammar != vocabulary.
>You'
>On Tue, Aug 01, 2000 at 07:29:05AM -0600, Tom Christiansen wrote:
>> I suggest that the language list discuss this very matter: what
>> Perl really *is*, so that we know the tenets and principles against
>> which proposals can be measured.
>
>Let's do that.
Thank you for your compliments.
> Would you be willing to give us a first shot at what Perl *is* to get the
>discussion going?
Only as slogans; deep analysis will require ascending a nearby summit.
"Perl is a language you already know, but that you just don't
know that you know."
>'Scuse me, but I'm a bit puzzled by this whole 'What is Perl' thing. My
>understanding of the rewrite was that it was primarily to provide a
>cleaner implementation than the current 'worn out' one, and to remove
>some of the more egregious features, e.g. the over-reliance on globs in
>some place
>Typeglobs != symbol tables.
>You can access individual variable bits in the symbol table now without
>using typeglobs. I don't see why that would have to change.
NB: $main::{fred} does not autoviv a typeglob when used lvaluably,
but *main::fred does.
--tom
>I apologize if this has already been gone over but I would really like to
>throw one out there: real Multi-line comments.
>This one has been bugging me for a long time. Any ideas?
>How about #/ lots of lines of code here, this is not backwards compatable,
>however /#
Do you really think
Plus you're still running à la pod mode, not à la code mode,
as mentioned on p630 of PP3. (I just looked to make sure multiline
comments were in the index. They are.)
--tom
>Several people have suggested strong typing as a feature, and have been shot
>down one by one. However, I think it can be done without forcing it on
>everyone.
Can it? Are you prepared to make everyone declare the full, formal, and
fancy types for the return values of all their functions?
C
>3. It no longer has a unix specific flavour (PS I am not anti-unix in any
>sense) so Mac, VMS and Windows users feel less confused.
Did it get decided that we were *supposed* to make Unix and C programmers
feel more confused and less at home with Perl?
--tom
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 se
>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))
>how about clone()?
I imagine that that name will be taken by something else, such as
cloned interpreters.
Anythi
>Johan Vromans writes:
>>Well, my editor has no problems to put #'s in front of a section of
>>lines, nor to remove them.
>Not every editor does this. Perl is supposed to be flexible and make things
>easy. It is not more flexible nor easier to require a programmer to use a
>certain type of editor
>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() o
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
>> Well we should still have POSIX::localtime().
>True, and hopefully in a more optimal form.
Were you planning on updating the Standard? :-)
--tom
>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 sh
>Please explain what the utility of having unshared variables? I might
>as well just fork().
The only sane situation is to have safety by default. Things should not
be shared unless you say they are.
--tom
>sub mapf(&;\@\@\@\@\@\@\@\@\@) {
Steal from lisp:
map
maap
maaap
mapp
mappp
maappp
...
:-)
--tom
>It nice to be able to bounce on % in vi, too:
>=#{
>comment
>=#}
You easy to do this already:
=begin comment {
=end comment }
--tom
>We're not thinking like in C where every variable `should' be prefixed with
>it's type, like p_var for a pointer to a variable or t_var for defining the
>type for var. In perl I just LOVE the way $, @, % and & unambiguously defines
>the type of the var. I just miss a prefix for formats (which wil
>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 mandatory takes
the singular prefix; to wit, $. What's next? Int
>Isn't this covered by locales?
Unicode and locales are immiscible.
--tom
>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:
p
>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 pro
>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 mer
>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.
What part of warnings(3) and perllexwarn(1) are you in disagreement with?
--tom
>> What is wrong with
>>
>> if (0) {
>>
>> }
>1) what if the block contains syntax errors?
Then the compiler carefully and courteously notifies you of such.
>2) what if the bloack contains unmatched braces?
See above.
>3) this is not easier to type or remember than the currently available
>
>Proposal: here-docs specified with regexes, and no special
>meaning for newlines.
> comment <
>But that, precisely, was my point: Arrays *and* hashes. If there is more than
>one plural whatzitz, then why can't there be more than one singular whatzitz?
>(and don't say, "because plural *means* more than one" :-). If having a
>filehandle character would make the code clearer, then let's do
>Tom Christiansen wrote:
>> > comment <>
>> Smack--the lexer cowers before you!
>Well, hey, while we're daydreaming... :-)
I suppose I should have written
The lexer misses!
You hit--More--the lexer cowers before you.
--tom
>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 s
>. 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 v
>> 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 $
>Perl 5 supports OO quite well.
Yup! Perl already supports classes and objects, single and multiple
inheritance, instance methods and class methods, access to overridden
methods, constructors and destructors, operator overloading, proxy
methods via autoloading, delegation, a rooted hierarchy for
>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
>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
>d
>I'd also like some 'what are you' introspection I can do on all scalars, on
>a more formal basis than 'ref'. Either an expansion of the 'ref' functionality
>to cover filehandles, or a more general system...
What do you mean, "formal"? ref() has always been a de facto typeof
operator, no?
o
>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
>Doesn't print 'GLOB' for me, but that's because a lot of real-world systems
^^
>haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause),
If you look at it, you'll notice that "real" is here being used as
something o
>I've just asked for a multiline comment sublist to be set up. Do any
>of the rest of these RFCs want/need a sublist?
What is the purpose of ghettoizing everying cohering topic? Making
us subscribe to infinite lists to wear us down?
--tom
>Tom Christiansen writes:
>> What is the purpose of ghettoizing everying cohering topic? Making
>> us subscribe to infinite lists to wear us down?
>Yes.
>If you really care about the topic, you'll join the list. If you
>don't care, stay off the list and don&#
>Could you please write up an RFC on this?
>K.
>On Tue, Aug 01, 2000 at 10:04:38AM -0700, Peter Scott wrote:
>>There was some discussion at TPC4 that typeglobs could be expunged from
>>P6. If this is likely, it would free up a type-defining punctuation
>>character (*).
>>
>>Could this be used
>> Making us subscribe to infinite lists to wear us down?
>You know about perl6-all, right?
Nope, I didn't.
Which is the very problem of which I was speaking.
Secret cabals and all.
--tom
> Thanks for the advice. Would "production" have been less likely to offend
>than "real-world"?
Perhaps. Or "conservative". Or "cautious". Or "paranoid". :-)
--tom
>What extra could reasonably have been done?
Should one really have to find the the time to read each of *hundreds*
of messages each and every day in order to keep up with this stuff?
Or should one be held accountable to for eyes glazing over adminstrative
metadiscussions (a crack into which for
>Great insight, thanks. It's obvious that I'll have to do a lot more
>research before (possibly) resubmitting anything on this subject. I do
>like the idea of at least being able to fiddle with input source
>tainting (since this is what usually gets me, even if I know the input
>source is safe). D
>Russ talked about doing that. I think it would have to be called
>nntp.perl.org.
I can trivially repoint the old news.perl.com to wherever works best.
--tom
>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.
Think of all the {file,dir}handle syscalls. They don't do that.
They autoviv an object.
--tom
>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 argument(s).
Just to name a few. bless ha
>Point taken, I did actually think of most of these. The difference is
>all of these return something still:
> $object = tie %hash, $class;
> $chopped = chop($var);
> $chomped = chomp($var);
> $ref = bless {}, $class;
I'd've written that more like
$data_axed = chop($var);
$
>Actually, open() currently CAN have just one parameter. What it does, is
>use a filehandle and a scalar variable with the same name, so
>Nope. Get rid of it! (p.s. Has anybody ever actually used this feature,
Yes, of course. That isn't an argument for its persistence, however.
--tom
>Modify open() and opendir() to return filehandle objects
Here are some things that that will be a problem for:
open(SESAME, "| output-pipe-command") # set up an output filter
open(SESAME, "input-pipe-command |") # set up an input filter
open SPOOLER, "| cat -v | lpr -h 2>/dev/nul
>I'd either leave that as (localtime)[3,4,5] (please read the man page for
>Time::Object), or understand that there's absolutely no need to separate
>off the variables like that in an object oriented interface:
> my ($day, $month, $year) = (localtime)[3,4,5];
>becomes:
> my $date = localtim
>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 convenient.
--tom
>This reminds me -- once there was a proposal to extend the wantarray
>functionality on p5p. Anyone remember? Anyone want to turn it into an
>RFC?
It was Damian's, no?
--tom
>The suggestion was the open() return a filehandle object, so may
>I suggest
> $fh = open("| cat -v | sort | lpr") or die ;
> $pid = $fh->pid;
Let's see how that plays out with pipe open:
if ($fh = open("| cat -v | sort | lpr")) {
print $fh "stuff\n";
} else {
di
>Are you saying that piped opens returning a "filehandle" object makes
>testing for failure more troublesome? If so, I have an evil proposal
>for you ... Let's make an "error" object (I hate to use that term)
>that's *always* false but has some state we can get at. This thing would
>encapsulate
>True, but maybe a lower precedance keword is needed like we did
>or || and &&. I think someone suggested "then"
> print $string1, $string2, "\n" then return 3 if $cond;
>then again, maybe not.
Why not just piss everybody off?
return 3 after print $string1, $string2 if $cond;
honk love f
>On Thu, Aug 03, 2000 at 08:13:09AM -0600, Tom Christiansen wrote:
>> No, that's gross. A failed constructor should return undef. See my
>> later message.
>That has always been my view. But then people say "but why did it fail"
>and having global vari
>On Thu, Aug 03, 2000 at 10:53:02AM +0100, Hildo Biersma wrote:
>> Ah, but we could make the language support this:
>>
>> localtime->{'day', 'month', 'year'}
>>
>> in hash-slice fashion.
>That's really scary and I like it a lot.
That already has a meaning, thank you very much. :-(
--tom
>[EMAIL PROTECTED] wrote:
>> Perl's similarity to English is one of the things that makes it Fun.
>OTOH, being fun (which I admit it is) is one of the reasons many
>people don't want to think Perl is a serious language.
So what?
--tom
>If we were to agree to make the basic syntax of open() something like:
> $object = open [$filename], [$class];
>There's a lot of cool stuff we could do. In the simplest "mostly looks
>like Perl5" cases, open() can work like shown above. In fact, I'd be
>plenty happy with just this, since it m
>if you want to have something like switch/case it is a good idea to use
>the 'case' of pascal, because it is easy to use and it is really clear.
>the 'switch/case' of c is (in my opinion) is not good for a language
>like perl which claims to be practical.
Please, please, *PLEASE* read through Da
> I have retained the title of "Lexical variables made default,"
>because I still feel that that is the primary purpose of this change,
>meaning that in future Perl documentation (books, manpages, classes (I
>hope)) new Perl users will first be presented with variables declared
>as lexicals with
>While a function style or quoted form
>comment might seem clever, and even Perlish due to its syntax, it doesn't help
>the author of the code/comments readily distinguish them. What good are
>comments if you can't find them when you need them?
Sounds like an argument for :10,20s/^/###/ style co
>This doesn't fix the problem of:
>{
> $somevar = 0;
> $someVar++; # oops, wrong case!
>}
>Forcing 'my' by default allows these errors to be caught.
How so?
--tom
> What if the default strictness of vars was a compile-time option to
>be decided by the administrator of each site?
That would hamper portability.
Then again, the right PERLOPTIONS=-M... set in /etc/profile might
work, too, but that -M is forbidden in file-based scripts.
--tom
>> Some related issues:
>>
>> 1) Did Larry or did he not mention something about dealing with
>>indirect object more cleanly?
>Maybe clarify this just a little. I don't think I was present for this
>discussion.
That's just the indirect object slot ambuiguity annoyance. See the
OO c
>How often does the return value from chomp or chop get used? The confusion
>would cleared up considerably, I think, if they didn't return a value.
Seldom, I think--albeit sufficiently often that you might want the
perl526 translator to have any such found be converted to some kind
of lchop/lcho
>Thus it was written in the epistle of Perl6 RFC Librarian,
>>
>> =head2 Disadvantages
>>
>> Literally none have been broached on the various C mailing lists.
>Well, I'll take my shot at providing one: An at least %800 increase in the
>characters used to make up these names. For quick hacks,
>no implicit;
>(Or 'no implicit print;' after rev 2 comes out. ;-)
Or "IMPLICIT NONE" :-)
--tom
> > What about '$me'? It ties in nicely with 'my' (although perhaps f
> > wrong reasons), it's half as much typing as 'self' or 'this' and we get
> > to annoy both sets of religious zealots at once. :-)=
>You took the words right out of my...err...fingers!
>Although, of course, it will
>Several macro processors exist and are easily available. I do not see
>the need to duplicate (parts of) their functionality in perl.
>Personally, I'd even trow out -P.
Well, possibly, but especially if a cpp-like source filter module
is included standard.
--tom
>> If you do it the C++ way, you can say:
>> try {
>> first_sub_that_throws_exceptions();
>> second_sub_that_throws_exceptions();
>> } catch {
>> it went wrong
>> }
>How does 'it went wrong' know _which_ of the subs went wrong?
This is my argument against obsolescing
>Johan Vromans <[EMAIL PROTECTED]> writes:
>> =head1 ABSTRACT
>>
>> Perl distinguishes named operators and functions. For Perl6, this
>> disctinction can be dropped.
>Will this then work?
> sub foo {
> my $func = shift;
> &$func(@_);
> }
> foo(\&print, "foo");
> foo("print", "foo"
>The descriptions in perlfunc etc. are not 100% complete.
Then send a patch.
>There are some features that are still not documented. Therefore, it is
>not possible to mathematically prove that a largish program is correct.
Your "therefore" is misplaced or misguided. Formal proof systems
of cor
>Hello!
> I am thinking about the perl compiler, and I thought if somebody
>avoid using the "eval $scalar", the compiled code (perl to C
>compiled code) may not contain a full perl interpreter. If it is the
>case, we must say to any module developer: Don't use "eval $scalar"!
>
>Has having $ and its riends caused trouble
>for you?
Only embarrassment at explaining it.
--tom
>I hesitate to point out that the object who's method is called is the
>actor, not what is acted upon. Therefore, we should be using the
>nominative case, and go with $I :-)
Actually, I'd argue dative (give $him "grief") or vocative
($brute->acting(qw/cassius strange/)).
--tom
>> 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!?!?
--tom
>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.
>>
>At 12:47 AM 8/4/00 -0400, Ken Fox wrote:
>>John Tobey wrote:
>> > The Perl 5 (and older) behavior may preclude some optimizations.
>>
>>I can't think of any optimizations @_ assignment precludes.
>>If we don't analyze dataflow to figure out if a sub modifies its
>>args, then we just assume it wil
>I've heard "internal consistency" bandied about a lot. I think
>auto-my()ing variables in these sub declarations is a bad idea.
>What if you DON'T want them to be my()'ed? Do we have to add a global()
>keyword?
That's what Python requires. Keeping in mind that Python isn't
truly block-scoped,
>> Why would we ever remove a syscall!?!?
>I vote for migration to a module.
And sysopen and fcntl and waitpid and ioctl
>Gisle Aas wrote:
>>
>> foo(\&print, "foo");
>I think it's critical that built-ins be reference-takeable,
>just like user-defineds.
But they [dw]on't work right.
sub CORE::push { push(@_);
$fn = \&CORE::push;
$fn->(@some_array, now, some, list);
--tom
>I don't much care for m4; it's not so much better than cpp to be
>worth the notice.
*Strongly* disagree.
--tom
>Tom Christiansen wrote:
>> > I think it's critical that built-ins be reference-takeable,
>> > just like user-defineds.
>>
>> But they [dw]on't work right.
>Um -- why not? Why can't we make then work right in perl6?
As my example demonstr
>As my example demonstrated, it's because there's no run-time
>application of content coercion templates. And I don't think
s/ent/ext/
>Andy Wardley wrote:
>> What about '$me'? It ties in nicely with 'my' (although perhaps for the
>> wrong reasons), it's half as much typing as 'self' or 'this' and we get
>> to annoy both sets of religious zealots at once. :-)=
>Yes, absolutely. Now what good meanings could we attribute to $
Gosh, just unlink() leave it as it is.
--tom
>Tom Christiansen wrote:
>> #if 0
>> ...
>> #endif
>Ahem, has somebody already mentioned -P (perldoc perlrun)?
>If you want 'em, you already got 'em!
I'm in the choir, preacher! IWTFM. :-)/3
--tom
>Point taken. But part of the goal was moving a lot of stuff out of CORE
>and making Perl faster. New features are great, but we should figure out
>whether or not they're truly CORE-worthy. Sticking it in a pragma like
>strict helps to solve this issue, but as always TMTOWTDI.
I find the notion t
>A regex's (?{...}) block is always considered to "match" successfully, but
>it'd be nice to be able to have it be unsuccessful. This would allow
>generic "if such and such is the case, abort this branch" components of
>regexes.
[supporting explanation deleted]
Agreed. This has been previously
>Here in my pre-caffiene morning trance it occurs to me that a few of
>the "fringe" features of perl should be removed from the langauge.
>Here's a few things that I would venture to say that none of the
>"perl5 is my first perl" people have probably ever actually used.
> reset #
>I've very rarely found cases where ?? was useful and // didn't work, and
>never in regular code.
>From the Camel:
The C operator is most useful when an ordinary pattern match
would find the last rather than the first occurrence:
open DICT, "/usr/dict/words" or die "Can't open w
>So basically, it would be nice if each, keys, values, etc. could all deal
>with being handed a hash from a code block or subroutine...
In the current Perl World, a function can only return as output to
its caller a LIST, not a HASH nor an ARRAY. Likewise, it can only
receive a LIST, not those o
>Today around 11:48am, Tom Christiansen hammered out this masterpiece:
>: >So basically, it would be nice if each, keys, values, etc. could all deal
>: >with being handed a hash from a code block or subroutine...
>:
>: In the current Perl World, a function can only retur
>It would be nice if a human readable dump were possible. So please don't
>completely dump the idea of Data::Dumper functionality in the core.
These are different things. And the bytecodes can always be B::Deparse'd, or
whatever we come up with for uncompilation.
Not that proper marshalling isn
> dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Hmm, what about CHECK blocks?
--tom
1 - 100 of 332 matches
Mail list logo
