Re: formats and localtime

[Larry Wall]

Nathan Torkington writes:
: Damian Conway writes:
: > My (limited) understanding of the aims of Perl 6 were to start again with a
: > clean slate and fix the things that are broken, or that could be designed
: > better with hindsight.  Backwards compatibily was to be fed to the lions.
: 
: Larry's the one who will decide what goes into perl6, and I'm speaking
: here as Nat the Perl Hacker not Nat the Project Leader.  So understand
: that what follows is not holy writ, but a mere mortal's understanding.
: 
: I would be surprised if perl5 programmers didn't feel at home in
: perl6, so I'm not expecting lots of massive changes to the language.
: I doubt int/string/etc typing will be mandatory.  I doubt dollar signs
: will disappear.  "If you want Ada, you know where to find it" still
: rings as true today as ever.  You'd need pretty convincing arguments
: to get any of those changes through.
: 
: That said, if you can make a convincing argument for a feature's
: inclusion then do so.  The types of arguments that are likely to win
: over Larry (I'm guessing) are things that make easy things easier,
: hard things easier, or previously impossible things possible.
: 
: So while backwards compatibility should not be an issue in the
: brainstorming process we're in now, this doesn't mean that perl6 will
: be unrecognizable.  Nor is this merely thinking of new things to bolt
: onto perl5.  Some of the most important changes will be underlying
: structural changes (e.g., internals, corners of language syntax) that
: make some previously hard things easier (extending with C,
: pretty-printing, run-time ability to optimize for memory or speed).
: 
: Larry, is this what you had in mind?

That's pretty close.  Just because everything is negotiable doesn't
mean that we plan to negotiate everything away.

To say we're feeding backward compatibility to the lions is a bit
misleading, in that it doesn't say what we're putting in its place.
What we're putting in its place is the notion of a clear migration
path--a land bridge from the old continent to the new one.  As long as
people have an easy way to upgrade (most of) their Perl 5 programs to
Perl 6, I think we've done our job.  Many syntactic constructs will be
easy to translate.  Some kinds of semantic shifts would make translation
next to impossible.  We're looking for some kind of 80/20 inflection
point.

Let me just add that I don't mind the brainstorming at all.  To be a
good language designer, you have to stuff your brain with what you
*could* do before you can reasonably choose what you *will* do.  At the
moment, I'm not only trying to follow along here; I'm also reading all
the books on computer languaes I can get my hands on--not just to look
for ideas to steal, but also to remind myself of the mindset Perl was
designed to escape.

In fact, I'd go as far as to say that it's imperative that you
overstuff your brain to the point where you no longer feel tempted to
overstuff the language.  Hypotheticality is your friend.

Larry

Re: formats and localtime

[Larry Wall]

Chaim Frenkel writes:
: > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
: 
: DC> Only if you simultaneously remove Perl 5!
: 
: DC> My (limited) understanding of the aims of Perl 6 were to start again with a
: DC> clean slate and fix the things that are broken, or that could be designed
: DC> better with hindsight.  Backwards compatibily was to be fed to the lions.
: 
: DC> If that isn't the case, I'll be unsubscribing immediately -- if Perl 6
: DC> is to be a mere exercise in featuritis, I'm not interested.
: 
: The problem will be what do you do with all of the old guard? Larry has
: a major balancing act to do. Clean up the dirty laundry but still leave
: the language for those useful dirty deeds.

The only difficulty is if we fail to perceive which parts of Perl 5 go
in the washing machine, and which which parts go in the bathtub.

To me, formats are a no-brainer.  They go in the washing machine, and
then back in the drawer where they're handy if you want to accomplish
formatly things.  Translating Perl 5 formats to Perl 6 formats should
be pretty easy.

But yelling that formats are essential to the core reminds me of my
kids, who sometimes act as if they're being excoriated when we're
merely trying to get them out of their dirty clothes and into some
clean clothes.  As humans we identify too closely with our clothes.

Larry

Re: RFC: Reimplement Warnings and Tainting as Pragmas

[Larry Wall]

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 run into the same kinds of problems we ran into with my
first boneheaded implementation of utf8.

About the only thing you could scope with a lexical scope is whether
a given input source taints its input, but that sort of decision should
really be done in an OO fashion as much as possible.  That is, you set
it on an input stream object, not on a chunk of code.

Larry

Re: RFC: Filehandle type-defining punctuation

[Larry Wall]

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 key-value pair by virtue of looking like two o's separated by a 
: divider.  Never seen this interpretation before, though.)

Sorry, beat you to it, barely.  Camel III, page 10:

(If you look carefully at the % character, you can see the key
and the value with a slash between them.  It may help to squint.)

Actually, that was one of the reasons I picked % in the first place.

Larry

Re: RFC: Filehandle type-defining punctuation

[Larry Wall]

Peter Scott writes:
: At 06:28 PM 8/2/00 -0600, Tom Christiansen wrote:
: >ref() has always been a de facto typeof operator, no?
: >
: > open my $fh, "< /etc/motd";
: > print ref $fh
: >GLOB
: 
: Can we make that IO in P6...?

Maybe, but it might be some class derived from an IO object, depending
on how we decide to do things.

Larry

Re: RFC: Higher resolution time values

[Larry Wall]

Graham Barr writes:
: On Wed, Aug 02, 2000 at 11:50:10AM -0400, Sam Tregar wrote:
: > On 2 Aug 2000, Gisle Aas wrote:
: > 
: > > =head1 PERL5 PORTABILITY
: > > 
: > > Calls to time() could be transformed to int(time()) when converting
: > > perl5 programs to perl6.
: > 
: > Unless there's a:
: > 
: >use HiRes::Time qw(time);
: > 
: > in effect!
: 
: 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.

Theoretically, we'd like to make subs run as fast as ops.

Larry

Re: RFC: Request For New Pragma: Implicit

[Larry Wall]

Chaim Frenkel writes:
: No.

This sort of argument is not terrilby useful.

Really, I don't see any big problem with the notion of the values of void
expressions being sent somewhere, as long as it's lexically scoped, and
doesn't rely on a global default filehandle.  This kind of default
output has always been a selling point of REXX, actually.

Let me reiterate my view of pragmas.  They can warp the language any
way you please, as long as they don't impact other modules.  I wouldn't
even mind if someone wrote a pragma that lets you program Perl in Latin.

Larry

Re: RFC: Filehandle type-defining punctuation

[Larry Wall]

Tom Christiansen writes:
: >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.

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.

Larry

Re: Removing/fixing $[line noise here] variables

[Larry Wall]

Steve Simmons writes:
: On Tue, Aug 01, 2000 at 04:47:47PM -0400, Dan Sugalski wrote:
: 
: > Put together an RFC for it. (Soon!) This is a language topic, but it will 
: > impact internals a touch, and I'd like to get as many of the "impact 
: > internals" things spec'd out as soon as possible . . .
: 
: Uh, OK - but how about we wait 24 hours to see who screams bloody murder?

Some of these concepts are not going to be global concepts in Perl 6.
The per-filehandle variables will be attached to filehandle objects.
The format variables will likely be attached to format objects.  Every
one of these global variables needs to be scrutinized to see if it
should be replaced with a lexically scoped variable.

If there are any left after that, then we could certainly consider
putting them into global hashes.

Larry

Re: Recording what we decided *not* to do, and why

[Larry Wall]

John Porter writes:
: Michael Mathews wrote:
: > how shall I, as an RFC > Maintainer determine what that status is?
: > 
: > Personally I don't want anything to do with judging the "status" of this
: > RFC, beyond my one voice. I do accept responsibility for compiling some
: > organized record of the responses I've received, but who shall decide
: > (before Larry decides)?
: 
: You have to determine the status, but that shouldn't be scary,
: considering these RFCs are ultimately just recommendations for
: Larry's consideration.  Since the broad concensus seems to have
: been that inline comments might be very useful, and not breaking
: anything else, the status could be "Good". 

As long as everyone realizes that I might reject a good many "Good"
things merely because if I accepted them all, Perl would become twice
as complicated as it is.  Note in particular that multi-line comments
are something we *could* have added at any time, but chose not to.
This means you're gonna have to argue a little harder for it than you
would for something that wasn't possible before, but that we think
might become possible with the redesign.

As I see it, given the proclivities of design-by-committee, my main job
at this point is to prevent feature bloat.  There are various prongs to
this strategy.  The obvious ones include culling "bad" features from
Perl 5, and limiting the introduction of marginal features into Perl 6.

A less obvious strategy is to try to see where various marginal
features could be subsumed under some more powerful feature.  To some
extent, you see this with the ability to use pod for multiline
comments.  For embedded comments, we might rather see some kind of
macro facility that could turn qc// or any other quoted form into a
list of zero or more tokens.

Larry

Re: RFC for recursive regexps

[Larry Wall]

[EMAIL PROTECTED] writes:
:> In perl5,
:> 
:>   /(??{ $FOO })/
:> 
:> delays the interpolation of $FOO, so as to be able to have
:> recursively defined regexps.
: 
: Of course, that example might in itself be sufficient reason
: to completely redesign the regex syntax!

On the other hand, if they're so bad, why are several other languages
now advertising that they support "Perl 5 regular expressions"?  :-)

Of course, we do want to stay ahead.  But we must be careful not to
confuse change with progress.

Larry

Re: Things to remove

[Larry Wall]

Jonathan Scott Duff writes:
: 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   # How often do you clear variables wholesale?
:   dump
:   ?pattern?   # one-time match
:   split ?pat? # implicit split to @_
:   study   # never been a win for me.
: 
: What's everyone's feeling on removing these from perl6?  How often are
: they used?

Those are all good candidates for removal, or at least "promotion" to
an external module.  The only one I'd think twice about is study.  For
much of Perl 5's existence, it didn't get a fair shake, since it was
buggy, and nobody noticed.  Of course, that might be an argument for
removal.  :-)

I'm not enamoured of the study interface, but the algorithm is
definitely a win on certain classes of data.  The basic problem with
study is that it needs incestuous hooks into how you do string
searching.  So even if we moved study out into an external module, we'd
still have to find some way to treat searching for constant strings as
polymorphic within the regex engine.

Larry

Re: perl 6 requirements

[Larry Wall]

Johan Vromans writes:
: On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote:
: > So Larry is doing most of the evaluation for us.  He's the one who
: > gave us the good things in the Perl language we have now.  He'll be
: > the one vetoing the ridiculous ideas.
: 
: Larry said: "Perl5 was my rewrite of Perl, Perl6 will be the community's
: rewrite of Perl." I think it is not realistic to keep shooting around,
: trusting Larry to prevent anyone from getting hurt. We have our own
: responsibilities as well.

Yes, I don't mind other people shooting down the bad ideas, as long as
they do it politely, and with good reasoning to back it up.  It's the
mindless sniping that is destructive, particularly when we're still
brainstorming.  People need to have a safe forum for bringing up
half-baked ideas, even if we're also trying to create a more official
RFC mechanism.

On the flip side, we need to be Very Careful not to get our egos
irrevocably tied to our proposals.  I have a particular distaste for
the sort of argument that goes, "If I can't have it my way, I'm going
to take all my marbles and go home."  That's not an argument--that's
nuclear blackmail.  I'm the only one who's allowed to make that sort
argument, and you'll never hear me making it.

Unless, of course, you count Rule 1 as a form of it.  :-)

But you'll notice I almost never invoke Rule 1.  I am, in fact, rather
more fond of Rule 2.  I think everyone should be allowed to change
their mind occasionally.

Larry

Re: what will be in Perl6 ?

[Larry Wall]

raptor writes:
: http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html

That's a good summary of what we've been thinking.  Here's another
article that talks about a lot of the things we *should* be thinking.
In fact, it's possible this article should be required reading for
anyone who aspires to be a Perl designer.

http://windows.oreilly.com/news/hejlsberg_0800.html

Larry

development relationship of Perl 5 and Perl 6

[Larry Wall]

Johan Vromans writes:
: Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
: 
: >   perl.exe + perl.dll or .../bin/perl + libperl.so 
: 
: RFC: Should the perl program be called differently (e.g., perl6) to
: allow sites to run 5 and 6 in parallel until their migration is
: completed (if ever)?

We will certainly have to distinguish the executables.

I will go farther than that, and say that we will fail if we do not
build Perl 6 in the same distribution tree as Perl 5.  Yes, we're
redesigning Perl 6 from scratch, but I think that for a long time yet,
we will need to keep the scaffolding of Perl 5 around Perl 6.  Keeping
them co-located has a number of advantages:

* We know which version of Perl 5 we're using to build Perl 6.
* We can make calls back into Perl 5 to emulate things not yet
implemented in Perl 6.
* We make it obvious that Perl 5 is still very important to us.
* We keep Perl 6 in front of everyone's nose even if they aren't
interested in using it yet.
* We can evolve the Perl-5-to-Perl-6 translator as we go.

I basically used the emulation approach to write Perl 5, so I know it
works.  There were some intermediate forms of Perl where some of the
opcodes ran Perl 5 C code, and some of them ran Perl 4 C code.  

My basic underlying point is that you can be revolutionary in design,
yet evolutionary in implementation of that design.  And that taking
such an evolutionary approach has the advantage of not letting the old
guard think they've been totally abandoned.  (Witness the problems of
perceived abandonment with the Mozilla rewrite.)

We may, of course, decide to do something so different that there's
no way to write the glue to call back into Perl 5 for unimplemented
opcodes.  If that's the case, it might be a danger signal that we're
overreaching, and we'll have difficulty dragging Perl 5 code into the
Perl 6 world.

I could be wrong about that.  Whether or not we use Perl 5 to emulate
unimplemented opcodes, we still to keep Perl 6 near Perl 5 for all the
other reasons.

Larry

Re: what will be in Perl6 ?

[Larry Wall]

Jonathan Scott Duff writes:
: On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote:
: > raptor writes:
: > : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
: > 
: > That's a good summary of what we've been thinking.  Here's another
: > article that talks about a lot of the things we *should* be thinking.
: > In fact, it's possible this article should be required reading for
: > anyone who aspires to be a Perl designer.
: > 
: > http://windows.oreilly.com/news/hejlsberg_0800.html
: 
: In reading this I noticed that documentation was listed as a first
: class language construct and that got me thinking about python's
: docstrings.  It would be neat to have something similar in perl.

If this article is going to inspire multiple threads, let's try to give
them unique subject names.  Thanks.

Larry

Re: RFC 58 (v1) C changes.

[Larry Wall]

Ted Ashton writes:
: Thus it was written in the epistle of Segher Boessenkool,
: > 
: > The magic defined($_ = ) only happens if  is the only thing
: > inside while().
: > 
: > In this case, it's not (there's a chomp() inside as well), so the magic
: > doesn't apply.
: 
: Ok.  One more time . . .
: 
:   I'm proposing that we change that.

Before we get too carried away discussing the syntax of chomp, let's
look a bit at the semantics.  What's chomp supposed to work on if we
make $/ go away?  I think any discussion of chomp without considering
how the input discipline finds line terminators is destined to be a
partial solution.  If chomp exists in Perl 6 at all, I think it would
have to be some kind of method call on the string that figures out what
the discipline determined to be the terminator *for the current line*.
(Note that under Unicode, we might well have one line terminated with a
line separator, and the next line terminated with a page separator, and
the line after that terminated with a CFLF.)

On the other end, we're constrained to be able to translate current
uses of chop and chomp to something that will work in Perl 6, so we
can't just throw them out and say the input disciplines will do it all.
Even if chop and chomp are not longer the preferred way of doing it,
we'll still have to emulate the functionality somehow.

Larry

Re: RFC 58 (v1) C changes.

[Larry Wall]

Larry Wall writes:
: (Note that under Unicode, we might well have one line terminated with a
: line separator, and the next line terminated with a page separator, and

Make that paragraph separator.

Larry

Re: RFC 71 (v1) Legacy Perl $pkg'var should die

[Larry Wall]

Bart Lateur writes:
: On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote:
: 
: >D'oh! ;-)
: 
: Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with
: this appropriate name any more.
: 
:   
: 
: 
: OTOH, try this:
: 
:   $hash{a'b} = 1;
:   print keys %hash;
: -->
:   a::b
: 
: That shows that the current situation is not ideal, anyway.
: 
: Besides, p52p6.pl can handle the conversion.

Alternately:

use ident qr/[A-Za-z_][A-Za-z_0-9']*/;

or some such.

Larry

Re: Things to remove

[Larry Wall]

[EMAIL PROTECTED] writes:
:> Most of the requests for deletion seem to begin with, "This isn't
:> used..." 
:> 
:> To which, "*I* use it." is a very valid argument.
: 
: Agreed. The real problem with ?...? is that it complicates the hell out
: of the parser. So long as the special magic is retained for m?...?, I
: would suggest that raw ?...? could beneficially disappear.

Or turned into m//f, or some such.  Must think about relationship to
an extension-based reset operator as well.  To maintain current semantics
we'd need introspection into the regular expressions used in a particular
package.

Larry

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

[EMAIL PROTECTED] writes:
: Note that it may not be possible to satisfy conflicting requests.  If
: module C and module C demand two different versions of the same
: module C, the compiler should halt and state the module conflicts.

Pardon me for sniping at a great RFC, but I already promised the CPAN
workers that I'd make that last statement false.  There's no reason in
principle why two modules shouldn't be allowed to have their own view
of reality.  Just because you write Foo::bar in your module doesn't mean
that Perl can't know which version of Foo:: you mean.

The issue is actually more general than just versioning.  The larger
view of it is how to support package aliasing.  A package name is
essentially the name of a public interface.  Suppose you have one
interface, but two or more different implementations of that interface
by different people.  Each might have their own version sequence.

There are open questions on that, of course.  If we have two different
packages of the same name differentiated only by version or by author
(or both), we obviously count that internally as part of the name of
the package.  To what extent do we need to reveal the full internal
name of a package?  (For instance, does the author/version show up as
part of the name when you say "ref $object".)

Another question is whether the two different versions of the "same"
module are going to stomp on each other?  (Not in package space, since
the packages are distinguished internally, but how about in the
filesystem?)

There are also policy issues with package naming.  When and how do we
declare that a package name like XML::DOM is a standard abstract
interface that belongs to no one implementation, and restrict version
numbers to interface revisions, not implementation revisions?

Basically, there are some more things we have to think about if we
really want to do Best Fit rather than First Fit.  And I think we do.

Larry

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

Dan Sugalski writes:
: Does that mean, then, that when module A does a "$C::bar = 1" it affects a 
: different package namespace than module B doing a "$C::bar = 2"?

Presumably.

: And does it also extend to things like this:
: 
: package A;
: use C 1.2;
: package B;
: use C 1.4;
: 
: where two packages in the same file use different versions of module C and 
: get them?

I expect that could also be made to work, provided the semantics of
importation remain package-scoped and don't become lexically scoped.

To me, it really just means that the *real* name of the package includes
the implementation (author?) and version, but that when you say

use C;

you're just choosing to wildcard both the implementation and version.
This view says that we probably ought to figure out how to encode the
implementation and version syntactically as part of the package name,
rather than as a 3rd argument to use.

Think about the long names of fonts for an example of how far this
can be taken.

Larry

Re: RFC 79 (v1) Code which is both executable and POD.

[Larry Wall]

John Porter writes:
: Michael Mathews wrote:
: > 
: > This ... underlines why POD is not a good way to comment code.
: > ...
: > This RFC would seem to address the issue quite neatly.
: 
: So, are you saying that if this RFC is implemented, POD would be
: an good way to comment code?

It already is, as far as I'm concerned.
 
The view that the POD contained within a file specifies a single
document is oversimplified.  The moment we added =for and =begin/=end,
POD became a way to specify multiple, independent documents in the same
file.  Each keyword following =for or =begin/=end specifies a different
abstract document.  If one of those abstract documents happens to be
commentary on the code, great.  Not all of those abstract documents have
to be intended for external POD viewers, assertions to the contrary
notwithstanding.
 
Seems like all we're discussing now is how much those independent
documents should be independent (where the code itself is considered
one of the documents).
 
Larry

Re: RFC 78 (v1) Improved Module Versioning And Searching

[Larry Wall]

Dan Sugalski writes:
: At 11:11 AM 8/9/00 -0700, Larry Wall wrote:
: >Dan Sugalski writes:
: >: Does that mean, then, that when module A does a "$C::bar = 1" it affects a
: >: different package namespace than module B doing a "$C::bar = 2"?
: >
: >Presumably.
: 
: H. That brings up some issues of ambiguity, then. If you use C in 
: package A, and also in package B, which do you see when you're in main and 
: access $C::bar?

I dunno.  I don't imagine the situation will arise that often.

: >Think about the long names of fonts for an example of how far this
: >can be taken.
: 
: Would this be "Taken to its logical and sensible conclusion" or "Taken as 
: far as it can possibly go, though it you turn around and look *really* hard 
: with binoculars you can see where you crossed the line, way back there by 
: the horizon"?

I was leaving that one ambiguous on purpose.  :-)

Larry

Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t

[Larry Wall]

[EMAIL PROTECTED] writes:
: =head1 IMPLEMENTATION
: 
: This strikes me as being a fairly easy thing to do, but then again
: internals ain't my thing, baby.

The problem I see here isn't the internals--it's how do you translate
Perl 5 to Perl 6?

Larry

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Larry Wall]

[EMAIL PROTECTED] writes:
: p52p6 would handle it (by translating all Perl 5 C"y">'s to Perl 6
: C<'x',"y">'s.
: 
: I *must* put this in the RFC!

I think most of the RFCs could use a MIGRATION POLICY section, or
some such.

Larry

Re: RFC 83 (v1) Make constants look like variables

[Larry Wall]

[EMAIL PROTECTED] writes:
: It is proposed that a new syntax for declaring constants be introduced:
: 
:   my constant $PI = 3.1415926;
:   my constant @FIB = (1,1,2,3,5,8,13,21);
:   my constant %ENG_ERRORS = (E_UNDEF=>'undefined', E_FAILED=>'failed');

Can't put a modifier like "constant" in the type slot.  The syntax for
variable attributes will look more like this:

my num $PI : constant = 3.1415926;
my int @FIB : constant = (1,1,2,3,5,8,13,21);
my str %ENG_ERRORS : constant = (E_UNDEF=>'undefined', E_FAILED=>'failed');

Larry

Re: Portable upper/lower case regexp matchesre and procedures

[Larry Wall]

Dave Storrs writes:
:   Here's my question of procedure:  plenty of times on these lists,
: I see something that I think is a really good idea.  I don't want to waste
: bandwidth by posting just a "me too!", but I also don't want the idea to
: die because no one weighed in in support of it.

If it's in an RFC, it won't die for lack of consideration.

:   Is there a mechanism in place for this, or could we set up
: something on the website for voting on the RFCs (perhaps with conditions,
: like "I agree with this as long as XYZ is [not] done")?

If something's a good idea, it'll either be obvious, in which case it
doesn't matter if it's voted on, or it'll be not so obvious, in which
case goodness of the idea emerges from the many ramifications that will
no doubt be hashed out in the ensuing discussion.  So the idea is that
we "vote" by exploring the ramifications of the hypothesis.  (If there
are no ramifications, perhaps the idea isn't so important.)

If something's a bad idea, then a few counterexamples will usually make
that obvious.

If something's a mediocre idea, maybe it can be refined into a good idea,
and maybe it can't.  But voting is unlikely to help there either.

Voting doesn't produce consensus.  Discussion sometimes does.

Larry

Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)

[Larry Wall]

Dan Sugalski writes:
: Yup. It's an issue for things that implement any non-standard semantics for 
: existing ops, especially if those ops are overridden at runtime so the 
: optimizer doesn't know. It's one thing to mess with tied variables, its 
: another entirely to make + behave differently.
: 
: I think we'll need to get a ruling from Larry at some point on this one.

I haven't been terribly happy with tie for some time.  I'd rather we had
more type-based approach, which could:

1) factor the work out to one spot so you wouldn't have to call tie
on every element of an array, for instance.
2) let us tie lexically scoped variables that don't leak out to the
surrounding program.

And even if we keep the current tie interface (and we probably have to,
even if we add a better way), we can probably limit the damage other
ways.  If we see a declaration like:

my int $foo;

we can decide either that $foo will never be tied, or that it will never
be tied to an implementation that violates the standard meaning of +.

Larry

Re: RFC 83 (v1) Make constants look like variables

[Larry Wall]

Steve Simmons writes:
: On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
: 
: > Please, please, please, PLEASE, let us not replicate the debacle that is
: > C++'s const modifier!
: 
: It doesn't feel like a debacle to me, it feels like it put the control
: in the programmers hands.  Yes, the syntax is often unweildy -- but IMHO
: that's because when one marries the idea of constants to complex data
: structures and references, the world becomes an unweildy place.

Hmm, well, we'll certainly have constants of some sort or another.  I
don't think Damian needs to worry about me making Perl look like C++.
I've also grown to detest the fact that every other word in a typical
C++ program is "const".  My inclination at this point is make certain
things constant by default (such as the insides of a complex constant,
and the parameters to a subroutine), and then have a way of "undeclaring"
constancy if you really want it.  It would perhaps be considered bad
form to vary someone else's constants.  (Outside of Indiana.)

Larry

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Larry Wall]

[EMAIL PROTECTED] writes:
: Yep.  Or more generally "Standardize Perl on all platforms to one
: common time epoch" and reccommend the Unix epoch since it's so
: widespread.  :-)

Oh, gee, where's your sense of history?  (As in creating our own. :-)
Maybe we should invent our own epoch, like the year 2000.  Or use a
really standard one, like the year 0 AD (aka 1 BC).

I have this horror that people will still be using 1970 as the epoch in
the year 31,536.

Larry

Re: RFC 126 (v1) Ensuring Perl's object-oriented future

[Larry Wall]

[EMAIL PROTECTED] writes:
: To put it another way, no one should ever be tempted to do this:
: 
: $obj->{'attribute'}
: 
: for efficiency reasons inside a tight loop or what have you.  (And no,
: the solution is not to "use C when you need efficiency."  I shouldn't
: need to use portable assembler to access an object attribute
: efficiently.)  Whatever the syntax turns out to be, simple things like
: object attribute accessors should not only be faster than doing this
: in Perl 5:
: 
: $obj->attribute
: 
: they should even be faster than the naughty, encapsulation-destroying,
: implementation-revealing hash-lookup above.

Regardless of how fast they go, accessors are in some sense the
"correctest" way to access attributes, since they inherit correctly,
and hashes don't.  And the $obj->attribute syntax (or $obj.attribute syntax)
is much cleaner than any hash-based syntax.

The main downside of accessors is that you can't (currently) say

local $obj->attribute = 2;

: I don't think pseudohashes and such go far enough.  I don't want "faster
: hash-based objects" or just "faster method dispatch", I want real,
: honest to goodness classes with attributes and methods and such that are
: distinct, both in syntax and implementation, from other Perl data
: structures like hashes and arrays.

I'm not sure we have to throw out the orthogonality of OO to data
structure to get what you want.  And we're certainly not going to
introduce syntax just to have more syntax.  But we do have to add
enough syntax (or metasyntax!) that it becomes possible to turn a
clearly written class into an efficiently implemented class.  And if we
invent a metasyntax that makes this possible, we need to either settle
on a standard syntax/implementation or make sure that variant
syntaxes/implementations will interoperate, particularly under
derivation.

: I think it's important to focus on this so it doesn't get lost in all
: the discussion of new letters to tack onto "m/.../sogie" and new syntax
: for range operators and such ;)  And I think it's something that
: everyone can agree on, since there's a lot of benefit to be had, and no
: down-side that I can see.
: 
: Let's make Perl 6 an awesome language for object-oriented development.

Can't disagree with that, as long as we don't trade away too much for it.

Larry

Re: RFCs (Re: Ideas that need RFCs?)

[Larry Wall]

Nathan Torkington writes:
: Steve Fink writes:
: > We are NOT here to construct a radically better language. We are here to
: > design the underpinnings of one.
: 
: Perhaps.  And by "perhaps", I mean "no".
: 
: We're here to say what we'd like to see in the next version of Perl.
: These can be big things (currying) or small (hashes returned by
: functions instead of long lists).  We're giving input to Larry, who
: will then design the language.  We are just telling Larry what we
: would like, and why (i.e., which itch it would scratch).

And my current role is to turn everybody's view upside-down by pointing
out that currying is a small thing if you have the right hooks between
the lexer and the parser, while returning hashes instead of long lists
is a big thing if it implies the unification of object and hash
notations.  How exactly do you "slice" an object, currently?

: > If you have an idea that will "add value" to Perl6 but can just as
: > well be done after the groundwork for the language has been laid :
> out, then please do not write up an RFC on it. It'll just distract.
:  : I completely disagree.  If you want something in Perl, now's the
time : to ask.  We're going to have to nail down the language so people
can : begin writing grammars, data structures, regex engines, and so
on.  : There's no such thing as a small change if that change comes
*after* : people have begun coding.  That's called "feature creep", as
I'm sure : you know.

I don't mind "small" RFCs.  I expect some number of them will be end up
being classified as:  "Should be implemented in terms of X later."  But
that doesn't mean they don't encode real desires.

: So I want to encourage people to submit RFCs.  Yes, there are a lot of
: them.  That's Larry's problem, not ours.  It's one problem he's glad
: to have, I'm sure.

Number 5 is alive!  Not disassemble!  Need more input!

Larry

Re: Ideas that need RFCs?

[Larry Wall]

[EMAIL PROTECTED] writes:
: Bare C and bare C *are* the main culprits. They require
: the tokenizer to track expression semantics so that when it encounters a
: '/' or '?' it can tell whether a pattern is plausible in this place or
: whether they've reached a division or hook operator, respectively.
: 
: In fact, these two cases are the *only* semantic contexts that
: Text::Balanced has to track in order to parse almost any Perl code.

It's a good thing you said "almost".  Does it parse [*]] correctly?

: Of course, it cheats a great deal by slurring over most of the tokenization
: in the interests of speed.

Ya, a real Perl tokener has to apply operator/term disambiguation to a
great many ambiguous characters.  Some people have proposed to add more
of them.  :-)

Hmm.  What's the dot mean here?

func ^1.2, 3, 4;

Answer: depends on the prototype of func.

Does Text::Balanced take into account functions declared with a
prototype of ()?

Larry

Re: RFC 23 (v3) Higher order functions

[Larry Wall]

Nathan Torkington writes:
: The fact that other languages can implement it trivially doesn't mean
: that Perl can.  I'd like us to have realized what kind of internals
: support is needed for a language feature (e.g., optree duping for
: partially-evaluated subroutines) *before* speccing out the internals.

It really depends on what you mean by "implement".  This stuff is
syntactic sugar.  To the first approximation, syntactic sugar is
trivial to implement.

To the second approximation, the first approximation is totally bogus.

Larry

Re: RFC 76 (v1) Builtin: reduce

[Larry Wall]

Jarkko Hietaniemi writes:
: > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
: > > consider the $ and $b to be warts.)
: > > 
: > And anyhow, this will work just fine (see RFC 23):
: > 
: >   $sum = reduce ^a + ^b, @numbers;
: 
: I have been amply reminded of this, thanks :-)  (Too little time
: to spend on RFCs...)

Yes, but has anyone pointed out that

   @out = sort ^b cmp ^a, @in;

won't do what people will certainly think it ought to?

Larry

... as a term

[Larry Wall]

Randal L. Schwartz writes:
: if ($a == $b) { ... } # should this be string or number comparison?

Actually, it's a syntax error, because of the ... there.  :-)

But that reminds me of something I wanted a few months ago.

I'd entertain a proposal that ... be made a valid term that happens
to do nothing, so that you can run your examples through perl -c for
syntax checks.  Or better, make it an official "stub" for rapid
prototyping, with some way of getting a warning whenever you execute
such a stub.

Larry

Re: Things to remove

[Larry Wall]

Tom Christiansen writes:
: >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 words: $!\n";
:   while () {
:   $first = $1 if ?(^neur.*)?;
:   $last  = $1 if /(^neur.*)/;
:   }
:   print $first,"\n";  # prints "neurad"
:   print $last,"\n";   # prints "neurypnology"
: 
: Nothing a SMOP can't address, but for one liners at the least, the
: S part would seem to preclude the P part.

I don't think the S and the P are that preclusive.  For the example above
you can just say:

/(^neur.*)/ .. ""

If you want to be able to reset, then say

/(^neur.*)/ .. !$x++# reset with $x = 0;

Larry

Re: Pre-RFC: Require a warning on spaces after here-document "terminator"

[Larry Wall]

Ariel Scolnicov writes:
: I was asked to debug a weird Perl5 problem yesterday.  The code in
: question looked roughly like this (indented 4 spaces, but otherwise
: unchanged):
: 
: #!perl -w
: use strict;
: 
: print <

Re: ... as a term

[Larry Wall]

Ed Mills writes:
: But don't {} or {1} sort of do the same thing?

Well, { warn "Encountered stub"; (); } would be more like it.  But the
biggest problem with {} or {1} is that they don't resemble an ellipsis.

Larry

Re: Pre-RFC: Require a warning on spaces after here-document "terminator"

[Larry Wall]

[EMAIL PROTECTED] writes:
:> : I would like to see a compiler warning for this:
:> : "Spaces detected after apparent here document terminator", but
:> : preferably phrased better.
:> : 
:> : Are there any objections?
:> 
:> I object, vaguely.  I think it should just Do The Right Thing.
:> (I suspect it should ignore spaces on the left to.)
: 
: Hear, hear.
: 
: And whilst you're in a mood to ignore whitespace, how about C<$/ = "">
: terminating on C?

I'm more inclined to ignore $/ these days.  :-)

Larry

Re: ... as a term

[Larry Wall]

[EMAIL PROTECTED] writes:
: I take it the existing C<...> operator would be unaffected?

Essentially.  The lexer is (and will continue to be) quite aware of the
difference between terms and operators.

The interesting thing about ... is that you have to be able to
deal with it a statement with an implied semicolon:

print "foo";
...
print "bar";

Either that, or it's a funny unary operator that can take 0 or 1 argument.

That might let you parse these too:

print (1, 2, 3, ...) or die;

or this:

print 1, 2, 3, ... 4, 5, 6;

The problem with treating it as a low-precedence unary operator is that
it would appear to run *after* the following statement in our first
example above.  And I think it's more important that ... a run-time
warning than a compile-time warning.

Another option is to treat ... as a statement where a statement is
expected, as a unary/zero-ary operator where a term is expected.  (And
as the binary ... operator where an operator is expected, as it is
now.  On the other hand, the scalar range (flipflop) operator is so
seldom used now that we might steal its notation for range objects even
in scalar context, and provide the flipflop operator with a little less
syntactic sugar.)

But I'd be happy with just ... as a statement.  Dwimming the unary
operator may not be worth it.  Especially since it might be confused
with the binary operator.  Compare the unary operator in

print 1, 2, 3, ... 4, 5, 6;

with the binary operator in:

print 1, 2, 3 ... 4, 5, 6;

Larry

Re: Things to remove

[Larry Wall]

[EMAIL PROTECTED] writes:
: How about this then:
: 
: In a void context, C dumps the program's current opcode representation
: to its filehandle argument (or STDOUT, by default).

It's not clear to me that reusing a lame keyword for this is the
highest design goal.  Let's come up with a real interface, and then if
we want to reuse the (the presumably missing) dump keyword for some
method name or other, that's fine.  But we're currently designing it
from the wrong end.

Larry

Re: RFC: extend "study" to produce a fast grep through many regexes

[Larry Wall]

David L. Nicol writes:
: What if there were a faster way to do this, a way to C a
: group of regexes and have the computer determine which ones had
: parts in common, so that if $situation =~ m/^foo/ is true, the
: fifty rules that start ^bar don't waste any time.  At all.

Perl 4 did this sort of thing automatically without a study, at least
with respect to the first character that could match.  Of course, it
didn't do it with regular expressions in an array, but rather in
a "switch" structure.  And you had to bunch your tests right.  If
your regular expressions were in an array, you had to use eval.

So certainly there's room for an interface that can take multiple regex
objects and turn them into a single super regex.  I don't think the
code to do it necessarily belongs in the core, but it would certainly
have to be somewhat incestuous with regex innards.

Larry

Re: ... as a term

[Larry Wall]

[EMAIL PROTECTED] writes:
: We already have plenty of statements with implied semicolons:
: 
:   print "foo";
:   for @list {}
:   print "bar";

Yes, we do, and I'm trying to figure out how to write a prototype for
one of those.  :-) / 2

: I'd have expected:
: 
:  print (1, 2, 3, ...) or die;
: 
: to print
: 
:   12345678910111213141516171819202122232425262728etc

If you're into dwimmery, you could make all of these work, too:

print (1, 2, 4, ...)
print (1, 4, 9, 16, 25, ...)
print (1, 1, 2, 3, 5, ...)
print ('a', 'b', 'c', ...)
print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)

: BTW, I propose the this new operator be pronounced "yadda yadda yadda". :-)

If you want to save the world, come up with a better way to say "www".
(And make it stick...)

Larry

Re: ... as a term

[Larry Wall]

John Porter writes:
: Could you make it "evaporate" and compile time, just like the (proposed) qc()?

Hard to make it evaporate at compile time and still give a warning at
run time.  :-)

Larry

Re: Things to remove

[Larry Wall]

Dan Sugalski writes:
: What I've been hoping for is:
: 
: 1) The ability to dump the program and its current state out into something 
: that can be reloaded later. (Though filehandles and other 
: external-interface things make this tricky)
: 
: 2) The ability to dump out a variable and all its attached state into 
: something that can be loaded in later somewhere else.

Now all we have to do is make the program a variable, and the two
requirements become one.

Larry

Re: Ideas that need RFCs?

[Larry Wall]

Dan Sugalski writes:
: At 10:35 AM 8/19/00 +1000, Damian Conway wrote:
: >However, for Perl 6 I'd really like to see run-time access to the
: >Real Tokenizer (tm):
: >
: > use tokenizer;
: >
: > my $tree = tokenizer( $sourcecode );
: >
: >This would be dead handy for building source-code filtering modules,
: >rather than relying on the pseudo-parsing tricks we're currently
: >forced to use.
: 
: Well, sure. You couldn't write an optimizer, bytecode compiler, or bytecode 
: execution engine in perl if you couldn't do that... :)

I was wondering this morning whether we ought to write the Perl 6
parser as a set of recursive regexes.  Might make it easier to plug in
new productions on the fly.  And designing the parser around regexes
might indicate ways in which Perl's regexes are not yet powerful
enough.

Larry

Re: Things to remove

[Larry Wall]

Tom Christiansen writes:
: >2) The ability to dump out a variable and all its attached state into 
: >something that can be loaded in later somewhere else.
: 
: To hope to do this completely and correctly is courageous.
: 
: my @funx = ();
: for my $name (qw/violet purple cream/) {
:   push @funx, sub {
:   print "I'll take a $name one, please, with @_.\n";
:   };
: } 
: 
: dump \@funx;
: 
: Closures will be challenging. :-)

Well, scratch it hard enough and you'll see that we're just discussing
persistent continuations.

Larry

Re: Ideas that need RFCs?

[Larry Wall]

Randal L. Schwartz writes:
: > "Joe" == Joe McMahon <[EMAIL PROTECTED]> writes:
: 
: Joe> This is done by using SNOBOL's dynamic function evaluation and
: Joe> conditional assignment during a pattern match. To do this kind of
: Joe> thing in Perl, we'd need to be able to match a substring, and
: Joe> then call an arbitrary function in the middle of a pattern match,
: Joe> and to back out the call if the match failed.
: 
: Already done in 5.6. :)  "perldoc perlre".

At the moment, there's no way for the call to "fail".  Unfortunately.

Larry

Re: Perl should become PEARL

[Larry Wall]

Suresh Kumar R writes:
: Perl should become PEARL

Er, the folks at http://www.irt.uni-hannover.de/pearl/pearl-gb.html
might have something to say about that.

Larry

Re: RFC 45 (v1) || should propagate result context to bo

[Larry Wall]

Tom Christiansen writes:
: It would appear that altering &&/|| on LHS context would entail,
: in the list assignment scenario, calling that operand in list context
: and then deciding whether it were true or not by some "intuitive"
: means (almost certainly by using whether its element count were
: zero or non-zero).  You'd have to squirrel away those list values
: first to avoid re-evaluation, but this does not seem unduly onerous.

If a lazy list object were returned, it could even specify its own
boolean meaning.  Conventionally it would have the same meaning
as array currently has in a boolean context, but one can imagine
funny array types that pick their own meanings for:

@a->bool
@a->len
@a->num
@a->str
...

Larry

Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

[Larry Wall]

Bart Lateur writes:
: Apropos those extended mechanisms: couldn't we use the same mechanism as
: is currently in use for $!, for $@ too? I mean: $! in numerical context
: gives an error number, in string context a text string. Then
: 
:   die "I'm outta here: $!";
: 
: should assign both the numeric representation of $! and the new text
: representation, the custom text, to the current $@ (future $!).

Whatever you do with the string or numeric part, I think the new $! should
push the old $! onto its stack of the old exception objects.

: That numerical part could then form the basis of the extended exception
: mechanism. No, the programmer shouldn't memorize the error numbers:
: there should be predefined constants, like
: 
:   ERROR::filenotfound
: 
: which are numeric, and which could then be used for the catch switch.
: Well, maybe drop the "ERROR::" part for brevity -- but not for clarity.

I think I agree with the folks that say errors should be caught by
type, not by number.  Just as a for instance, you ought to able to
write a simple handler that catches any ERRNO-style error.

Larry

Re: RFC 127 (v1) Sane resolution to large function returns

[Larry Wall]

Chaim Frenkel writes:
: LW> P.S. I think we *could* let @foo and %bar return an object ref in scalar
: LW> context, as long as the object returned overloads itself to behave as
: LW> arrays and hashes currently do in scalar context.
: 
: Isn't this an internals issue?

Not completely.  The scalar value would visably be a built-in object:

@bar = (0,1,2);
$foo = @bar;# now means \@bar, not (\@bar)->num
print ref $foo, $foo->num, $foo->str, ($foo->bool ? "true" : "false");
^D
ARRAY3(0,1,2)true

One implication of this approach is that we'd break the rule that says
references are always true.  Not clear if that's a problem.  It's basically
already broken with bool overloading, and defined still works.

Larry

Re: RFC 127 (v1) Sane resolution to large function returns

[Larry Wall]

Dan Sugalski writes:
: And do we want to consider making this (and its ilk) Do The Right Thing?
: 
:(@foo, @bar) = (@bar, @foo);

We certainly want to consider it, though perhaps not in -internals.
You can talk about passing @bar and @foo around as lazy lists, and
maybe even do lazy list-flattening, but I don't see how that works yet,
even in the absence of overlap.  The basic issue here may come
down to whether the LHS of an assignment can supply a prototype for the
entire assignment that forces everything to be treated as objects
rather than lists.

That is, right now, we can only have a scalar assignment prototype of ($),
and a list assignment prototype of (@).  We need a prototype (not just
for assignment) that says "all the rest of these arguments are objects",
so we don't have to use prototypes like (;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@).
Or (\@*) for short.

Though if we let @foo and %bar automatically return refs in a scalar context
rather than booleans, we might write that as (;$).  ($*) for
short.  (Presuming * to be available if typeglobs go away.)

However we force non-flattening object lists in prototypes, there's
still the question of how you specify the use of an object list
prototype on assignment.  Hmm.

(@foo, @bar) \= (@bar, @foo);

Dunno if I like that or not.

Larry

P.S. I think we *could* let @foo and %bar return an object ref in scalar
context, as long as the object returned overloads itself to behave as
arrays and hashes currently do in scalar context.

Larry

Re: Larry's ALS talk summary

[Larry Wall]

Jarkko Hietaniemi writes:
: >   * XS, the system for extending Perl with C or C++, will be replaced
: > with something much easier to use.  This will give people very
: > convenient access to existing code libraries, and write C or C++
: > subroutines that can be called as Perl subroutines from Perl code
: > to take advantage of C's speed and memory flexibility.
: 
: I disclaim having any inner access to Larry's current thoughts on this
: but just as a datapoint check out the latest Perl Journal and its
: article on the Inline module.
: 
: Also, having recently been subjected to the pain and horrors, ummm,
: thrill and joys, of trying to use a very deeply C-like (1) library to
: from Java, allow me to voice my fervent, errr, humble hope that we
: steer clear of the JNI disaster (2).
: 
: (1) Synchronous and asynchronous callbacks implemented using
: function pointers and void pointers being used both
: as event type specific data containers and as user-specified
: opaque cookies.  Yum.
: 
: (2) There are 200+ functions in the JNI API -- but enough to do (1).
: I do understand that mapping a type-unsafe language to a type-safe
: O-O language is hard but the resulting API is simply disgusting,
: and even Sun admits this, slow as a drunken limping pig.

The hope is to extend Perl's subroutine declaration syntax (via types
and attributes) to the point where a "forward" declaration in Perl of a
C, Java, or C# routine can supply all the glue information formerly
supplied by XS.  While this will undoubtedly give us some rather
strange looking Perl, I'd rather look at potentially strange Perl than
certainly strange XS.

Larry

Re: Larry's Apocalypse 1

[Larry Wall]

David Grove writes:
: [1] Strongs is pure Koine. I'd think Larry would be more of the Ionic
: type. 

You might say I get a charge out of Homer.  :-)

Actually, I've done more Attic than Ionic.  And I haven't done enough
of any of them to get very far from my lexicon.  But I started Greek at
Seattle Pacific, and they've always stressed learning classical Greek
first, even if you're planning to concentrate on Koine later.

So I tend to stick with my Liddel and Scott, even when reading Koine.
Even though I don't believe that a word's current meaning is defined by
its etymology, I find that knowing the history of a word helps to keep
one from reading meanings into a word that were probably not layered
onto the word until afterwards.  Apocalypse is such a word.

Teachers of Koine have a bad reputation for being sloppy about these
things, but I have to say that my Greek teachers did not, even when
they were teaching Koine.  In particular, I vividly remember a lecture
by Ed Goodrick, Professor of Greek at Multnomah, in which he said:

Most Greek words are vanilla words.  I want you to remember that.
Many of you will go out from here and become preachers.  Someday
I'll come visit your church, and you'll be up there preaching a
stirring sermon to your congregation.  And in order to fire the
people up, you'll say that the Greek word "dunamai" means
"dynamite".  I warn you that if you do, I will stand up in the
middle of your sermon and shout, "It does not!" and then I'll sit
back down.  So don't do that.  You must always remember that
"dunamai" is a vanilla word.  It simply means, "I can."

So anyway, I stick with Liddel and Scott, who do a decent job of
covering Koine where it needs covering.  If I want a strictly NT view
of the word, I might occasionally dip into Bauer, Arndt and Gingrich.
My Strong's got used too many times as a booster chair, and died the
death, and I haven't bothered to replace it.

Though I'm old enough to remember the saw: Strong's for the strong,
Young's for the young, and Cruden's for the crude.  And much though I
despise making fun of people's names, the saying had some truth to it.

Incidentally, Prof Goodrick was coauthor of the first NIV concordance,
which was, as far as I know, the first that was computer-generated.

Well, enough of that.  Back to the future.

Larry

Re: Larry's Apocalypse 1

[Larry Wall]

Randal L. Schwartz writes:
: > "Nathan" == Nathan Wiger <[EMAIL PROTECTED]> writes:
: 
: Nathan> This is interesting, and in my gut I like it. Many people I've worked
: Nathan> with end up writing:
: 
: Nathan>@foo[0]
: 
: Nathan> Which works.
: 
: "Works", for some odd meaning of the word "works".  Ever try this:
: 
: @foo[0] = ;
: 
: and then wonder where all the *rest* of your input went?

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.  There will probably be optional modifiers before colon
for various reasons.  This has the result that we could distinguish an
inner:* operator from and outer:* operator.  (Labels would be required
to have whitespace after the colon, in this scenario.)

It also means that every operator has a function name, so you could
call inner:*(@a, @b) or @a->inner:*(@b) or some such.  It might even
mean that we can have a URL literal type, if we can figure out how to
parse it, and if there's any good reason to treat a URL as more than
just a string:

print $::OUT http://www.wall.org/~larry/index.html;

But I really mustn't spill too many half-digested beans here.  :-)

Larry

P.S.  Larry's Second Law of Language Redesign: Larry gets the colon.

Re: Larry's Apocalypse 1

[Larry Wall]

David Whipp writes:
: You may be right that there are no useful literals other than
: strings, integers, reals and lists. OTOH, if we are going to
: construct a meta-language which supports multiple syntaxes,
: then it is very likely that each application-specific language
: would have its own literals. The question becomes whether perl
: itself should have this ability.

What he said.  To my mind, the question boils down to limiting the
scope of a syntactic rule borrowed from another lingo.  So I can see
some potential in a general literal syntax resembling FOO:BAR where the
FOO class predeclares the method to parse and interpret the string
"BAR".  (Larger scopes are also possible with other syntax, of course.)

The fact that this would make it possible to have an http literal is
interesting to me, but that's not the main point.  (In fact, this whole
debate about whether the http class should be built-in or not is rather
beside the point from my perspective.  It's defined by a class, so
we can do it either way.  We can decide it one day before we ship 6.0.0.)

The fact that this metasyntax might also allow names of operator
variants to be disambiguated is also somewhat beside the point.  The
point to me is the extension mechanism, not the extensions.  The only
reason I'm looking at some of these possible extensions is to see some
of the directions such a mechanism might be taken.

Just because the general is visiting a particular trench doesn't mean
he plans to set up headquarters there.  There are broader issues at
stake.  So I'd appreciate it if my soldiers would refrain from killing
each other over what color to paint the foxhole.

Larry

Re: Larry's Apocalypse 1

[Larry Wall]

Dan Sugalski writes:
: If we're going to provide a mechanism to define the syntax of 
: a mini-language (or a maxi one, I suppose, though there are probably better 
: ways to do it) then the details of colons and constants and what-have-yous 
: are pretty close to irrelevant.

I expect that most of these lingos will want to redefine the small
stuff rather than the big stuff.  So if you're a numerologist you might
want to redefine how subscripts are parsed or some such without
changing anything outside of subscripts.

: If we can redefine the entire world then, well, we can redefine the world. 
: It doesn't really much matter the shape of Africa if we're building Europa.

Well, sure, but if you're only interested in Africa you shouldn't have
to respecify Europa.  We already have a sledgehammer with source
filtering, and that has demonstrable problems--ask any Damian.  That's
why I said that such things need to be scope limited.  I expect most of
the sublingoes to be barely distinguishable from Standard Perl except
for some narrow slice of oddity.  It's really just applying to syntax
munging the same principle we apply to variables.  We declare our variables
in the smallest possible scope if we want to avoid unforeseen interactions
with other code elsewhere.  Similarly, syntactic munging should only
tweak that smallest part of the grammar that it can get away with to
accomplish what it needs to.

Larry

Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)

[Larry Wall]

Dan Sugalski writes:
: At 10:16 AM 4/17/2001 +0100, Tim Bunce wrote:
: >On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote:
: > > People seem to think that telling Perl 5 apart from Perl 6 is trivial.
: >
: >My reading of Larry's comments is that it will be _made_ trivial at the
: >file scope level. If the file doesn't start with Perl 6 thingy then
: >it's Perl 5. Period.
: 
: I think you (and we) are reading too much into the comments around this. 
: They're all in the "RFC 16: Keep default Perl free of constraints such as 
: warnings and strict" section. I've been reading them as setting perl's 
: default warning and stricture levels, but that's not necessarily the intent.

Well, it was in A1 because it addressed large issues, some of which I
punted on.  In particular, the degree of stricture in the main program
when we know it's Perl 6.

: As for default perl 5-ishness, while there's language that says we assume 
: perl 5, there's also a paragraph in there that says having to declare we're 
: really perl 6 sucks, too.

I think it's going to turn out pretty easy to distinguish Perl 5 from
Perl 6 (the standard dialect).

Consider that in Perl 6, modules might not be imported with "use".
Instead, they will might well be declared with "my" and "our" to
indicate whether you want the module definition to be scoped to your
current package or your current lexical scope.

So a Perl 6 program that wanted to invoke the "bad" pragma might start out:

my bad;

:-)

We know the use syntax has to change anyway to deal better with versioning
and aliasing, so we might as well break it correctly.  We may end up with
aliased modules looking like this:

my http is Foo::Bar::Http:GSAR:3.0.1 ...

As for what we currently do with "use", I'm not sure the exact syntax
yet, but since "use" currently imports ordinary modules to the package
space, the p526 translator might turn non-pragmas into some kind of an
"our" declaration.

Anyway, just some more ballistic ideas to randomize all your eyeballs.

Larry

Re: Larry's Apocalypse 1 \}

[Larry Wall]

Dan Sugalski writes:
: At 12:17 AM 4/20/2001 -0500, David L. Nicol wrote:
: >Recursive parsing is not needed.  We have the HERE string, which can
: >  include anything in with the rest of the code, by looking for the
: >  end-token.  The perl5 Inline module works that way.

Indeed, Perl 5 works that way.  But not necessarily Perl 6.

: I'm not a parser guy by any means (unfortunately) but we have the distinct 
: possibility of completely replacing all of the parser rules after token X 
: appears, whatever that token might be.

Yes, consider that rule replacement is essentially what happens in any
parse.  Whenever you run into a quoting operator, for instance, you're
switching to a different "microlanguage" that understands the following
text differently from the preceding text.  It's just that, in a
standard grammar, the rules are immutable.  All we're really doing for
Perl 6 is specifying that grammar rules can have just-in-time binding.

And switching complete grammars can be thought of as merely installing a
new top-level rule.  If you think of grammars in OO terms, installing
new rules is a form of derivation, and switching grammars is merely
telling the parser to use a different parser object class either permanently
or temporarily.  (Recall that what looks like lexical scoping to
the program at run time is really temporal scoping at compile time.
>From the standpoint of the compiler, it's as simple as push_grammar($new)
at the beginning, and pop_grammar() at the end.  Or maybe even just
temp $grammar = $new.)

But I digress.

: (Heck, we may have the possibility of replacing the entire parser)

Indeed, I think it's quite likely that Perl 6's migration parser for
legacy Perl 5 will in fact be Perl 5's current C parser grafted onto a
Perl 6 syntax tree generator.  That would preempt a bunch of problems
involved in trying to reconstruct exactly how the Perl 5 parser thinks,
which nobody entirely understands.  With this approach we need only
remap the semantics across, and then deparse or run the Perl 6 syntax
tree as appropriate.

To be sure, we'd have to tweak the Perl 5 parser to remember extra
information such as formatting and comments.  And it's possible that
someone will write a Perl 5 parser using Perl 6's parsing engine simply
for the fun of it, or for the educational value.  In which case, all
bets are off as to which way we go.  In any event, the long term goal
is for the Perl 5 parser to be deprecated at some point and eventually
jettisoned.  For some embedded applications (places where Perl doesn't
currently fit), the Perl 5 parser may not even be available from the
start.

But I digress.

: There's no guarantee the non-perl-6 section 
: will have a nice end-delimiter for us to find. Granted that won't be the 
: case all the time, but it's certainly quite feasable. We might not even be 
: able to rely on perl's definition of a token. (Or whitespace for that 
: matter--Whitespace isn't just whitespace in python mode)

That is correct.  Standard Perl 6 will end up working a lot like Perl 5,
but that's by convention, not by restriction.

Larry

Re: Tying & Overloading

[Larry Wall]

=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes:
: I _really_ think dot-syntax would make perl prettier as well as make it
: more acceptable to the world of javacsharpbasic droids. Which is some
: kind of goal, no? 

Consider it a given that we'll be using . for dereferencing.  (Possibly
with -> as a synonym, just for Dan. :-)

: I suspect that we will never agree on anything here though.

I suspect we will.  :-)

: Which of qw[~ ++ +~ + &] do we dislike the least?  Using + would be
: nice, but introduce no end of problems with number/sting behaviour. '&'
: is too much like a certain unpopular language. And there was no end to
: the quabbling :(

++ is out becuase you can't have the same operator as both postfix and infix.
& is out because it'll stay bit-fiddly.
+ is out because it will add numbers.
+~ is out because I'd really like to have a single character for something
as common as concatenation.
(And juxtaposition is out because we're not going to destroy indirect
object syntax

I'm thinking concat will be ~.  Furthermore, I'm thinking unary ~ will
be stringify, and unary ^ will be bit complement, on the theory that
bit complement is like xoring with 0x.  And unary + will be a
numify, not a no-op.

: If we can make the concatenation into something else, we free the dot to
: do "string".length() and innumerable other niceties.

Indeed.  Though of course that's not related to the syntax of . vs ->, which
could be taught to do the same thing.

: ps. What do you think about the following sentence: "we should steal
: more from ruby"? a) disgusting, b) uninteresting, c) clever, d)
: wonderful.

Well, whatever you think, we would have to steal it from the 1/3 of
Ruby that wasn't stolen from Perl.  :-)

: pps. if ($_ === qw(b c d)) {
:   "=== 'is in' operator", 
:   "dot operator remapped to mean",
:   "objectspace array/iterator as in ruby, giving access to all existing 
:data (but of course more complete than rubys rather flaky
: implementation",
: }

If we don't install such features directly, we at least want to make it
easy to install them.  For instance, we'll definitely have easy ways
of writing code blocks that can function as iterators.  And it would
be relatively easy to install a universal .each method that calls such
a code block, so you could, if you like, do a Rubyesque thing like

@dogs.each { $^.bark };

Depending on how HOF rules end up interacting with method prototypes,
we might even get:

@dogs.each $^.bark;

But it's probably clearer with the curlies.  On the other hand, it's
possible that if @dogs (as an array) doesn't have a bark method, but
each Dog scalar does, then

@dogs.bark;

might do the right thing.  I dunno about that yet.  We can't just
assume the method is distributed over the array, or we won't be able to
get to methods resembling length(@dogs).

Larry

Re: Tying & Overloading

[Larry Wall]

Stephen P. Potter writes:
: Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @,
: and % characters?  
: 
: @foo = @a @+ @b;  # element by element add

Because it's difficult to tell the operators from the terms visually.

Larry

Re: Tying & Overloading

[Larry Wall]

Nathan Wiger writes:
: Larry Wall wrote:
: > 
: > : I _really_ think dot-syntax would make perl prettier as well as make it
: > : more acceptable to the world of javacsharpbasic droids. Which is some
: > : kind of goal, no?
: > 
: > Consider it a given that we'll be using . for dereferencing.  (Possibly
: > with -> as a synonym, just for Dan. :-)
: 
: 
: 
: > + is out because it will add numbers.
: 
: FWIW, if we're going to go "all the way" and make Perl's objects .-based
: (which I personally dread, but oh well),

The . is just syntax.  Do you mean something semantic by ".-based"?

: then we should adopt the "+"
: for string concat as well. Yes, I know that string concat isn't
: commutative and all the other stuff, but who cares?

I don't care about commutative either, but what you are proposing is to
throw away a particularly useful feature of Perl, which is its
autoconversion between numbers and strings.  That we're not going
to lose.  This implies that string operators must stay distinct
from numeric operators.

: Sometimes taking
: what other languages do just because it's widely used is worthwhile. I
: personally don't know of any other language that uses "~" for string
: concat. Does anyone else?

Doesn't ~ look like a piece of string to you?  :-)

I think it kind of looks like a stitch.

: Besides, if everything's an object and you have a vtable/whatever PLUS
: method, then why shouldn't:
: 
:print "The next loop will be " + $i + 1 + "\n";
: 
: DWIM?

Then how do you concatenate a number?

: As a segue for a second, we should keep in mind which types of people
: we're trying to satisfy. I personally don't care at all if Perl 6 is
: more popular with Java and C# people than Perl 5. But I definitely don't
: want it to be less popular with Perl folks (like me).

Me either.  But then you propose to break one of the most endearing
features of Perl 5.

: With the proposed
: changes in this thread so far, you've got:
: 
:P5  P6
:--- ---
:->  .
:.   ~
: 
: For no net gain.

For no *perceived* net gain.  Let us be precise.  :-)

There are many people who would prefer . to ->, if for no other reason
than it's cleaner looking and is one less character to type.  The fact
that it's become the industry standard for method call syntax is also
a point in its favor.

Incidentally, Perl 6 will not require . everywhere that Perl 5 requires
->.  The deref will be assumed before (), [], and {} (where an operator
is expected).  We're only talking about method calls here, really.

: I know we're just brainstorming still,

Well, maybe we are, at that.  But I feel as though I've been in design
mode for a while now.  That is, any brainstorming I'm doing at this
point is merely to feel my way into the ramifications of making some of
the hard-nosed decisions that have to be made.

: but -> is not an
: oddity to Perl. There are other languages (like C) that use this.

To be fair, C also has the . variant, so there's certainly prior art on
the other side as well.

: And personally I think Perl is far more effective as a C-sh/cgi glue than a
: Java-.Net glue.

I think Perl is still suboptimal as C glue, and we can improve it.  If
it becomes better VM glue at the same time, all the better.  But I fail
to see how . notation can be much of a political issue, unless people
choose to turn it into one.

: The latter space is already populated w/ Java and C#,
: and Sun and MS have a little bit of marketing cash.

And because they have better marketing we should therefore concede in
the technical sphere?  I don't follow.

: Just my own personal feelings. I don't want Perl 6 to be a complete
: disregard for Perl 5, but rather an improvement over it (RFC 28, you
: know...).

The question is, what is the essence of Perl 5?  There are many
different levels on which we can conserve the spirit of Perl 5.
Syntactic continuity is merely one of those levels.  An important
level, to be sure, but not inviolate.  Not this time.

Larry

Re: Tying & Overloading

[Larry Wall]

[EMAIL PROTECTED] writes:
: Okay, then:
: 
: @foo = @( @a + @b );# @(), $(), and %() set context.
: 
: Easier to identify the operators, and little or no question about the
: context...

Well, sure, though it was already in list context from the assignment...

I do expect that @() and $() will be used for interpolating list and
scalar expressions into strings, and it is probably the case the $()
would be a synonym for scalar().  @() would then be a synonym for
the mythical list() operator.  Which probably, in Perl 6, turns out
to be equivalent to [...] when used in a scalar context, and a no-op
in list context.  That is, $() and @() would essentially be typecasts.

Larry

Re: Tying & Overloading

[Larry Wall]

Glenn Linderman writes:
: Why not
: 
:@foo = @( a + b );   # element by element add of @a and @b

I expect that's be written:

@foo := @a + @b;

where the := says to treat the left side as a prototype, and a bare
array in a prototype is going to put scalar context on the right side,
and a + in scalar context is going to do the right thing with arrays
in scalar context.  It's possible that a bare = could be made to work
too, but it implies copying a list, where := only implies copying
a pointer.

Larry

Re: Tying & Overloading

[Larry Wall]

Graham Barr writes:
: On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote:
: > I do expect that @() and $() will be used for interpolating list and
: > scalar expressions into strings, and it is probably the case the $()
: > would be a synonym for scalar().  @() would then be a synonym for
: > the mythical list() operator.  Which probably, in Perl 6, turns out
: > to be equivalent to [...] when used in a scalar context, and a no-op
: > in list context.  That is, $() and @() would essentially be typecasts.
: 
: Hm, I would expect @() in a scalar context to give the
: same result as
: 
:   @tmp = @(...); $x = @tmp;
: 
: That is, yeild the number of elements in the list.

Well, it does, but it does it differently.  After the assignment, $x
contains a pointer to @tmp.  However, if you say $x where a number is
wanted, you still get the length.  If you're worried about the delayed
operation, you can force numeric context with $x = +@tmp;, just as you
can force string context with a unary ~.

: What would be the benefit of it being the same as [...] ? It would be
: one more character.

It's not the same.  It's a cast, not a composer.  It only comes out the
same in scalar context by accident.  In string context, it
interpolates.  In list context, it does nothing.  The behavior of
emulating [] in a scalar context really stems from the more basic
notion that lists in Perl 6 should behave more polymorphically,
emulating the behavior of Perl 5 where it can.  So when you say

for ($i = 0, $j = 0; $i < 10; $i++, $j++) {
}

The C-style comma operator would actually no longer be defined quite
the same.  Rather, it's notionally producing a list that gets discarded
in void context.  In the rare case that you're really interested in the
last value of a list, use ()[-1] instead.

All subject to Rule 2, of course.  :-)

Larry

Re: Tying & Overloading

[Larry Wall]

Bart Lateur writes:
: Or, in analogy to "cmp", "gt" etc:
: 
:   $a = $b plus $c;
: or
:   $a = $b cat $c;

It would probably have been C if it had come to that.

Larry

Re: Tying & Overloading

[Larry Wall]

Simon Cozens writes:
: On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote:
: > :@foo = @( a + b );   # element by element add of @a and @b
: > I expect that's be written:
: > 
: > @foo := @a + @b;
: 
: Two different assignment operators? I can understand the intent, but this kind
: of difficult-to-remember special-casery is the sort of thing that *already*
: gives Perl a bad press.

It's not special casery.  It's a fundamentally different kind of
assignment, such as you find in Ruby, and the rules applied to the left
side of such an assignment will be identical to the rules applied to a
function prototype/signature.  The := will assume it's assigning
scalar objects unless it's explicitly instructed otherwise.

: Think about the question "Does this vastly increase or vastly decrease the
: program-breaking potential of a mistake made by a novice Perl 6 programmer?"

I have thought about it a lot, actually.  Why do you think this is
taking so long?  :-)

: >From a trainer's point of view, having two operators which look very similar,
: are used for the same thing in various different languages, and do *almost*
: the same thing but not quite, is completely *asking* for confusion.

So teach 'em :=, and outlaw = with some kind of stricture.  That'll
save a heap of newbie confusion with == too.  The = would only be there
for compatibility anyway, when you want an old-fashioned Perl
assignment that attempts to dwim the list/scalar context.  But it's
redundant, in the sense that function signatures will have sufficient
power to write the equivalent to = using := notation.

And I don't care if it looks like Pascal, so don't try that argument.  :-)

Larry

Re: Tying & Overloading

[Larry Wall]

John Porter writes:
: Larry Wall wrote:
: > I do expect that @() and $() will be used for interpolating list and
: > scalar expressions into strings, and it is probably the case the $()
: > would be a synonym for scalar().  @() would then be a synonym for
: > the mythical list() operator.  Which probably, in Perl 6, turns out
: > to be equivalent to [...] when used in a scalar context, and a no-op
: > in list context.  That is, $() and @() would essentially be typecasts.
: 
: Yay!  Then we're nine tenths of the way to highlander variables!

Except we're not having highlander variables.  $foo and @foo remain
distinct entities.

Larry

Re: Tying & Overloading

[Larry Wall]

[EMAIL PROTECTED] writes:
: On 4/23/01 3:25 PM, Larry Wall wrote:
: > : >From a trainer's point of view, having two operators which look very
: > similar, : are used for the same thing in various different languages, and do
: > *almost* : the same thing but not quite, is completely *asking* for confusion.
: > 
: > So teach 'em :=, and outlaw = with some kind of stricture.  That'll
: > save a heap of newbie confusion with == too.  The = would only be there
: > for compatibility anyway, when you want an old-fashioned Perl
: > assignment that attempts to dwim the list/scalar context.
: 
: Then why not use = to do what you want := to do, and make := do what the
: Perl 5 = does?  Poor, confused Perl 5 programmers, I know.  But if the ":=
: functionality" is the common case for Perl 6, why make everyone type := all
: over the place when they could be typing = ?

Don't think I'm not tempted.  But I'm not sure if people will take to

@foo = @bar;

no longer implying list context by default.

: > And I don't care if it looks like Pascal, so don't try that argument.  :-)
: 
: I'm just trying to save a (chorded!) keystroke in every assignment... :)

Now that's a good argument.  :-)

Larry

Re: s/./~/g

[Larry Wall]

Branden writes:
: I'm starting to be a bit worried with what I'm reading...
: 
: 1) Use $obj.method instead of $obj->method :
: 
: The big question is: why fix what is not broken? Why introduce Javaisms and 
: VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 
: code (and Perl 5 programmers) for a zero net gain?

It's not zero net gain, and I'm going to ignore the next person who says it.

: 2) Use $a~$b instead of $a.$b :
: 
: The same argument, only stronger now. This one still poses another problem: 
: for $a = $a ~ $b, the syntax would be $a ~= $b. Now read these two quickly 
: and tell me what's the difference
: 
: $a~=$b;
: $a=~$b;
: 
: It's not only hard to teach the =~ operator, imagine teaching that there 
: are two of them... Imagine if a programmer writes the wrong one, how long 
: you'll have to wade through that code until find the bug!

We have lots of operators you wouldn't want to reverse by accident.

: 3) Introduce := and deprecate = :
: 
: Ok, nobody told = would be deprecated, but I've actually read that := would 
: do everything = does, so that = could be forgotten. Now, why not extend =, 
: instead of adding this Pascal-ism to Perl?

That's still a possiblility.

: I agree that Perl should get ideas from the maximum of languages, 
: including, of course, Java, VB, Pascal. I just don't see why introduce 
: syntatical elements of those languages, since the ideas could be done with 
: Plain Old Perl Syntax, that one inspired in the language for real 
: programmers, C, as it has always been through time.
: 
: What I mean is, when I first say Ruby, I thought: That looks like a cool 
: language, it has most features of Perl, and supports some neat things Perl 
: doesn't... But when I saw it's Java-like syntax, I thought: Forget about 
: it! Perl syntax rules!

What is it about . that seems to inspire allergic reactions in people?
Surely it's not the . itself, but the requirement that you fit everything
into that one syntactic mold.  Perl's not going to do that.

: The bottom line is: please don't change the syntax, unless it's 
: unavoidable. It will cost many time of reading code until finding bugs 
: because of operators that used to work and don't work anymore...

That is a consideration, but there's no such thing as absolutes here.
All change is avoidable at some price.  I don't intend to pay that price.

Larry

Re: s/./~/g

[Larry Wall]

John Porter writes:
: Larry Wall wrote:
: > Surely it's not the . itself, but the requirement that you fit everything
: > into that one syntactic mold.  Perl's not going to do that.
: 
: I'm not opposed to the change, but I want to make one point:
: certain characters (like dot) are special in regexes, so
: when you want to search for them, you have to escape them,
: whether in vi, or with grep, or perl, or whatever.
: String concats with dot are uncommon enough; but member
: access is quite common.

Okay, but it's just as many characters to say -> as it is \., y'know.

There *is* one place where it's more problematic to use ., and that's
interpolating method calls.  For this reason, method interpolations
are likely to require parentheses, even if there are no arguments.
Otherwise "$file.ext" is gonna break badly.

Larry

Re: Larry's Apocalypse 1 \}

[Larry Wall]

David L. Nicol writes:
: Dan Sugalski wrote:
: > I'm not a parser guy by any means (unfortunately) but we have
: > the distinct possibility of completely replacing all of the
: > parser rules after token X appears, whatever that token might
: > be. (Heck, we may have the possibility of replacing the entire
: > parser) There's no guarantee the non-perl-6 section will have a
: > nice end-delimiter for us to find. Granted that won't be the
: > case all the time, but it's certainly quite feasable. We might
: > not even be able to rely on perl's definition of a token. (Or
: > whitespace for that matter--Whitespace isn't just whitespace in
: > python mode)
: 
: 
: sounds a lot like an "exec" system call: there are some things
: which remain in effect (open file handles, current directory,
: environment) but there are many others which do not.  Maybe
: switching parsers is best an absolute kind of thing rather than
: a stacked kind of thing, with the later parser responsible for
: switching back.  

The truth is somewhere in the middle.  It is incumbent on the outer rule
to inform the inner rule how it thinks the inner rule ought to terminate,
and it is the choice of the inner rule whether to follow the convention
suggested by the outer rule.  A rule that starts at a left parenthesis
will suggest stopping on a right parenthesis, but if the inner rule
is parsing troff, all bets are off on properly nesting parens.

Larry

Re: Strings vs Numbers (Re: Tying & Overloading)

[Larry Wall]

Bart Lateur writes:
: On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
: 
: >Using + for concat: no!
: >
: >My vote is to use . and require space before and after.
: >$this.$is.$ugly.$anyway ;)
: 
: My vote is to ditch the concat operator altogether. Hey, we have
: interpolation!
: 
:   "$this$is$just$as$ugly$but$it$works"

At the moment I'm leaning toward ^ for concat, and ~ for xor.  That
will help with ^= not resembling =~, though ~= would still mean The
Wrong Thing...

HOF is not an issue, since those will be $^whatever.

: Which reminds me... one problem I have with it is that it's too hard to
: separate a variable name from the rest of the string, if it also
: consists of word characters:
: 
:   my $bar = "BAR";
:   print "foo${bar}baz";  -> fooBARbaz
: 
: Since $bar is a lexical variable, this syntax doesn't make much sense
: anyway: it reeks of symbolic references and those don't work for
: lexicals.
: 
: I think I'd like something incorporating a backslash would be nicer:
: 
:   print "foo$bar\Ebaz";
: 
: It works, but it may have unwanted side effects -- in case the "\E"
: actually serves a purpose.
: 
: But, you may completely forget about it. I just had to say this one day.

No, I already thought of that one yesterday, and I agree with you completely.
Though \E is probably not it.

Well, they're calling my flight, so I'd better shut down.  (On layover
in Phoenix.)

Larry

Re: Strings vs Numbers (Re: Tying & Overloading)

[Larry Wall]

Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
: 
: $hashref.{ }
: 
: be that desirable? I really like ->{  } in that case..

It won't be either of those.  It'll simply be $hashref{ }.

Larry

Re: Strings vs Numbers (Re: Tying & Overloading)

[Larry Wall]

Edward Peschko writes:
: Ok, so what does:
: 
: my %hash = ( 1 => 3);
: my $hash = { 1 => 4};
: 
: print $hash{1};
: 
: print?

4.  You must say %hash{1} if you want the other.

Larry

Re: Strings vs Numbers (Re: Tying & Overloading)

[Larry Wall]

Bart Lateur writes:
: Ok. So how about hash slices? Is $hash{$a, $b}, the faked
: multidimensional hash, going to go?

Yes, fake multidimensional hashes will be defenestrated.

Larry

Re: Strings vs Numbers (Re: Tying & Overloading)

[Larry Wall]

Bart Lateur writes:
: Er... hip hip hurray?!?!
: 
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs. A highlander
: variable would get you that: that if a hash %foo exists, the scalar $foo
: would automatically be a reference to that hash.
: 
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?

$foo{THERE} always means the hashref in $foo.  %foo{THERE} always means
the hashref in %foo.  %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref.  &foo by itself in
a scalar context means a coderef.  It's gonna be pretty consistent.

Likewise, bare @foo, %foo, &foo in function prototypes will default
to supplying a scalar context, so they don't eat arguments.  The final
argument will have to be specifically marked if you want it to eat
up arguments.  And we'll probably distinguish eating a list in list
context from eating a list of scalars, so you could pass a list of
arrays easily to a variadic function with each variable name in
scalar context so as to produce a reference.

This is a little hard to explain, but I intuit that it will turn out to
be intuitive.

Larry

Re: Flexible parsing (was Tying & Overloading)

[Larry Wall]

Eric Roode writes:
: John Porter wrote:
: >IIUC, this ability is precisely what Larry was saying Perl6 would have.
: 
: I may have my history wrong here, but didn't Ada try that?

Not at all.  The syntax of Ada was nailed down tighter that almost any
language that ever existed.

: Super-flexible, redefinable syntax? And wasn't the result that nobody could
: read anybody else's code, so Standards Committees were set up to 
: define Legal Styles that basically reduced the syntaxes that you could
: use to just the One Standard Style?

Gee, you must be thinking of K&R C.  :-)

In any event, I'm not worried about it, as long as people predeclare
exactly which variant they're using.  And I'm also not worried that
we'll have any lack of style police trying to enforce Standard Perl 6.

Larry

Re: Flexible parsing (was Tying & Overloading)

[Larry Wall]

Dan Sugalski writes:
: And on the other hand you have things like Forth where every program 
: essentially defines its own variant of the language, and that works out 
: reasonably well. (Granted it's more of a niche language, especially today, 
: but that's probably more due to its RPN syntax)

Perhaps.  I would also attribute Forth's lack of success in part to its
lack of standardization, but only in conjunction with its lack of
standardization, if you take my meaning.  The core distribution was
too small to establish a common culture.  Despite the fact that we're
trying to pare down the actual core core of Perl, I don't think the
standard distribution is going to fall into the error of providing
too little guidance on cultural matters, if for no other reason than
we must minimally provide for translated Perl 5 programs.

I would also argue that Forth's diversity was driven in part by its
lack of support for other programming paradigms.  I don't see Perl
falling into that trap any time soon either...

Larry

Re: a modest proposal Re: s/./~/g

[Larry Wall]

Nathan Wiger writes:
: Now, it may be that all the "We should use ." people are just keeping
: quiet, or think it's obvious why this is a benefit, but I'm unconvinced.
: Again, I'm open-minded, but the only argument I've really heard is to
: make Perl more Java/Python-like. This doesn't sway me at all. Are there
: other reasons?

Yes, there are, but I don't really want to write Apocalypse 12 before
I finish Apocalypse 2.  However, I can tell you that object attributes
will likely be declared as special variables within a class like this:

my $.foo;
my @.bar;
my %.baz;

and henceforth be usable as either methods or as data values (but the
latter only within the object methods of the class).  It is also a
distinct possibility that unary . will be used to indicate methods called
on the current object.  This would avoid both the problems of trying
to come up with an agreed-upon name for $self/$this/self/me/whatever,
but also avoid the problem of C++ where a method call is not visually
distinguished from a function call.

Anyway, I wish you folks would stop arguing about heroic measures to
rescue the . operator for concatenation.  It's not going to happen.
I want people to associate .foo with the idea of methods and attributes
about the way they associate $foo with scalars currently.  This won't
happen if we overload it, and I'm pretty picky when it comes to the
psychology of the thing.

And I'm tired of hearing the argument that Perl programmers can't get
used to a different operator for concatenation.  I know better--after
all, Perl is probably what got them used to . in the first place.  If
you can teach dogs to salivate at a bell, you can probably teach them
to salivate at a dog biscuit.  :-)

Larry

Re: Flexible parsing (was Tying & Overloading)

[Larry Wall]

Dan Sugalski writes:
: It's also the one reason that I really like the idea of policy files of 
: some sort, to allow sites that don't want this sort of thing to forbid it. 
: I'm not talking things like perl automagically loading policy files in. 
: Rather having "use site_policy;" set limits that can't be undone at all 
: easily, or something like that. Site management can mandate its use and 
: wield the appropriate baseball bat if it isn't followed.

If the site refuses to install the module that tweaks the syntax, that
will enforce site policy quite effectively.  It's possible that we could
take an administrative approach to make sure all such modules go into
Tweaks:: or some such, so they can be easily detected.  I'm reminded that
you couldn't get Ada to do dangerous things without saying

with UNCHECKED_TYPE_CONVERSION;

or some such glaring declaration at the top.

On the other hand, people don't generally declare which dialect they're
going to speak in before they start speaking.  So there's some balance
point in there somewhere, or maybe a set of balance points to be
balanced.  The trick is to give Perl a wide dynamic range of easily
enforced balance points, not to enforce any particular one.

Larry

Re: Flexible parsing (was Tying & Overloading)

[Larry Wall]

John Porter writes:
: Larry Wall wrote:
: > On the other hand, people don't generally declare which dialect they're
: > going to speak in before they start speaking.  
: 
: On the other other hand, perl already embraces the philosophy
: of pre-declaring things that change the language.  That's what
: a pragma is.  Even "my" could be construed this way.

Certainly, sorry I wasn't clear.  I wasn't suggesting that Perl try to
intuit the dialect--I was just pointing that out as the opposite end of
the continuum from the bureaucratic red tape of trying to ask the
government permission to use non-French words in a legal document.  :-)

For good or ill, a computer program is more like a legal document than
a bedtime story.

Larry

Re: Flexible parsing (was Tying & Overloading)

[Larry Wall]

Dan Sugalski writes:
: Besides, having the site administrator forbid the installation of parser 
: tweaks might not be what is wanted. If we get PPython in there, a site may 
: well have a Python.pm module handy, and source might start:
: 
:use site_policy qw(Python);
: 
: for modules that were all-Python, or
: 
:use site_policy qw(Perl);
: 
: for ones that were all-perl. The site-policy file would, amongst other 
: things, perhaps lock down the parser so you couldn't switch languages in 
: mid-file.

I think we have to be careful here.  We should ask people to name site
policy files after their site, and not use a generic name like
"site_policy", since we'd be likely to end up with 20 different
"standard" site_policy files wandering around the net.  So something
like

use OReilly::Policy;

or

use Mongolian::Navy::ProcurementOffice::Policy;

might be more in order.

Larry

Re: a modest proposal Re: s/./~/g

[Larry Wall]

Simon Cozens writes:
: Hey, that would make "_ _ __" legal Perl code. Abigail, Abigail!

Now we just need to make "... ___ ..." mean something exceptional.

: (I still prefer ~, but acknowledge that this is just bikeshed painting.)

Bikesheds need to be painted occasionally.

Larry

Re: Flexible parsing (was Tying & Overloading)

[Larry Wall]

[EMAIL PROTECTED] writes:
:> use OReilly::Policy;
:> 
:> or
:> 
:> use Mongolian::Navy::ProcurementOffice::Policy;
:> 
:> might be more in order.
: 
: You Americans and your non-ISO penchant for putting the specific before
: the general. Surely that should be:
: 
: use Policy::O::Reilly;# really gonna miss that ' package separator 
:;-)
: 
: or
: 
: use Policy::Mongolian::Navy::Office::Procurement;

Well, I did say "more in order".  I didn't say how much more.

: Next you'll be putting the month and day before the year in dates!

No, that isn't next, that was previous.  Perhaps, being hemispherically
challenged, you're looking at it upside down.  (-:, er, that is, :-)

Larry

Re: Flexible parsing (was Tying & Overloading)

[Larry Wall]

Dan Sugalski writes:
: I hadn't really considered having a separate module for each type of site 
: policy decision.

Er, neither had I.  Each site only has one policy file.  I just want it
named after the actual site, not some generic name like "Policy".  I
think policy files are inherently non-portable, so they should be named
that way.

Larry

Re: Please make "last" work in "grep"

[Larry Wall]

Michael G Schwern writes:
: (grep {...} @stuff)[0] will work, but its inelegant.

It's inelegant only because the slice doesn't know how to tell the
iterator it only needs one value.  If it did know, you'd call it
elegant.  :-)

Larry

Re: .NET

[Larry Wall]

David Grove writes:
: Larry, et. al.: Is this similarity on purpose?

Yes, but only becase .NET is a VM, not because it's from MicroSoft.

The basic goal is to have a Perl VM that can sit easily on other VMs,
whether .NET's or Java's or our own.  Another example of competing
by cooperating, which Perl has always done.

Larry

Re: Please make "last" work in "grep"

[Larry Wall]

H.Merijn Brand writes:
: On Wed, 2 May 2001 08:05:29 -0700 (PDT), Larry Wall <[EMAIL PROTECTED]> wrote:
: > Michael G Schwern writes:
: > : (grep {...} @stuff)[0] will work, but its inelegant.
: > 
: > It's inelegant only because the slice doesn't know how to tell the
: > iterator it only needs one value.  If it did know, you'd call it
: > elegant.  :-)
: 
: IIRC, that optimization is not even considered for reasons of many people

Whoever it is that is not considering it does not include me.  :-)

: wanting the side effects of grep/map finishing over all elements (which could
: of course be from a tied array or database connection)

If we do that kind of optimization, then we would certainly provide
some kind of easy syntax to defeat it.  But I'd say that, by and large,
it's precisely when you're dealing with a slow database connection that
you could use all the clever optimization you can get, because the
unintended work gets magnified along with the intended, and the stakes
are higher.

Larry

Re: Please make "last" work in "grep"

[Larry Wall]

Bart Lateur writes:
: Because you might have a wantarray situation that expects no values?
: 
:   () =3D whateveryouwant();
: 
: You can always expect one more than is on the LHS.
: 
: How is this currently handled with split()?

It fakes up a third argument that is one more than the length of the
list.

In Perl 6, we'll have a unary * that (in an lvalue or formal parameter)
marks the following item as a "slurper".  So in a list assignment,
these work differently:

(@a, @b, @c) = ...; # provides 3 scalar contexts
(@a, @b, *@c) = ...;# provides 2 scalar and 1 list context

So by analogy, we could conceivably have:

($a, $b, $c) = split;   # splits in 3 spots
($a, $b, *$rest) = split;   # splits in 2 spots

But what that would mean in a formal parameter list, I have no idea.
So * on a scalar might not fly in general.

A unary * in rvalue context defeats signature checking for the rest
of the arguments in the list.  So Perl 5's:

&foo(@list)

would likely be translated to Perl 6's:

foo(*@list)

Larry

Re: Please make "last" work in "grep"

[Larry Wall]

Dan Sugalski writes:
: I'd really like to get into the details of what is and isn't valid for the 
: optimizer to do, though I expect it's still a little early in the 
: Apocalypse season for that.

Doubtless we'll do as other compilers do, and have a little knob you
just keep turning up until something breaks, and then you back it off
a notch and think no more about it.

Larry

Re: Please make "last" work in "grep"

[Larry Wall]

[EMAIL PROTECTED] writes:
:> >Hopefully the "something similar", I hope in Perl 6 we will able to
:> >bury the "0 but true" workaround to the backyard on a moonless night :-)
:> 
:> Especially since you don't need it. "0E0" and "0.", to name just two,
:> work just as well.   ;-)
: 
: http://yetanother.org/damian/Perl5+i/control.html#Any_value_can_be_true_or_false
: 
: ;-)

Except if we take that approach it will be probably spelled:

return 0 is true;

More in A2, which I'm just putting the finishing touches on.

Larry

Re: So, we need a code name...

[Larry Wall]

Edward Peschko writes:
: > : (is a nice city in Italy with a great symbol, the tower of Pisa).
: > : 
: > : a'P'  at the beginning, which means  'Perl',
: > : an   'I'  which may mean 'Interpreter',
: > : a'S'  which may means'Six'
: > : an   'A'  which may means'Alpha'
: > 
: > I suggest [1]Peterbilt.  
: 
: Why not parrot, again?

Too many dead parrot jokes?  Too many lousy acronyms?

Platform-Agnostic Rabidly Rapid Object Thrasher

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.

Then Perl language variants could go the other way and be:

PermMicro Perl
PernNano Perl
PeroJava Perl
PerpPython Perl
PerqQuick Perl
PerrRuby Perl
PersStrict Perl
PertTypesafe Perl
PeruUnforgivable Perl
PervVectorized Perl
PerwWonky Perl
PerxExperimental Perl
PeryYet Another Perl
PerzZany Perl
Pesayour ad here
Pesbyour ad here
...

'Course, at that rate, we eventually get back to "Pisa"...

Appearances notwithstanding, I am seriously suggesting "Perk".  The name
is, er, perky.  Hopefully the implementation would be too.

Larry

Re: apo 2

[Larry Wall]

David L. Nicol writes:
: 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 worry that official standard p6 will be more difficult
: to use than official standard p5.

Mostly I didn't want to deal with the muddy case of where the
identifier might be a quote operator, possibly even a user-defined
one.  But it's not something I feel implacable about.  I'm mostly just
trying to pare Perl's list of oh-by-the-ways down to a dull roar.
You'll note that a great deal of what's going on comes under the
category of simplification (even if half the Slashdot crowd doesn't
understand that).  I'm particularly partial to the simplifications that
allow us to increase the power of other parts of the language.  This
particular simplification is only a little bit that way, though I can
imagine deciding to extend << syntax in other directions someday, in
which case we might want to put random function names after the <<.
But certainly we're not taking the autoquoting away from {} or =>,
so I suppose there's something to be said for keeping it here too.

Larry

Re: apo 2

[Larry Wall]

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

Re: Apo2: \Q ambiguity

[Larry Wall]

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]

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