Re: RFC 76 (v1) Builtin: reduce

[Ariel Scolnicov]

Perl6 RFC Librarian <[EMAIL PROTECTED]> (but actually it was Damian
Conway) writes:

> If the original list has no elements, C immediately returns C.

I like everything except this part.  Reducing an empty list should be
an error.

Returning undef (or anything else, really) breaks the algebraic
equivalence that

f((reduce \&f, LIST), $x) eq (reduce \&F, LIST, $x)

Since this is the single most important property of reduce (indeed, it 
is the *only* property of reduce), I don't see what we get by breaking 
it.

Also, the RFC should specify that the function is always evaluated in
a scalar context (for things to make sense).

-- 
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd.  |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels

Re: RFC 48 (v2) Objects should have builtin stringifying

[Piers Cawley]

John Porter <[EMAIL PROTECTED]> writes:

> Michael Fowler wrote:
> > 
> > I think a stringified reference is worth seeing, moreso than a simple undef,
> > for debugging purposes if nothing else.
> 
> I personally would like to have the stringification of refs be a
> symmetric operation, i.e. such a string should dwim in a ref context:
> 
>   $r = bless {}, 'Foo';
>   $s = "$r";
>   ref($s); # True.
>   $s->bar; # call method of Foo.
> 
> I guess that means the deref operator would have be implicitly overloaded
> for strings...

Down that road lies madness.

-- 
Piers

RFC 80 (v1): Exception objects and classes for builtins

[Jonathan Scott Duff]

Peter Scott writes:
> try {
> # fragile code
> } catch Exception::IO with {
> # handle IO exceptions
> } catch Exception::Socket with {
> # handle network exceptions
> } otherwise {
> # handle other exceptions
> };

What would the difference between that and this be?

try {
# fragile code
} catch {   # catch ALL exceptions
switch ($EXCEPTION->name) {
case IO { ... }
case Socket { ... }
}
}

The catch clause would catch all exceptions.  The one thrown would be
placed in a "global" $EXCEPTION variable.

> This is a strawman exception class hierarchy.  The merits of this RFC
> do not depend on this beign a good hierarchy, only on it being possible
> to find a reasonable one.

Is it really a hierarchy?  Must it be?  Your strawman looks more like
an enumeration to me.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Bart Lateur]

On Wed, 9 Aug 2000 22:57:34 -0500, Jonathan Scott Duff wrote:

>By "local timezone" do you mean that some sort of inspection happens to
>determine the local timezone and the date() intrinsically knows about it?
>What about daylight savings time?  I presume the ability to specify an
>offset from GMT will be built in to date()?  And I still think it would
>be a good idea to let the user somehow provide an anonymous sub to date()
>that will tell date() the proper offset from GMT for "localtime" if
>we're going to support that concept at all.

Indeed. The only built-in timezone (and daylight savings time, which is
technically the same as a time zone) it really needs, is that of the
current lcoaltime(). gmtime() is no offset.

For the particular case where I needed this, where the server in another
time zone than me, I know the data for the time zone and daylight
savings time, so I can pass that data myself.

But I have some doubt if you actually need to be able to pass this
function a sub ref (AKA a callback). For most of the time, this will be
a constant, so passing a constant in the form of "+0200" should be
possible as well.

I would put all other time zone processing, apart from the local
system's localtime() time zone, and including the callback functions, in
a module.

As for the parameter's format: GMT is easy, you can pass "GMT" (or
"+"). For localtime(), you often don't explicitely know the time
zone and Daylight savings Time rule, so this looks like a good candidate
for undef.

-- 
Bart.

Re: RFC 73 (v1) All Perl core functions should return ob

[Bart Lateur]

On Thu, 10 Aug 2000 13:22:46 +1000 (EST), Damian Conway wrote:

>The RFC I'm writing specifies that if the subroutine being called has
>a lazy context specifier on a given argument, that argument is only
>evaluated when the value of the corresponding element of @_ is fetched,
>stored, or eval'd. 
>
>So the subroutine that's being called is the one that decides.

If this is the only rule, I wholeheartedly agree. Now, the only
operators that do lazy eval are the booleans: 'and', 'or', '&&' and
'||'. So here too it's the operator/function that decides.

-- 
Bart.

Re: Proposal for \v and \V, the small- and large- cut regex opera tors.

[Bart Lateur]

On Thu, 10 Aug 2000 04:42:56 -0400, Ilya Zakharevich wrote:

>> Variable interpolation can be handled using Damian's curried expressions.
>
>On XRay:
>
>Summary for query "curried;Damian":
>
>   found 0 matches in 0 files.

Look up RFC 23 on : "Higher order functions".

-- 
Bart.

Re: Things to remove

[Bart Lateur]

On Sat, 5 Aug 2000 09:44:47 -0500, Jonathan Scott Duff wrote:

>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?

Definitely. You can't even use it to clear a package, which would be one
of it's better uses. Grouping by start of name is a Bad Thing (TM), IMO.

Perlfunc says:

Generally used in a `continue' block at the end of a loop to
clear variables 

Oi! Use block scoped lexical variables for that! Oh yes, this is pre
Perl5...

... and reset `??' searches so that they work again.

Now, that would have been interesting, if only ?PATTERN? itself was
worth bothering with. I've not ever used it. "last", anyone?

>   dump

Perlfunc says:

Primarily this is so that you can use the undump program
(not supplied) to turn your core dump into an executable binary
after having initialized all your variables at the beginning of
the program.

Only on Unix, I guess.

This function is now largely obsolete, partly because it's very
hard to convert a core file into an executable.

Not even there.

>   study   # never been a win for me.

Me neither. I wouldn't know what it's good for. According to perlfunc,
it serves to speed up searches on a very large string. I don't do that
very often. Instead, I use lots of smallish strings, lines from a file.

>   ?pattern?   # one-time match

I've never used it. I never will. First, I like "last" to jump out of a
loop. Or you can set a variable in the match, like this:

$test ||= do { /PATTERN/ and ... };

There's also:

if($temp=(/PATTERN/ .. 0) and $temp==1) {
print "Hey!, got my first match!\n";
}

although that is a bit kludgy, not in the least because you can't
localize the temp.

>   split ?pat? # implicit split to @_

also:
split   # in a scalar or void context

Dirty. Never ever. I'd rather have that in scalar context, split just
returned a count, without affecting @_.

I have a lot of suggestions of my own... but that will have to wait till
another post.

-- 
Bart.

And A Parser In A Pared Tree (was Re: Overloading && ||)

[Bryan C . Warnock]

On Thu, 10 Aug 2000, David L. Nicol wrote:
> "Bryan C. Warnock" wrote:
> 
> > This was the ass that I never found the gall to scratch, because I've
> > identified no solutions, and have found only problems.
> > 
> > --
> > Bryan C. Warnock
> > ([EMAIL PROTECTED])

While I appreciate the creative combination of several key points in
my post, I'd appreciate it more if you wouldn't state that I actually
wrote that.  Or perhaps you were making your own point.  :-)

The rest of your paraphrasing is pretty much on, I guess.  Perl already
is two (similar, but distinct) languages, of which only one is required
to work in Perl.  They are Perl, the defined language, and the internal
API to Perl.  (Okay, so that's still fuzzy, but you should get the
idea.)

Ideally, it wouldn't involve Yet Another Language, but could be done in
one of the two Perl already has.  (Or both, I suppose.)  What I don't
believe should be the goal, although it may be an unfortunate
side-effect, is to, in essence, write the parser in Perl, and to
require writing a full parser for every case  That would, in essence,
require dropping the user parser inline between the lexer and the real
parser, capturing all the tokens coming out, doing the necessary
identification and modifications, and passing the new token stream to
the real parser. I think this was one of Nat's hook areas, and is
similar to what Chaim suggested with how macros could work.
This could work with very simple requirements, and could even partially
extend to adding lexer extensions.  Otherwise, why not just rewrite the
parser in its entirety, and drop it in as a new front end?

Alternately, to keep things simple, you could have a signature callback
type mechanism, where the parser only calls your code upon certain rule
reductions.  This requires the lexer to have already sent the data to
the parser, which could make for some icky situations, particularly
with inspection and modification of what the parser has already done.

Or, to keep things really simple, have parser pragma types that affect
the parser internals runtime much like the rest of Perl modules affect
Perl runtime.  (This would, of course, require the parser to be able to
support much deeper introspection than it does now.  Yet Another
Language, more complexity.  But would allow for only a limited number
of hooks, which would be a little easier to contain and a little less
scary to deal with.)  This last was basically what I was looking for
with RFC 40.  This would allow people to write their own pragmas, as
long as they only needed what hooks were available.  More radical
changes would involve adding more hooks.

I'll ponder all this today, and maybe give some examples this evening,
perhaps showing how some of the current RFCs could be addressed.

 -- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: Overloading && ||

[Dan Sugalski]

On Wed, 9 Aug 2000, Bryan C. Warnock wrote:

> What I was trying to say, is that I think most of the language RFCs
> could be addressed (in one way) by affecting whether and how the parser
> interprets what the lexer gives to it.

That's closer to the truth, though the RFCs that don't introduce brand new
concepts generally affect the runtime behaviour of perl rather than the
compile-time behaviour, though some do both.

Perl's biggest barrier to doing this is the difficulty of determining what
a token is, and that's really what stands in the way. Changing how the
parser deals with tokens is reasonably simple compared to that. (Well, as
simple as writing parser code) Lexer abuse is needed for things like
Python mode, though--without it that's a no go.

We may be able to fake it with source filters and parser abuse, though.

Dan

we might as well give up now: CobolScript(R)

[Jarkko Hietaniemi]

We will never conquer the world with Perl 6:
CobolScript(R) got there before us. 

http://www.cobolscript.com/

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: RFC 80 (v1) Exception objects and classes for builti

[Bennett Todd]

2000-08-10-02:40:41 Perl6 RFC Librarian:
> RFC 70 proposes that all builtins throw trappable exceptions on 
> error.

Not quite. RFC 70 acknowleges that perl's current behavior is
preferred by some very focal participants in the language's
development, and even if it weren't, that switching all builtins to
throw exceptions is too radical a change.

Rather, RFC 70 proposes that some (I hope!) subtle blemishes on
perl's innards get polished up a bit, so that all builtins that can
returns errors, can also be wrapped. If that fix were made, then the
already-available module Fatal.pm, included with perl releases for
some time now, could be made to work with all builtins, at which
point it would be a reasonable amount of additional work to make it
really easy to change this aspect of perl's behavior. I really hope
to be starting all my programs with

use Fatal qw(:all);

So, yes, there's a connection between RFC 70 and RFC 80, but I
submit that it's a little bit looser. If RFC 70 should prevail, then
Fatal.pm will step into the limelight, and _it_ should be made to
honor RFC 80 (or whatever ends up specifying the exception classes
for builtins).

-Bennett

 PGP signature

Portable upper/lower case regexp matches

[Jason Elbaum]

As far as I know, there is a basic bit of regexp functionality which
Perl should support but doesn't.

Perl regexps support the following features, though they're a bit
obscure to my tastes...

(from perlre:)
\l  lowercase next char (think vi)
\u  uppercase next char (think vi)
\L  lowercase till \E (think vi)
\U  uppercase till \E (think vi)
\E  end case modification (think vi)

...but Perl doesn't offer a regexp pattern to match all alphabetical
characters of a particular case. Something like:

\x  match lowercase alpha char
\X  match uppercase alpha char

Thus /\X\x*/ would match all capitalized words, while /\X+/ would match
acronyms, and /(\X\x+)+/ would match Java class names.


What's the big deal, you ask? Just use [A-Z] and [a-z]!

Well, perlre notes:

"If use locale is in effect, the case map used by \l, \L, \u and \U is
taken from the current locale."

And to quote perllocale:

"Perl supports language-specific notions of data such as `is this a
letter', `what is the uppercase equivalent of this letter', and `which
of these letters comes first'. These are important issues, especially
for languages other than English--but also for English: it would be
naive to imagine that A-Za-z defines all the `letters' needed to write
in English."

So explicit regexp matching for upper/lower alpha characters is
necessary to support locales, not to mention to be consistent with the
perl docs themselves.

There is no convenient way to imitate this functionality in Perl while
supporting locales. There should be.


Jason Elbaum
[EMAIL PROTECTED]

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

[Bennett Todd]

2000-08-09-21:00:31 Chaim Frenkel:
> Making a module local to the using package, might have interesting
> properties. [...]
> The only breakage that I see, is having some way of globally setting
> a variable. For example, turning on debugging for all uses. (FTP::Debug
> I find quite popular.)
> 
> Can anyone see any other breakage? 

Not other breakage, but another example of the same exact class
of breakage. In RFC 70 I proposed some (hopefully minor) language
cleanups to make it possible to have Fatal.pm actually work the
way people want it. If it worked, then Fatal.pm would be getting
some categories it supported, e.g. "use Fatal qw(:io);". I then
suggested that the invoked categories could be posted into a
testable variable, in case other module authors wished to cooperate
with this protocol.

If the only real problem that can be found with making module use
package-local is in these few option-flag type variables, perhaps
they could be handled differently. E.g. suppose normal package
variables end up being local to the package that "use"-es the
package, and when a package actually wants to make a genuine global
for all users of the package, it explicitly tucks it into a variable
whose name starts with main::. E.g. let Net/FTP.pm post its debug
flag into $main::Net::FTP::Debug, and the list of exception classes
requested of Fatal.pm could be posted into @main::Fatal.

The next natural thought seems to be that the module creating such
a global should check and see if it's being used by main, and
only post into the global if so, otherwise let its option[s] be
user-local. Can import() use caller() this way? That would allow
a module author to e.g. code their module using Fatal, without
affecting anything outside their module, while allowing main's
invocation (if any) of Fatal to offer guidance to other modules that
chose to try and honor it.

-Bennett

 PGP signature

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

[Bennett Todd]

2000-08-09-17:33:25 Steve Simmons:
> If that's the intent, then yes, author name must become part of the
> package identifier.  Rather than change the meaning of "ref $object"
> unexpectedly, I'd add one or more alternate forms of ref.  Off the
> top of the head, something like
> 
> ( $version, $class ) = vref $object;  # ref with version
> ( $author, $class ) = aref $object;   # ref with author
> ( $version, $author, $class ) = fref $object;   # get all

Rather than proliferating the number of keywords eaten with all
these *ref varients, this sounds like a useful place for returning
an object with a default stringification of the class:

$class = ref $object; # when you use $class as a string,
  # or 2nd arg to bless()
$version = $class->{VERSION};
$author = $class->{AUTHOR};

Ref RFC 37, RFC 73.

-Bennett

 PGP signature

Re: Portable upper/lower case regexp matches

[Bart Lateur]

On Thu, 10 Aug 2000 17:21:44 +0300, Jason Elbaum wrote:

>   \x  match lowercase alpha char
>\X  match uppercase alpha char
>
>Thus /\X\x*/ would match all capitalized words, while /\X+/ would match
>acronyms, and /(\X\x+)+/ would match Java class names.

You've got my vote, apart from one tiny detail: \x is already in use. It
allows you to specify character codes in hex, just like "\012" is in
octal.

$_ = "a\tb";
$_ = "a\tb";
print join '#', split /\x09/;
-->
a#b


Getting a feature like this accepted, should be rather trivial.

-- 
Bart.

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

[Steve Simmons]

On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote:

> I'll take that as my cue ;-).

Ah, nothing like a man who knows when to pick up his cues.

> <*shudder*>  This whole business is getting pretty scary . . .
  [[ discussion of ugly implicatations elided ]]

The short answer is that (assuming I understand Larry's statement)
he'd like these issues addressed.  If the resulting `best' answer
is so complex and so ugly that he decides it's a bad idea, that's
fine -- but (if I recall correctly) tcl has addressed this problem
and come up with workable solutions.  I'm not intimately familiar
with them, but will get so.

Re: Portable upper/lower case regexp matches

[Jarkko Hietaniemi]

On Thu, Aug 10, 2000 at 05:21:44PM +0300, Jason Elbaum wrote:
> As far as I know, there is a basic bit of regexp functionality which
> Perl should support but doesn't.
> 
> Perl regexps support the following features, though they're a bit
> obscure to my tastes...
> 
> (from perlre:)
> \l  lowercase next char (think vi)
> \u  uppercase next char (think vi)
> \L  lowercase till \E (think vi)
> \U  uppercase till \E (think vi)
> \E  end case modification (think vi)
> 
> ...but Perl doesn't offer a regexp pattern to match all alphabetical
> characters of a particular case. Something like:
> 
> \x  match lowercase alpha char
> \X  match uppercase alpha char
> 
> Thus /\X\x*/ would match all capitalized words, while /\X+/ would match
> acronyms, and /(\X\x+)+/ would match Java class names.

Perl 5.6.0 has [[:lower:]] and [[:upper:]].

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: RFC 80 (v1): Exception objects and classes for builtins

[Peter Scott]

At 02:56 AM 8/10/00 -0500, Jonathan Scott Duff wrote:
>Peter Scott writes:
> > try {
> > # fragile code
> > } catch Exception::IO with {
> > # handle IO exceptions
> > } catch Exception::Socket with {
> > # handle network exceptions
> > } otherwise {
> > # handle other exceptions
> > };
>
>What would the difference between that and this be?
>
> try {
> # fragile code
> } catch {   # catch ALL exceptions
> switch ($EXCEPTION->name) {
> case IO { ... }
> case Socket { ... }
> }
> }
>
>The catch clause would catch all exceptions.  The one thrown would be
>placed in a "global" $EXCEPTION variable.

TMTOWTDI, I guess.  The exception variable comes into the catch block as 
$_[0] in Error.pm.  To catch all exceptions you'd just use an otherwise clause.

> > This is a strawman exception class hierarchy.  The merits of this RFC
> > do not depend on this beign a good hierarchy, only on it being possible
> > to find a reasonable one.
>
>Is it really a hierarchy?  Must it be?  Your strawman looks more like
>an enumeration to me.

You're right, the places where I suggested subclassing wouldn't really be 
subclasses, just an extra :: in the name to imply containership.  Unless 
the exception classes had some semantics I hadn't thought of, in which case 
they could be inherited.  Good point, I shall fix it in v2.

--
Peter Scott
Pacific Systems Design Technologies

Re: Portable upper/lower case regexp matches

[Johan Vromans]

Jason Elbaum <[EMAIL PROTECTED]> writes:

> Perl regexps support the following features, though they're a bit
> obscure to my tastes...
> 
> (from perlre:)
> \l  lowercase next char (think vi)

Actually, this has little to do with regexes, it a string issue.

> ...but Perl doesn't offer a regexp pattern to match all alphabetical
> characters of a particular case. Something like:
> 
> \x  match lowercase alpha char
> \X  match uppercase alpha char

Well, take your pick:

[:lower:]   and [:upper](POSIX, e.g., /[[:islower:]]+/)
\p{IsLower} and \p{IsUpper} (UNICODE, e.g., /\p{IsLower}+/)

It's all in 5.6. See PP3, pp 167 and up.

-- Johan

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

[Ted Ashton]

Thus it was written in the epistle of Steve Simmons,
> On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote:
> 
> > I'll take that as my cue ;-).
> 
> Ah, nothing like a man who knows when to pick up his cues.

:-)

> > <*shudder*>  This whole business is getting pretty scary . . .
>   [[ discussion of ugly implicatations elided ]]
> 
> The short answer is that (assuming I understand Larry's statement)
> he'd like these issues addressed.  If the resulting `best' answer
> is so complex and so ugly that he decides it's a bad idea, that's
> fine -- but (if I recall correctly) tcl has addressed this problem
> and come up with workable solutions.  I'm not intimately familiar
> with them, but will get so.

Understood.  After a bit of reflection on it, I got to wondering, what if it
  1) Searched all of @INC for the most recent module which fits within the 
 constraints given (version range numbers, at least).
  2) Loaded the module globally (as it does now) *unless* told not to.  Thus,
 if a module wanted to
   use Foo private;
 then it could.
As far as the author business goes, is it becoming unwieldy to have portions
of the namespace assigned to specific authors?  That is, Devel::SmallProf is 
mine (as per committee decision) and others wanting to write small profilers
can have TinyProf, MicroProf and so forth.  I really think that multiple 
versions of a module are a fairly natural thing, but that modules with the
same name by different folks are bound to cause confusion, much beyond the 
actual running of programs.  

  PerlUserA:  I keep having this problem with the Foo::Bar module.  It won't
grok blargs as it ought.
  PerlUserB:  You must be doing something wrong.  It works fine for me.
<*three day conversation ensues*>
  PerlUserB:  I give up.  I don't know what you're doing wrong.  Why don't you
write to Tom and ask him.
  PerlUserA:  Tom, why Tom?
  PerlUserB:  Because he wrote the module.
  PerlUserA:  No he didn't.  Ilya wrote it.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
It is not knowledge, but the act of learning, not possession but the act of
getting there, which grants the greatest enjoyment. When I have clarified
and exhausted a subject, then I turn away from it, in order to go into
darkness again; the never-satisfied man is so strange if he has completed a
structure, then it is not in order to dwell in it peacefully, but in order
to begin another. I imagine the world conqueror must feel thus, who, after
one kingdom is scarcely conquered, stretches out his arms for others.
   -- Gauss, Karl Friedrich (1777-1855)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

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

[Steve Simmons]

On Thu, Aug 10, 2000 at 11:01:39AM -0400, Bennett Todd wrote:

> Rather than proliferating the number of keywords eaten with all
> these *ref varients, this sounds like a useful place for returning
> an object with a default stringification of the class:
>  . . .
> Ref RFC 37, RFC 73.

I have no problem with this or any other solution that gets the
data back.  I'll add a comment to RFC78 that should those RFCs
prevail, we'll follow them.

For the record, I prefer hashes for that sort of thing too.  But
perl has traditionally done ordered list returns, and I followed in
that vein.

Re: RFC 73 (v1) All Perl core functions should return ob

[Dan Sugalski]

At 03:38 PM 8/10/00 +1000, Damian Conway wrote:
>> >> An object that has many different -ify methods:
>> >>   stringify
>> >>   numify
>> >>   hashify
>> >>   listify
>> >>   objectify (!)
>> >
>> > Possible, but blech.
>>
>> Why is that more blech?
>
>Because it's "heavy".
>
>However, if Dan assures me that objects will have lower overheads
>in Perl 6, I will happily withdraw my "blech".

Objects will have lower overhead in perl 6. This sort of thing doesn't have 
to be an object, either--it should be reasonably trivial to do with the 
perl 6 equivalent of magic, which should be even cheaper.


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

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

[Dan Sugalski]

At 10:43 AM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-09-21:00:31 Chaim Frenkel:
> > Making a module local to the using package, might have interesting
> > properties. [...]
> > The only breakage that I see, is having some way of globally setting
> > a variable. For example, turning on debugging for all uses. (FTP::Debug
> > I find quite popular.)
> >
> > Can anyone see any other breakage?
>
>Not other breakage, but another example of the same exact class
>of breakage. In RFC 70 I proposed some (hopefully minor) language
>cleanups to make it possible to have Fatal.pm actually work the
>way people want it. If it worked, then Fatal.pm would be getting
>some categories it supported, e.g. "use Fatal qw(:io);". I then
>suggested that the invoked categories could be posted into a
>testable variable, in case other module authors wished to cooperate
>with this protocol.

Why not, then, introduce non-fatal errors and a new keyword to throw them? 
Something like quit(), which could take an error class, an error identifier 
(a number or short string or something) and a message. It'd work like a 
bare return, but also stick something in $@, and could be trappable. (Quit 
with one parameter would default the class to generic, and the identifier 
to unknown)

This way, when something needs to bail with a non-fatal error it could:

   quit('io', 'READERROR', "Unable to read from file $foo");

and the code calling the sub could, if it wanted, could do a plain:

   $foo = some_sub($file);

or:

   {
 use fatal;
 eval {
   $foo = some_sub($file);
 };
 if ($@) {
   if ($@->nonfatal) {
 # handle non-fatal errors
   }
 }
   }

or something like that.

*) Define a set of c

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 67 (v1) Deep Copying, aka, cloning around.

[Dan Sugalski]

At 11:01 PM 8/9/00 -0500, Jonathan Scott Duff wrote:
>On Wed, Aug 09, 2000 at 11:46:12AM -0500, Garrett Goebel wrote:
> > From: Peter Scott [mailto:[EMAIL PROTECTED]]
> > >
> > > >I would like deep copying to include copying CODE. It would
> > > >be useful for implementing object methods...
> > >
> > > Why would it be necessary to deep copy a CODE reference?
> >
> > It might not be necessary. I'm still learning how to write kosher Perl...
> > elegance is a long way off for me.
>
>Imagine storing your code along with your data in a database for use
>later (persistent objects)

Imagine being able to freeze your program to disk for later use, or being 
able to serialize an object and all the code and data it has access to to 
disk. (Or the network...)


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Portable upper/lower case regexp matches

[Peter Scott]

At 10:28 AM 8/10/00 -0500, Jarkko Hietaniemi wrote:
>On Thu, Aug 10, 2000 at 05:21:44PM +0300, Jason Elbaum wrote:
> > As far as I know, there is a basic bit of regexp functionality which
> > Perl should support but doesn't.
> >
> > Perl regexps support the following features, though they're a bit
> > obscure to my tastes...
> >
> > (from perlre:)
> > \l  lowercase next char (think vi)
> > \u  uppercase next char (think vi)
> > \L  lowercase till \E (think vi)
> > \U  uppercase till \E (think vi)
> > \E  end case modification (think vi)
> >
> > ...but Perl doesn't offer a regexp pattern to match all alphabetical
> > characters of a particular case. Something like:
> >
> > \x  match lowercase alpha char
> > \X  match uppercase alpha char
> >
> > Thus /\X\x*/ would match all capitalized words, while /\X+/ would match
> > acronyms, and /(\X\x+)+/ would match Java class names.
>
>Perl 5.6.0 has [[:lower:]] and [[:upper:]].

Yes, but this one is worth a digraph.  Question is, which one?  Currently 
the free ones are:

\F  \h \H  \i \I  \j \J  \k \K  \m \M  \o \O  \q  \R  \T  \v \V  \y \Y

\v \V are being debated on p5p currently.

I suggest \i \I, mnemonic with ?:i and /i.  I know it's a strange 
association once you think about it, but it made sense at first thought.

--
Peter Scott
Pacific Systems Design Technologies

Re: Portable upper/lower case regexp matches

[Jarkko Hietaniemi]

On Thu, Aug 10, 2000 at 08:55:27AM -0700, Peter Scott wrote:
> At 10:28 AM 8/10/00 -0500, Jarkko Hietaniemi wrote:
> >On Thu, Aug 10, 2000 at 05:21:44PM +0300, Jason Elbaum wrote:
> > > As far as I know, there is a basic bit of regexp functionality which
> > > Perl should support but doesn't.
> > >
> > > Perl regexps support the following features, though they're a bit
> > > obscure to my tastes...
> > >
> > > (from perlre:)
> > > \l  lowercase next char (think vi)
> > > \u  uppercase next char (think vi)
> > > \L  lowercase till \E (think vi)
> > > \U  uppercase till \E (think vi)
> > > \E  end case modification (think vi)
> > >
> > > ...but Perl doesn't offer a regexp pattern to match all alphabetical
> > > characters of a particular case. Something like:
> > >
> > > \x  match lowercase alpha char
> > > \X  match uppercase alpha char
> > >
> > > Thus /\X\x*/ would match all capitalized words, while /\X+/ would match
> > > acronyms, and /(\X\x+)+/ would match Java class names.
> >
> >Perl 5.6.0 has [[:lower:]] and [[:upper:]].
> 
> Yes, but this one is worth a digraph.  Question is, which one?  Currently 
> the free ones are:

Hardly.  I beg to differ.  We have enough magical digraphs as it is.
Let's save what we have for metamarkers, such as \v\V, not for 
character classes..

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

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

[Simply Hao]

You might want to check out Umbrella Frameworks:

  http://arstechnica.com/reviews/2q00/macos-x-dp4/macos-x-dp4-3.html

It would be good for some of us to have an easier way of using
multiple versions of modules sometimes.

-Hao

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

[Brust, Corwin]

-Original Message-
From: Steve Simmons [mailto:[EMAIL PROTECTED]]

> For the record, I prefer hashes for that sort of thing too.  But
> perl has traditionally done ordered list returns, and I followed in
> that vein.

Perhaps Damian's want() (RFC 21) can be used to allow allow either return
type? 

Assuming that's adopted, of course.

-Corwin

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

[Bennett Todd]

2000-08-10-11:52:31 Dan Sugalski:
> Why not, then, introduce non-fatal errors and a new keyword to
> throw them?

If we were to add a non-fatal exception type, that would just mean
that those of us who want errors to behave differently than they do
now, would have to wrap our whole program in a catcher; that's just
a couple of extra lines of clutter, and I'm sure they could be
deposited in a module to reduce it back to the desired one line.

Arranging for all the builtins to throw a non-fatal exception would
impose a cost on the rest of the folks, who prefer to have most
errors ignored (the way perl currently works), but who want to just
check for the error return from select calls: they would have to do
things differently.

Your suggestion (all builtins through non-fatal exceptions for error
reporting) would make implementing Fatal.pm a lot easier, but a less
intrusive measure (making all error-reporting buitins wrappable, my
RFC 70) would at least make Fatal.pm possible to implement
completely, and would inflict little or no change on the people who
like perl's currently style of error reporting.

But I do see one worry about the proposed non-fatal exception type,
and that is that it would require some interesting implementation
hair to make it work; unlike the current exceptions, non-fatals
would require passing state downward, and defining its scope,
because the routine throwing an exception has to know whether
they're being caught before it actually throws. Or else we'd have
to have continuations, and the non-fatal exception could be thrown
with a continuation, which a default catcher could use to resume
execution ignoring the error. I can't believe I suggested that.

-Bennett

 PGP signature

Re: RFC 80 (v1): Exception objects and classes for builtins

[Graham Barr]

On Thu, Aug 10, 2000 at 02:56:59AM -0500, Jonathan Scott Duff wrote:
> Peter Scott writes:
> > try {
> > # fragile code
> > } catch Exception::IO with {
> > # handle IO exceptions
> > } catch Exception::Socket with {
> > # handle network exceptions
> > } otherwise {
> > # handle other exceptions
> > };
> 
> What would the difference between that and this be?
> 
>   try {
>   # fragile code
>   } catch {   # catch ALL exceptions
>   switch ($EXCEPTION->name) {
>   case IO { ... }
>   case Socket { ... }
>   }
>   }

I was more thinking of

eval {
# fragile code
}
else {  # catch ALL exceptions
switch ($@) {
case __->isa('IO') { ... }
case __->isa('Socket') { ... }
else   { ... }
}
}
continue {
   # code always executed (ie finally)
}

And the only new keywords are for the switch statement.

Graham.

Re: RFC 80 (v1) Exception objects and classes for builti

[Peter Scott]

At 09:44 AM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-10-02:40:41 Perl6 RFC Librarian:
> > RFC 70 proposes that all builtins throw trappable exceptions on
> > error.
>
>Not quite. RFC 70 acknowleges that perl's current behavior is
>preferred by some very focal participants in the language's
>development, and even if it weren't, that switching all builtins to
>throw exceptions is too radical a change.
>
>Rather, RFC 70 proposes that some (I hope!) subtle blemishes on
>perl's innards get polished up a bit, so that all builtins that can
>returns errors, can also be wrapped. If that fix were made, then the
>already-available module Fatal.pm, included with perl releases for
>some time now, could be made to work with all builtins, at which
>point it would be a reasonable amount of additional work to make it
>really easy to change this aspect of perl's behavior. I really hope
>to be starting all my programs with
>
> use Fatal qw(:all);
>
>So, yes, there's a connection between RFC 70 and RFC 80, but I
>submit that it's a little bit looser. If RFC 70 should prevail, then
>Fatal.pm will step into the limelight, and _it_ should be made to
>honor RFC 80 (or whatever ends up specifying the exception classes
>for builtins).

Ah, got it.  Now we have actually two types of error from builtins:

Non-trapped (builtins return 0, undef, 1 :-) , n where n < # requests, etc).
RFC 70 wants all these to be turned into optional exceptions if Fatal is used.

Exceptions: the builtin die()s.  RFC 80 was actually only thinking about 
these, but clearly gets even more power if Fatal is used, when a whole 
bunch more exception classes come into play.

I like the way this is going.  I'll fix up v2.

--
Peter Scott
Pacific Systems Design Technologies

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Russ Allbery]

Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

> By "local timezone" do you mean that some sort of inspection happens to
> determine the local timezone and the date() intrinsically knows about
> it?  What about daylight savings time?

This all should be handled by the operating system.  If you call localtime
in C, you should get back local time, whatever the local time zone.  The
whole point is to not try to duplicate that information in Perl core.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

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

[Dan Sugalski]

At 12:11 PM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-10-11:52:31 Dan Sugalski:
> > Why not, then, introduce non-fatal errors and a new keyword to
> > throw them?
>
>Arranging for all the builtins to throw a non-fatal exception would
>impose a cost on the rest of the folks, who prefer to have most
>errors ignored (the way perl currently works), but who want to just
>check for the error return from select calls: they would have to do
>things differently.

No, it wouldn't, really. We could make "use fatal;" scoped, so that the 
quit op (or whatever it is) only jumps through all its hoops if the 
pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return 
and that's it.

You'd have the overhead of checking a flag when actually quitting with an 
error, but that adds a very small amount of overhead to an exceptional case.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Russ Allbery]

Bart Lateur <[EMAIL PROTECTED]> writes:

> As for the parameter's format: GMT is easy, you can pass "GMT" (or
> "+"). For localtime(), you often don't explicitely know the time
> zone and Daylight savings Time rule, so this looks like a good candidate
> for undef.

The string "GMT" is technically wrong.

I'm opposed to allowing one to pass in any sort of string for time zone
information; if you allow "GMT", people are going to expect to be able to
use "EST", and who knows what they actually mean.  If you want GMT, pass
an offset of 0.

Be careful about time zone offsets, btw, if the interface is going to
support them.  +0700 is *not* "700 minutes"; it's 7 hours and 0 minutes.
And there are half-hour time zones.  This is an area where there's a *lot*
of potential confusion; people in Newfoundland are going to expect to be
able to pass in -0230 and have that work, and that's interestingly hard.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 80 (v1): Exception objects and classes for builtins

[Peter Scott]

At 05:11 PM 8/10/00 +0100, Graham Barr wrote:
>I was more thinking of
>
> eval {
> # fragile code
> }
> else {  # catch ALL exceptions
> switch ($@) {
> case __->isa('IO') { ... }
> case __->isa('Socket') { ... }
> else   { ... }
> }
> }
> continue {
># code always executed (ie finally)
> }
>
>And the only new keywords are for the switch statement.

Do you propose this solely to conserve keywords, or is there another 
advantage?  I find

 try {
   #
 } catch Exception::Thingy with {
   #
 } catch Exception::Whatsit with {
   #
 } otherwise {
   #
 };

considerably more appealing, especially since catch blocks can contain tens 
of statements.  It's easier to see the exception class (not tucked inside a 
method call), and there aren't additional block levels.

BTW, the methods in Error.pm I don't use are except() and record().
--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 80 (v1): Exception objects and classes for builtins

[Graham Barr]

On Thu, Aug 10, 2000 at 09:34:43AM -0700, Peter Scott wrote:
> At 05:11 PM 8/10/00 +0100, Graham Barr wrote:
> >I was more thinking of
> >
> > eval {
> > # fragile code
> > }
> > else {  # catch ALL exceptions
> > switch ($@) {
> > case __->isa('IO') { ... }
> > case __->isa('Socket') { ... }
> > else   { ... }
> > }
> > }
> > continue {
> ># code always executed (ie finally)
> > }
> >
> >And the only new keywords are for the switch statement.
> 
> Do you propose this solely to conserve keywords,

partly

> or is there another 
> advantage?  I find
> 
>  try {
>#
>  } catch Exception::Thingy with {
>#
>  } catch Exception::Whatsit with {
>#
>  } otherwise {
>#
>  };
> 
> considerably more appealing, especially since catch blocks can contain tens 
> of statements.  It's easier to see the exception class (not tucked inside a 
> method call), and there aren't additional block levels.

Well what is the difference between try and eval ?

The catch syntax is less flexable, if you wanted to catch two
different types with the same code you are forced to either
  * duplicate code
  * put it in a sub, which is away from the statement. This may not help readability
  * put a switch statement in the otherwise

In fact the syntax could be

  eval {
  }
  continue {
  }

  switch ($@) {
  } if $@;

I just don't see the need to make perl look like other languages just for
the sake of makeing it look like other languages.

Graham.

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

[Graham Barr]

On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote:
> No, it wouldn't, really. We could make "use fatal;" scoped, so that the 
> quit op (or whatever it is) only jumps through all its hoops if the 
> pragma's in effect. If its not, then quit(foo, bar, baz) does a bare return 
> and that's it.
> 
> You'd have the overhead of checking a flag when actually quitting with an 
> error, but that adds a very small amount of overhead to an exceptional case.

Why not make that flag avaliable instead of having a new op ?

The user can then write

  $^fatal ? die  : return;

Hm, although people may start to mis-use the flag.

Graham.

My opposition to RFC20, and an alternative

[Steve Simmons]

Overloading an existing operator such that it changes the performance
in prior situation is evil, evil, evil.  Yes, I know it can have some
wins, and I agree they're big ones.  But no win is worth having to
debug this (admittedly contrived for the example) situation:

if ( ( $ares = A() ) && ( B() ) ) {
# A and B succeeded, go do something
} elsif ( $ares ) {
# A succeeded but B failed, do B cleanup
} else {
# Do B differently because A failed
}

If the overload means that now A() and B() will now both be processed
no matter what, that block of code is going to go south in a deeply
undetectable way.  And finding the bug is going to be bloody hell.  This
argues that overloading should be restricted in its scope.

Now consider some poor maintenance coder.  He's looking at his main
and a module, trying to figure out why something doesn't work.  Both
contain a test like

if ( A() && B() ) . . .

In main it works one way, in the module it works the other.  Is it
reasonable to expect that?  I submit not.

With humble acknowledgement of my debt to Socrates, I submit that
this dilemma shows that either solution - universal overloading or
localized overloading - leads to extreme difficulties in maintenance.

IMHO, overloading is just syntactic sugar - `it looks cool.'  If
we need an &&/|| operator that always tests both sides, lets
make them -- &&& and |||.  That's a tiny new thing in perl, while
avoiding deep, deep problems introduced from overloading standard
operators.  If someone wants a &&/|| that does something wildly
different, then write a module-specific or general function for
it

Overloading existing operators is evil, evil, evil.  Operators are
not class-specific functions.  They're core language constructs
and the programmer should be able rely on them to remain fixed
in function.

And in conclusion I'm opposed to this.  What I tell you three**3
times is true**3.  :-)

Re: RFC 80 (v1): Exception objects and classes for builtins

[John Porter]

Graham Barr wrote:
> 
> The catch syntax is less flexable, if you wanted to catch two
> different types with the same code you are forced to either
>   * duplicate code
>   * put it in a sub, which is away from the statement.
>   * put a switch statement in the otherwise

Could catch lists of types:

try {

}
catch Exception::Thingy, Exception::Whingy
with {


-- 
John Porter

Re: RFC 80 (v1) Exception objects and classes for builti

[John Porter]

Peter Scott <[EMAIL PROTECTED]>:
> 
>  try {
>  # fragile code
>  } catch Exception::IO with {
>  # handle IO exceptions
>  } catch Exception::Socket with {
>  # handle network exceptions
>  } otherwise {
>  # handle other exceptions
>  };

I'd like to recommend just "catch" instead of "otherwise",
because sometimes you'll do this:

try {
# fragile code
}
catch {
# handle other exceptions
};

And it would look silly to use "otherwise" there.

You could make it so "catch" takes a list of 0 or more exception
class names.

-- 
John Porter

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

[Dan Sugalski]

At 05:46 PM 8/10/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 12:28:05PM -0400, Dan Sugalski wrote:
> > No, it wouldn't, really. We could make "use fatal;" scoped, so that the
> > quit op (or whatever it is) only jumps through all its hoops if the
> > pragma's in effect. If its not, then quit(foo, bar, baz) does a bare 
> return
> > and that's it.
> >
> > You'd have the overhead of checking a flag when actually quitting with an
> > error, but that adds a very small amount of overhead to an exceptional 
> case.
>
>Why not make that flag avaliable instead of having a new op ?
>
>The user can then write
>
>   $^fatal ? die  : return;

Sure, that works. Whatever keyword throws the non-fatal error might just be 
a perl sub that does exactly that, at least to start. (Maybe always, who knows)

>Hm, although people may start to mis-use the flag.

What, people misuse core functionality? I can't picture *that* happening. 
It's so unperlish... :)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 80 (v1) Exception objects and classes for builti

[Bennett Todd]

2000-08-10-12:19:49 Peter Scott:
> Ah, got it.  Now we have actually two types of error from builtins:
> 
> Non-trapped (builtins return 0, undef, 1 :-) , n where n < # requests, etc).
> RFC 70 wants all these to be turned into optional exceptions if Fatal is used.

Ultimately, yes, that's my goal --- but RFC 70 really only asks that
it be possible to do Fatal.pm correctly, which it's currently not,
because of builtins that return errors, but which cannot be wrapped.

> Exceptions: the builtin die()s.  RFC 80 was actually only thinking
> about these, but clearly gets even more power if Fatal is used,
> when a whole bunch more exception classes come into play.

If you could sell that, I'd be one happy camper. But that's so much
more radical than just making all error-reporting builtins
wrappable, and so making it possible for Fatal.pm to finish the job,
that I gave up any hope of trying to sell it.

-Bennett

 PGP signature

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

[Steve Simmons]

> Perhaps Damian's want() (RFC 21) can be used to allow allow either return
> type? 

Yes indeed.

> Assuming that's adopted, of course.

Sure looks to me like a good idea; I hope it does.

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[John Porter]

Jeremy Howard wrote:
> The reason that having (1..) implies having (..-1) is that if you allow
> (1..), then this is a valid construct:
> 
>   @dot_dot_neg_one = reverse (map {-$_} (1..));
> 
> which is identical to (..-1)! 

No, NOT identical.  The same set of numbers, yes, but generated in
the opposite order.   (..-1) should generate -INF first, but obviously
it can't do that.  (..$n) is an impossible construct, and should be
a fatal error -- presuming it even gets past the lexer...

-- 
John Porter

Re: RFC 80 (v1): Exception objects and classes for builtins

[Bart Lateur]

On Thu, 10 Aug 2000 09:34:43 -0700, Peter Scott wrote:

>Do you propose this solely to conserve keywords, or is there another 
>advantage?  I find
>
> try {
>   #
> } catch Exception::Thingy with {
>   #
> } catch Exception::Whatsit with {
>   #
> } otherwise {
>   #
> };
>
>considerably more appealing, especially since catch blocks can contain tens 
>of statements. 

I find it pretty ridiculous. Why "otherwise" instead of "else"? This
*is* some kind of switch statement; if Perl is to have a general syntax
for switch statements, it should be employed for error trapping as well.

p.s. I've always disliked the word "throwing" for errors, just to be a
complement to "catch". An error to me is something like a trapdoor,
where you unexpectedly fall through.

-- 
Bart.

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: And A Parser In A Pared Tree (was Re: Overloading && ||)

[David L. Nicol]

perl parser compiles perl language into perl op-code tree.

Larry ("the" Larry) has said that a new parser might parse
other languages into perl op-code trees too.


If the parts of the language are well organized, a LanguageSwitch
(the computer equivalent of a "context switch" in a conversation,
but "context switch" is already taken in computerese, as the
basic magic that underlies multitasking) would cause as little or
as much to be replaced by the overlay as we like.  Parser definition
overlays would be this third language we agree is ugly but needed to
implement this modularly.

So if we've got the vanilla language defined clearly, we can overload
stuff at a higher level.  Current overloading works when you have
a function that the parser recognizes as a function, and you switch the
contents of that function, but its still a function rather than a flow 
control construct.

&& and || are thought of as "functions that short-circuit" that makes
them flow control constructs.  To switch them from parsing into an if-then
kind of thing into being overloadable functions,  the parser needs to
recognize them as functions that will operate on both their arguments
rather than flow control to decide to evaluate or not the right side.

So if we add parser overloading, it might look like

use parseroverload qw{ && treeAnd};
use parseroverload qw{ || treeOr};

treeAnd and treeOr would have to be defined somewhere.


parseroverload language (to be determined) might be able to affect binding
of arguments to functions, are they postfix, prefix, infix, this would
give us "user definiable operators" which I think is a way of saying
that you want to put the function name between the arguments instead
of before them:


assign( $a , add($x, $y))

or

$a assign $x add $y


or

$a = $x + $y


The third version is the one that is most familar, the first is possible
in  languages with implicit pass-by-reference or arguments, the second is
possible (to have it mean the same thing) if we can reprogram the
parser to treat "add" and "assign" as alternate words for what we are
used to thinking of as + and =.  

Of course, when it comes time to translate the language to Chinese, having
all this stuff done in advance means we can drop in a big overlay and
call it translated.




"Bryan C. Warnock" wrote:

> Ideally, it wouldn't involve Yet Another Language, but could be done in
> one of the two Perl already has.  (Or both, I suppose.)  What I don't
> believe should be the goal, although it may be an unfortunate
> side-effect, is to, in essence, write the parser in Perl, and to
> require writing a full parser for every case  That would, in essence,
> require dropping the user parser inline between the lexer and the real
> parser, capturing all the tokens coming out, doing the necessary
> identification and modifications, and passing the new token stream to
> the real parser. I think this was one of Nat's hook areas, and is
> similar to what Chaim suggested with how macros could work.
> This could work with very simple requirements, and could even partially
> extend to adding lexer extensions.  Otherwise, why not just rewrite the
> parser in its entirety, and drop it in as a new front end?
> 
> Alternately, to keep things simple, you could have a signature callback
> type mechanism, where the parser only calls your code upon certain rule
> reductions.  This requires the lexer to have already sent the data to
> the parser, which could make for some icky situations, particularly
> with inspection and modification of what the parser has already done.
> 
> Or, to keep things really simple, have parser pragma types that affect
> the parser internals runtime much like the rest of Perl modules affect
> Perl runtime.  (This would, of course, require the parser to be able to
> support much deeper introspection than it does now.  Yet Another
> Language, more complexity.  But would allow for only a limited number
> of hooks, which would be a little easier to contain and a little less
> scary to deal with.)  This last was basically what I was looking for
> with RFC 40.  This would allow people to write their own pragmas, as
> long as they only needed what hooks were available.  More radical
> changes would involve adding more hooks.
> 
> I'll ponder all this today, and maybe give some examples this evening,
> perhaps showing how some of the current RFCs could be addressed.
> 
>  --
> Bryan C. Warnock
> ([EMAIL PROTECTED])

-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Jarkko Hietaniemi]

On Thu, Aug 10, 2000 at 09:30:05AM -0700, Russ Allbery wrote:
> Bart Lateur <[EMAIL PROTECTED]> writes:
> 
> > As for the parameter's format: GMT is easy, you can pass "GMT" (or
> > "+"). For localtime(), you often don't explicitely know the time
> > zone and Daylight savings Time rule, so this looks like a good candidate
> > for undef.
> 
> The string "GMT" is technically wrong.
> 
> I'm opposed to allowing one to pass in any sort of string for time zone
> information; if you allow "GMT", people are going to expect to be able to
> use "EST", and who knows what they actually mean.  If you want GMT, pass
> an offset of 0.
> 
> Be careful about time zone offsets, btw, if the interface is going to
> support them.  +0700 is *not* "700 minutes"; it's 7 hours and 0 minutes.
> And there are half-hour time zones.  This is an area where there's a *lot*

There are quarter-hour time zones...

> of potential confusion; people in Newfoundland are going to expect to be
> able to pass in -0230 and have that work, and that's interestingly hard.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Overloading && ||

[Damian Conway]

   > We may be able to fake it with source filters and parser abuse, though.

I'm intending to write RFCs on revamping source filters, and also on
run-time access to the parse tree. Just as soon as I grow those two
extra hands so I can run that second keyboard in parallel.

Damian

Re: RFC 73 (v1) All Perl core functions should return ob

[Chaim Frenkel]

Why push it through a user subroutine. Might as well make it part of the
core language.

Why add another keyword non_lazy. though it isn't an antonym, eval{}
has the right meaning and effect.

I can see the utility of having the callee specify the alacrity of the
parameter. But this would put quite a burden on the parser/runtime engine.

Package A and B both define a function foo. A->foo has non-lazy arguments
B->foo has lazy arguments. Then

$fooA = new A;
$fooB = new B;

$fooA->foo 
$fooB->foo 

What is a poor perl parser to do?



> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:

DC> But, of course, lvalue subroutines give you the ability to impose the
DC> choice externally as well. If you need to pass a lazy argument to a
DC> normally non-lazy subroutine, you could just write:

DC> sub enervate (?$) : lvalue { $_[0] }

DC> And then:

DC> non_lazy( a(), enervate(b()), c() );

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

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

[Glenn Linderman]

Perl6 RFC Librarian wrote:

> 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');

I like this.  Implementation wise, it could fit nicely with the DRAFT
structure RFC, which needs things that look like hashes with a constant set of
keys, although for structures, the values can vary with the method calls.
--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne


___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html

Re: RFC: Higher resolution time values

[Nick Ing-Simmons]

Dan Sugalski <[EMAIL PROTECTED]> writes:
>>Why - the 1/10 of second is not exact anyway (unless you happen to
>>have an atomic clock in an appropriate physical enviroment attached to
>>your machine). A double's mantissa is better than your typical oscillator.
>
>While it may not be correct, at least it's exact. 

The importance of the distinction escapes me - where the errors come
from does not matter in the real world.

>If we go with an inexact 
>representation, we run the risk of accumulating errors and eventually 
>ending up with a number that's both inexact and incorrect.

But computer time is always inexact and incorrect - thats why we need NTP.

-- 
Nick Ing-Simmons

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

[Mike Pastore]

On Thu, 10 Aug 2000, Larry Wall wrote:

> 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');
> 

What about:

my %STRUCT : constant = (
 Name =>str 'Jane', 
 Age => int 30,
 Gender =>  str 'Female',
 Kids =>num 2.5
);

or 

my %STRUCT : constant = (
 str Name => 'Jane'
 int Age => 30,
 # etc
);

The reason I ask is because (as my example was intended to show) there can
be many different types of data elements in a hash or a list.

Then again, maybe these types of hashes and lists don't NEED to be made
constant, simply because they're CONSTANT and unchanging.

One more thing: Does the 'constant' refer to the hash (ie, the ability to
add and delete items) or to the individual data elements?

Darn typing!! Darn constants!!

--
Mike Pastore
[EMAIL PROTECTED]

Re: RFC 80 (v1) Exception objects and classes for builti

[Chaim Frenkel]

(I'm not quite in favour. But assuming this flys...)

Why not use Damien's switch syntax. Much more powerful and the flow
is better controlled.

And why add another keyword. Just extend eval{} to accept two blocks.

eval {
}
catch {
}
finally {
}

With the catch block setting the lexical $@ to the exception.

Though, I'm sure that Larry will come up with a better synonym.



> "JP" == John Porter <[EMAIL PROTECTED]> writes:

JP> Peter Scott <[EMAIL PROTECTED]>:
>> 
>> try {
>> # fragile code
>> } catch Exception::IO with {
>> # handle IO exceptions
>> } catch Exception::Socket with {
>> # handle network exceptions
>> } otherwise {
>> # handle other exceptions
>> };

JP> I'd like to recommend just "catch" instead of "otherwise",
JP> because sometimes you'll do this:

JP> try {
JP> # fragile code
JP> }
JP> catch {
JP> # handle other exceptions
JP> };

JP> And it would look silly to use "otherwise" there.

JP> You could make it so "catch" takes a list of 0 or more exception
JP> class names.

JP> -- 
JP> John Porter





-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

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

[Simply Hao]

> my %STRUCT : constant = (
> Name =>str 'Jane',

Isn't this ambiguous, considering that the => operator quotes the
left side?

-Hao

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

[Damian Conway]

   > Instead of calling the right thing or actually doing the right thing,
   > AUTOLOAD subroutines should return a coderef which will be run as if
   > it were the method called. If an AUTOLOAD subroutine does not wish to
   > cope with a method call, it should return undef. Perl would then walk
   > the OO hierarchy and find the next AUTOLOAD to call, eventually failing
   > with an error if no AUTOLOAD method is found which will accept the call.

A more general solution is to allow the AUTOLOAD to resume the dispatch
process. My forthcoming RFC on revamped subroutine dispatch will cover this.

I don't *dislike* your proposal, except that it interposes another layer of
indirection on a process that is already too slow.


   > =head2 $AUTOLOAD
   > 
   > While we're at it, it *may* be a good idea to remove the global
   > $AUTOLOAD variable and instead pass it as the first parameter of the
   > AUTOLOAD subroutine call. For: general global drought, the fact that
   > perlsub's argument "because, er, well, just because, that's why..." is
   > a bit weak. Against: makes AUTOLOAD more complicated, breaking the
   > "subroutine parameters end up as @_" paradigm (apparently).

This, I really like.

   > =head2 UNIVERSAL->can
   > 
   > This proposal has the added bonus that the UNIVERSAL->can method (or
   > whatever replaces it) will now work with AUTOLOAD-ed methods, whereas
   > in Perl 5 it used to fail.

But how would it know whether a particular AUTOLOAD can handle the requested
method without calling that AUTOLOAD and seeing what it returns? Oh, I get
it: it *would* call every AUTOLOAD it found until one of them returned
something? If so, the RFC ought to explain this explicitly.

Damian

Re: RFC 76 (v1) Builtin: reduce

[Chaim Frenkel]

> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:

>> If the original list has no elements, C immediately returns C.

AS> I like everything except this part.  Reducing an empty list should be
AS> an error.

AS> Returning undef (or anything else, really) breaks the algebraic
AS> equivalence that

AS> f((reduce \&f, LIST), $x) eq (reduce \&F, LIST, $x)

I don't see it.

1 == f((reduce +, undef), 1) == reduce +, undef, 1

I really would like to be able to pass around an empty list and get
a _reasonable_ answer. Having to check the list for emptyness before
passing it in just seems dirty. One doesn't have to do this for anyother
looping operator in the language.

for (@empty) {}
grep {} @empty
map {} @empty

etc.

AS> Since this is the single most important property of reduce (indeed, it 
AS> is the *only* property of reduce), I don't see what we get by breaking 
AS> it.

And if your rule is true, then your induction proof is wrong. A list
can be empty.

AS> Also, the RFC should specify that the function is always evaluated in
AS> a scalar context (for things to make sense).

Why? reduce should be able to reduce a set of matrices to a matrix. Or
actually any aggregate (plural whatzit).

I think this is too limiting.

Depending upon the context reduce should return undef, an empty list,
or other empty plural whatzit.


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 73 (v1) All Perl core functions should return ob

[Damian Conway]

   > Why push it through a user subroutine. Might as well make it part of the
   > core language.

Why exacerbate the core, when I one-line user sub can do it?


   > Why add another keyword non_lazy. though it isn't an antonym, eval{}
   > has the right meaning and effect.

No, "non-lazy" was just some ordinary subroutine that I was enervating an
argument for. It certainly isn't part of the proposal.

   > I can see the utility of having the callee specify the alacrity of the
   > parameter. But this would put quite a burden on the parser/runtime engine.
   > 
   > Package A and B both define a function foo. A->foo has non-lazy arguments
   > B->foo has lazy arguments. Then
   > 
   >$fooA = new A;
   >$fooB = new B;
   > 
   >$fooA->foo 
   >$fooB->foo 
   > 
   > What is a poor perl parser to do?

Ignore the prototype unless $fooA and $fooB are typed lexicals.
I.e. act just like it does now.

Damian

Re: RFC 80 (v1): Exception objects and classes for builtins

[Chaim Frenkel]

Nice.

The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the 'else' clause indicate that the exception
was handled?

A couple of possiblities

1. Undef $@. But that's a bit of extra work in each leg.

2. switch is 'slightly' special in an eval/else block. If the case
   selects the error, then it is considered handled unless a die or
   redo is encountered.

3. If continue is not being used by Damian's switch, then a continue
   continues onto the continue block, and marks the successful handling
   of the exception.



> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:

GB> I was more thinking of

GB> eval {
GB> # fragile code
GB> }
GB> else {  # catch ALL exceptions
GB> switch ($@) {
GB> case __->isa('IO') { ... }
GB> case __->isa('Socket') { ... }
GB> else   { ... }
GB> }
GB> }
GB> continue {
GB># code always executed (ie finally)
GB> }

GB> And the only new keywords are for the switch statement.

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 76 (v1) Builtin: reduce

[Damian Conway]

   > I don't see it.
   > 
   >1 == f((reduce +, undef), 1) == reduce +, undef, 1

undef isn't an empty list, it's a one element list.

Consider the other "common" reduction:

sub f { $_[0] * $_[1] }

Now:

f((reduce \&f, ()), 1) == 0 # f(undef,1) -> f(0,1) -> 0
   
But
reduce \&f, (), 1 == 1  # list flattens to (1),
# single element immediately returned


   > I really would like to be able to pass around an empty list and get
   > a _reasonable_ answer. Having to check the list for emptyness before
   > passing it in just seems dirty. One doesn't have to do this for anyother
   > looping operator in the language.
   > 
   >for (@empty) {}
   >grep {} @empty
   >map {} @empty

None of which *combines* its (possibly non-existent) values together.
   
  
   > AS> Also, the RFC should specify that the function is always evaluated in
   > AS> a scalar context (for things to make sense).
   > 
   > Why? reduce should be able to reduce a set of matrices to a matrix. Or
   > actually any aggregate (plural whatzit).
   > 
   > I think this is too limiting.
   > 
   > Depending upon the context reduce should return undef, an empty list,
   > or other empty plural whatzit.

H. I need to see more debate on this before I decide what to propose
in the next version of the RFC.

Damian

Re: RFC 76 (v1) Builtin: reduce

[Ariel Scolnicov]

Chaim Frenkel <[EMAIL PROTECTED]> writes:

> > "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
> 
> >> If the original list has no elements, C immediately returns C.
> 
> AS> I like everything except this part.  Reducing an empty list should be
> AS> an error.
> 
> AS> Returning undef (or anything else, really) breaks the algebraic
> AS> equivalence that
> 
> AS> f((reduce \&f, LIST), $x) eq (reduce \&F, LIST, $x)
> 
> I don't see it.
> 
>   1 == f((reduce +, undef), 1) == reduce +, undef, 1

You're confusing "f()" and "+" here, and (on the LHS) "undef" with
"()".  What you're claiming is that

f(undef, 1) eq 1

for any function f().  While this is true (in Perl) for C<__+__>, it's
not even true for C<__*__>.  And of course there's nothing you can do
about user-specified functions f().

> I really would like to be able to pass around an empty list and get
> a _reasonable_ answer. Having to check the list for emptyness before
> passing it in just seems dirty. One doesn't have to do this for anyother
> looping operator in the language.
> 
>   for (@empty) {}
>   grep {} @empty
>   map {} @empty
> 
> etc.

Think of the first element of the list as different from the rest --
it is the initial value to reduce from (for + and *, you'll usually
pick an appropriate identity element).  By writing

@sum = reduce __+__ 0, @numbers

you deal elegantly with both cases.

NOTE: I find this trick very elegant.  I wish it were my trick,
instead of Damian's...

[...]

-- 
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd.  |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels

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

[Chaim Frenkel]

I'd put it into 

Perl::Option{__Package__} 

There was some talk about making Perl:: special. So that might be the one
and only truely global space.

Hmm, that wouldn't work with multiple versions without cooperation.

Alternatively, we could treat a set 

Perl::Option{FTP::Net}->Debug = 255;

as a method call, and have the package determine it's caller.



> "BT" == Bennett Todd <[EMAIL PROTECTED]> writes:

BT> If the only real problem that can be found with making module use
BT> package-local is in these few option-flag type variables, perhaps
BT> they could be handled differently. E.g. suppose normal package
BT> variables end up being local to the package that "use"-es the
BT> package, and when a package actually wants to make a genuine global
BT> for all users of the package, it explicitly tucks it into a variable
BT> whose name starts with main::. E.g. let Net/FTP.pm post its debug
BT> flag into $main::Net::FTP::Debug, and the list of exception classes
BT> requested of Fatal.pm could be posted into @main::Fatal.

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 76 (v1) Builtin: reduce

[Damian Conway]

   > By writing @sum = reduce __+__ 0, @numbers 
   > you deal elegantly with both cases.
   > 
   > NOTE: I find this trick very elegant.  I wish it were my trick,
   > instead of Damian's...

Damian wishes it were Damian's, but is sure it's at least a few hundred
years old :-)

Damian

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

[Graham Barr]

On Fri, Aug 11, 2000 at 06:22:46AM +1000, Damian Conway wrote:
> I don't *dislike* your proposal, except that it interposes another layer of
> indirection on a process that is already too slow.
   
> 
> 
>> =head2 $AUTOLOAD
>> 
>> While we're at it, it *may* be a good idea to remove the global
>> $AUTOLOAD variable and instead pass it as the first parameter of the
>> AUTOLOAD subroutine call. For: general global drought, the fact that
>> perlsub's argument "because, er, well, just because, that's why..." is
>> a bit weak. Against: makes AUTOLOAD more complicated, breaking the
>> "subroutine parameters end up as @_" paradigm (apparently).
> 
> This, I really like.

But it will slow things down. Firstly because it must be added to the stack
then removed inside the sub.

I don't see any issue keeping $AUTOLOAD as the way the sub name is passed.

>> =head2 UNIVERSAL->can
>> 
>> This proposal has the added bonus that the UNIVERSAL->can method (or
>> whatever replaces it) will now work with AUTOLOAD-ed methods, whereas
>> in Perl 5 it used to fail.
> 
> But how would it know whether a particular AUTOLOAD can handle the requested
> method without calling that AUTOLOAD and seeing what it returns? Oh, I get
> it: it *would* call every AUTOLOAD it found until one of them returned
> something? If so, the RFC ought to explain this explicitly.

But you cannot do that as the AUTOLOAD subs may not just be defining the sub,
they may be doing the work.

And ->can can already be used with AUTOLOADed methods if there is a stub
in place.

Graham.

Re: RFC 80 (v1): Exception objects and classes for builtins

[Graham Barr]

On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote:
> Nice.
> 
> The continue clause, I assume would re-raise an uncaught exception.
> But, a big but. How does the 'else' clause indicate that the exception
> was handled?

By not rethrowing it. ie if it does not want to handle the
error itself it just callsdie;

Which will call PROPAGATE on the object in $@, just like perl5, then
look back up the call-stack for the next eval { }

Graham.

> A couple of possiblities
> 
> 1. Undef $@. But that's a bit of extra work in each leg.
> 
> 2. switch is 'slightly' special in an eval/else block. If the case
>selects the error, then it is considered handled unless a die or
>redo is encountered.
> 
> 3. If continue is not being used by Damian's switch, then a continue
>continues onto the continue block, and marks the successful handling
>of the exception.
> 
> 
> 
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
> 
> GB> I was more thinking of
> 
> GB>   eval {
> GB>   # fragile code
> GB>   }
> GB> else {# catch ALL exceptions
> GB>   switch ($@) {
> GB>   case __->isa('IO') { ... }
> GB>   case __->isa('Socket') { ... }
> GB> else   { ... }
> GB>   }
> GB>   }
> GB> continue {
> GB># code always executed (ie finally)
> GB> }
> 
> GB> And the only new keywords are for the switch statement.
> 
> -- 
> Chaim Frenkel  Nonlinear Knowledge, Inc.
> [EMAIL PROTECTED] +1-718-236-0183
> 

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

[Graham Barr]

On Thu, Aug 10, 2000 at 10:43:02AM -0400, Bennett Todd wrote:
> If the only real problem that can be found with making module use
> package-local is in these few option-flag type variables, perhaps
> they could be handled differently. E.g. suppose normal package
> variables end up being local to the package that "use"-es the
> package, and when a package actually wants to make a genuine global
> for all users of the package, it explicitly tucks it into a variable
> whose name starts with main::. E.g. let Net/FTP.pm post its debug
> flag into $main::Net::FTP::Debug, and the list of exception classes
> requested of Fatal.pm could be posted into @main::Fatal.

And the difference is ?

$ perl -e 'warn \$main::fred::x," ",\$fred::x'
SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1.

Graham.

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

[Bennett Todd]

2000-08-10-17:36:41 Graham Barr:
> And the difference is ?
> 
> $ perl -e 'warn \$main::fred::x," ",\$fred::x'
> SCALAR(0x80dc254) SCALAR(0x80dc254) at -e line 1.

Today there's no difference. If the proposal under discussion were
to pass, and packages' namespaces were to become local to the
namespace where the "use" occurred, then perhaps main::whatever
could be a common, stable, global that they could use for these rare
variables that really need to be common from multiple invokers.

-Bennett

 PGP signature

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

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Replace => (stringifying comma) with => (pair constructor)

=head1 VERSION

  Maintainer: Damian Conway <[EMAIL PROTECTED]>
  Date: 10 August 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 84

=head1 ABSTRACT

This RFC proposes the introduction of a new data type -- the I -- and
the co-opting of the => operator to act as a pair constructor. Most existing
uses of => would be preserved.


=head1 DESCRIPTION

It is proposed that a new data structure, to be known as a I, be
added to the language. The => operator would cease to be a
first-argument-stringifying comma operator, and becomes an anonymous pair
constructor (just as [...] and {...} are anonymous list and hash constructors
respectively). The => operator would return a reference to a pair containing
the two operands to =>.

The first component of a pair would be called its C, and the second, it's
C. It is proposed to either extend the semantics of C and
C to allow them to operate of pair references, or else introduce
two new built-ins -- C and C -- to access the components of a pair.

=head2 Pairs and hashes

A hash could be constructed from a list of pair references. In fact a
hash could be thought of (and perhaps implemented!) as a set of pairs.

Thus:

%hash = ( a=>1, b=>2, 'c', 3 );

does what it does in Perl 5, but works slightly differently. The list being
assigned consists of four elements (not six): a pair reference, another pair
reference, a string, and an integer.

When a pair reference is assigned (in)to a hash, the pair's key becomes
the hash entry's key, and the pair's value becomes the entry's value

As the above example indicates, hashes could still be assigned "flat" lists.


=head2 Pairs and arrays

When a pair reference is assigned (in)to an array, it remains a single scalar
(referential) value. So:

@array = ( a=>1, b=>2, 'c', 3 );

assigns four elements (not six) to @array.


=head2 Pairs and subroutines

When a pair reference is used in the argument list of a subroutine with
no parameter list, it is passed as a single scalar value (i.e it remains
a pair reference).

When a pair reference is passed to a subroutine with named parameters, it
binds its value to the parameter of the same name, regardless of the order
in which it is passed.

Thus:

use Data::Dumper;

sub no_params {
print "no_params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}

sub params ( $name, $rank, $serial_num) {
print "params:\n"
print join "\n", map {ref||"scalar val"} @_;
print Dumper @_;
}

no_params(serial_num=>1234, name=>'demo', rank=>'RFC');

params(serial_num=>1234, name=>'demo', rank=>'RFC');

prints:

no_params:
PAIR
PAIR
PAIR
$VAR1 = ( 'serial_num' => 1234 );
$VAR2 = ( 'name' => 'demo' );
$VAR3 = ( 'rank' => 'RFC' );

params:
scalar val
scalar val
scalar val
$VAR1 = 'demo';
$VAR2 = 'RFC';
$VAR1 = 1234;


Note that these semantics still support the popular:

sub hash_like_args {
my %args = @_;
# etc.
}

hash_like_args(serial_num=>1234, name=>'demo', rank=>'RFC');


=head2 Pairs and multiway comparisons

Pairs also provide a clean way of implementing multiway comparisons.

It is proposed that when a pair is evaluated in a boolean context, it
would evaluate to the truth value of its key. But when evaluated as the left
operand of a comparison operator, it would evaluate to its value,
I would short-circuit if its key were false.

Thus:

1 < 4 < 7 < 9

would be evaluated:

(((1 < 4) < 7) < 9)
(((true=>4) < 7) < 9)   # true because 1 < 4
((true=>7) < 9) # true because 4 < 7
(true=>9)   # true because 7 < 9
1   # boolean context evals to truth of key

On the other hand:

1 < 4 < 7 < 3 < 9

would be evaluated:

1 < 4) < 7) < 3) < 9)
true=>4) < 7) < 3) < 9) # true because 1 < 4
(((true=>7) < 3) < 9)   # true because 4 < 7
((''=>3) < 9)   # '' (false) because !(7 < 3)
''  # short circuits to false



=head1 REFERENCES

Forthcoming Conway RFC on subroutine parameter lists
(including named parameters)

RFC 25: Operators: Multiway comparisons

RFC 85 (v1) All perl generated errors should have a

[Perl6 RFC Librarian]

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

All perl generated errors should have a unique identifier

=head1 VERSION

  Maintainer: Chaim Frenkel <[EMAIL PROTECTED]>
  Date: 9 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 

85

All perl generated errors should have a unique identity. So that
changes in the text should not cause breakage in code.

=head1 DESCRIPTION

Currently many programs handle error returns by examining the text of
the error returned in $@. This makes changes in the text of the error
message, an issue for the backwards compatibility police.

An added benefit, depending upon the actual method of identifing
errors selected could be a classification scheme for errors.

=head1 IMPLEMENTATION

Each unique identifier once assigned as part of a stable release
of perl will be guarenteed never to be changed, or if the error
text is removed, never to be reused.

=head2 Encodings

I have listed some possiblities. But none of these are ideal.

=head3 A unique number

Each error message will be assigned a unique number. The number
could be made accessible via the $@ in a numeric context.

=over 4

=item As an integer

This would be simple and direct

=item As a floating point number

The integer part would be the actual identifier. The fractional
part could encode some classification scheme.

=back

=head3 Unique String

Each error message will have a unique string assigned.

The unique string could be accessible as

$@->unique_id

=head3 Prefixes for all error strings (Shades of Big Blue)

Each error message will have a unique string that will be part of
the text.

For those of you who have ever read through the IBM Codes and Errors
manual this will look familiar.

For example

  FIL0001W unable to close filehandle %s properly
  PAR0003F Can't find label %s


=head2 Classification Schemes

To be defined. Suggestions welcome.

=head1 REFERENCES

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

[Mike Pastore]

On 10 Aug 2000, Perl6 RFC Librarian wrote:

> %hash = ( a=>1, b=>2, 'c', 3 );
> 
> does what it does in Perl 5, but works slightly differently. The list being
> assigned consists of four elements (not six): a pair reference, another pair
> reference, a string, and an integer.

Well, I suppose that takes care of the typing issue.

Nice work.

--
Mike Pastore
[EMAIL PROTECTED]

Re: RFC 76 (v1) Builtin: reduce

[Jeremy Howard]

Damian Conway wrote:
>> AS> Also, the RFC should specify that the function is always
evaluated in
>> AS> a scalar context (for things to make sense).
>>
>> Why? reduce should be able to reduce a set of matrices to a matrix.
Or
>> actually any aggregate (plural whatzit).
>>
>> I think this is too limiting.
>>
>> Depending upon the context reduce should return undef, an empty list,
>> or other empty plural whatzit.
>
> H. I need to see more debate on this before I decide what to propose
> in the next version of the RFC.
>
Couldn't reduce return a list just through concatenating its elements? For
instance:

  @a = (1,3,2,4,3,6,4,8);
  @sum = reduce( (^total, ^x+^y ), @a );  # (4,6,9,12)

I'm not necessarily saying this is the best way, mind you. We've got two
options here:

1- Build the concept of multidimensionality into Perl's proposed arrays
2- Make Perl support only 1d arrays

The benefit of (1) is that we can build the syntax directly to allow
reduction over dimensions, transposition, and so forth. The downside is that
we have to work out a lot more of these details up front.

The benefit of (2) is that we achieve the same thing through fewer language
additions. A rich set of functions for slicing, indirection, partitioning,
and interleaving arrays would allow pure Perl to be used to define
multidimensional behaviour. The downside is that the compiler (and run-time
optimisations) would have to be _extremely_ smart to optimise out all this
indirection when it's actually used.

We probably need to get some feedback from the internals team here--how much
optimisation is possible would impact what notation is suggested, I think.
Or should we propose the full multi-dimensional notation and just let the
internals team implement it in pure Perl if they think that's best?

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[Jeremy Howard]

John Porter wrote:
> Jeremy Howard wrote:
> > The reason that having (1..) implies having (..-1) is that if you allow
> > (1..), then this is a valid construct:
> >
> >   @dot_dot_neg_one = reverse (map {-$_} (1..));
> >
> > which is identical to (..-1)!
>
> No, NOT identical.  The same set of numbers, yes, but generated in
> the opposite order.   (..-1) should generate -INF first, but obviously
> it can't do that.  (..$n) is an impossible construct, and should be
> a fatal error -- presuming it even gets past the lexer...
>
Well, maybe... If you think the idea of 'generation order' is meaningful. I
would have thought that it should look like all the elements are generated
together--since I don't think we want to confuse lists and streams.

Anyhow, maybe this is a moot point. Damian's recanted his RFC, and I'm still
trying to decide whether this is important enough to finish off a redraft of
it that I started...

Re: RFC 80 (v1): Exception objects and classes for builtins

[Chaim Frenkel]

> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:

GB> On Thu, Aug 10, 2000 at 04:34:50PM -0400, Chaim Frenkel wrote:
>> Nice.
>> 
>> The continue clause, I assume would re-raise an uncaught exception.
>> But, a big but. How does the 'else' clause indicate that the exception
>> was handled?

GB> By not rethrowing it. ie if it does not want to handle the
GB> error itself it just callsdie;

GB> Which will call PROPAGATE on the object in $@, just like perl5, then
GB> look back up the call-stack for the next eval { }

Hmm, we must be coming from different backgrounds.

I expect my exception handler to rethrow if not handled. I expect
the continue block to be run under both conditions, and be responsible
for ensuring consistancy.

Let's look at it from how the validity of the data (or object)

# --> Invariant True
eval {
# --> Invariant True

# --> Invariant True
}
else {
# --> Invariant might be invalid
...
# --> 
}
continue {
# --> 
...
# --> Invariant True
}
# --> Invariant True

What would you want at the exit point of the else or the entry point
of the continue? Is the job of the continue to restore the invariant
or is it the job of the else clause.


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 76 (v1) Builtin: reduce

[Damian Conway]

   > Couldn't reduce return a list just through concatenating its elements? For
   > instance:
   > 
   >   @a = (1,3,2,4,3,6,4,8);
   >   @sum = reduce( (^total, ^x+^y ), @a );  # (4,6,9,12)

Currying placeholders are scalars, so you want:

  @sum = @{reduce (@^total, ^x+^y ), [], @a };

More and more I lean towards a scalar-only reduce.

Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need
multidimensionals.

Damian

Re: RFC 73 (v1) All Perl core functions should return ob

[Chaim Frenkel]

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:

>> $fooA->foo 
>> $fooB->foo 
>> 
>> What is a poor perl parser to do?

DC> Ignore the prototype unless $fooA and $fooB are typed lexicals.
DC> I.e. act just like it does now.

Hmm, would it be too nasty for perl to recognize that all foo's have the
same prototype? (Consider the singular foo case.)


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 73 (v1) All Perl core functions should return ob

[Damian Conway]

   > Hmm, would it be too nasty for perl to recognize that all foo's have the
   > same prototype? (Consider the singular foo case.)

Probably. Remember that the programmer can always
C or C and completely change
inheritance hierarchies.

Anyway, the overloading functionality you want will be available
via multimethods, when I get around to writing that RFC.

Damian

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

[Jon Ericson]

Perl6 RFC Librarian wrote:
> The first component of a pair would be called its C, and the second, it's
> C. It is proposed to either extend the semantics of C and
> C to allow them to operate of pair references, or else introduce
> two new built-ins -- C and C -- to access the components of a pair.

> =head2 Pairs and arrays
> 
> When a pair reference is assigned (in)to an array, it remains a single scalar
> (referential) value. So:
> 
> @array = ( a=>1, b=>2, 'c', 3 );
> 
> assigns four elements (not six) to @array.

How do we get keys and values out?

  print $array{a}; # 1 
  print $array{c}; # undef? 3?

  print $array[0]; # 1? a? a=>1?
  print $array[2]; # c

  print join ',', keys @array; # a,b? a,b,c?
  print join ',', values @array; # 1,2,c,3? 1,2,3?

Or are hash operations syntax errors on @array?

  print value $array[0]; # 1
  print join ',', map {key} @array; # a,b? a,b,,?

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King

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

[Brad Hughes]

Perl6 RFC Librarian wrote:
[...]
> This RFC proposes the introduction of a new data type -- the I
[...]

I hereby propose that all current Perl 6 Project Plan deadlines
be extended 3 months so that Damian has more time to come up
with gems like this.  I have no idea if it ultimately makes sense
or will be implemented or just how it would be used, but it's
damn intriguing.

Re: RFC 76 (v1) Builtin: reduce

[Chaim Frenkel]

Okay, then for

reduce &avg $identity, @list

What should $identity be?



> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:

AS> Think of the first element of the list as different from the rest --
AS> it is the initial value to reduce from (for + and *, you'll usually
AS> pick an appropriate identity element).  By writing

AS> @sum = reduce __+__ 0, @numbers

AS> you deal elegantly with both cases.

AS> NOTE: I find this trick very elegant.  I wish it were my trick,
AS> instead of Damian's...

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 76 (v1) Builtin: reduce

[Jeremy Howard]

Chaim Frenkel wrote:
> Okay, then for
>
> reduce &avg $identity, @list
>
> What should $identity be?
>
What's wrong with:

  $average = reduce (^last+^this, @^list) / scalar @^list;
  print $average->([1,3,5]);   # Prints '3'

You don't need to explicitly add a '0' to the front of the summed list.
Although I guess for a geometric average you have to be more careful:

  $geo_average =
reduce (defined(^last)?^last:1 * ^this, @^list)
** (1/scalar @^list);
  print $geo_average->([1,2,4]);   # Prints '2'

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

[Damian Conway]

   > > When a pair reference is assigned (in)to an array, it remains a
   > > single scalar (referential) value. So:
   > > 
   > > @array = ( a=>1, b=>2, 'c', 3 );
   > > 
   > > assigns four elements (not six) to @array.
   > 
   > How do we get keys and values out?

The proposed C and C built-ins (or the extended C and
C) would be used on a pair reference:

print key $array[0];# or perhaps: print keys $array[0];
print value $array[0];  # or perhaps: print value $array[0];

Damian

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

[James Mastros]

A semantic definition of "constant" would be nice.

I'd like to propose the following definition:

A constant value cannot be assigned to, deleted, or used as the argument to
a mutating function/operator.
Doing any of these would be a catchable error.  (However, it can be deleted
by the GC, and thus may have a
DESTROY method.)

It cannot be local()ized, unless the "localizable" flag was given, IE
my $foo = 42 : constant(localizable);  (This should be an error sepperate
from "cannot localize" and "assignment to a constant".)

Note that I use the word "value" and not "variable".

I suggest that additionaly, in a hash if a key is constant, it means that
the key cannot be deleted, but it's value can be changed.  To make the whole
pair constant, set the value to be a constant -- removing the key would
imply deleting the value as well, which is an error.

A hash being constant, or a list being constant implies that all of it's
members are constant.

A ref to a thingy being constant is different from a ref to a constant
thingy.

The constant attribute can never be removed from a variable once it is set.

The localizable flag cannot be added later, but can be removed.

There may be other flags in the future; their addablity/removeablility is
not defined.

The constant attribute is rather odd in that normaly, somthing of the form
"my $foo = 42 : attrib" creates $foo, sets it's "attrib" attribute, and then
assigns 42 to it.
OTOH, the constant attribute is set after the assignment -- otherwise the
assignment would
always be in error!

-=- James Mastros

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Bart Lateur]

On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote:

> people in Newfoundland are going to expect to be
>> able to pass in -0230 and have that work, and that's interestingly hard.

What's so hard? Subtracting 2 hours and 30 minutes from the official
referential time (GMT)? Or the Daylight Savings Time rules?

-- 
Bart.

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Jarkko Hietaniemi]

On Fri, Aug 11, 2000 at 02:09:43AM +0200, Bart Lateur wrote:
> On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote:

Did not.

> > people in Newfoundland are going to expect to be
> >> able to pass in -0230 and have that work, and that's interestingly hard.
> 
> What's so hard? Subtracting 2 hours and 30 minutes from the official
> referential time (GMT)? Or the Daylight Savings Time rules?

Without any further thought I'll just shoot and say the DST rules because
they are legislation and fickle, not logic/astronomy and stable.

> -- 
>   Bart.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

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

[Jon Ericson]

Damian Conway wrote:
>> > When a pair reference is assigned (in)to an array, it remains a
>> > single scalar (referential) value. So:
>> >
>> > @array = ( a=>1, b=>2, 'c', 3 );
>> >
>> > assigns four elements (not six) to @array.

> The proposed C and C built-ins (or the extended C and
> C) would be used on a pair reference:
> 
> print key $array[0];# or perhaps: print keys $array[0];
^^^ Makes sense Mismatch ^ ^ 
> print value $array[0];  # or perhaps: print value $array[0];
   ^ 's'

But what does C do?  Or C?

Jon
-- 
Knowledge is that which remains when what is
learned is forgotten. - Mr. King

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

[Chaim Frenkel]

Shades of LISP, batman.



I can see it now, the '=>' operator will be called cons-ing.

And the new keword for accessing a pair will be CAR and CDR.



Are the two values of a pair restricted in anyway? All your examples
were scalar. What about a plural whatzit or a reference to a plural
whatzit?



> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

PRL> =head1 ABSTRACT

PRL> This RFC proposes the introduction of a new data type -- the I -- and
PRL> the co-opting of the => operator to act as a pair constructor. Most existing
PRL> uses of => would be preserved.


PRL> =head1 DESCRIPTION

PRL> The first component of a pair would be called its C, and the second, it's
PRL> C. It is proposed to either extend the semantics of C and
PRL> C to allow them to operate of pair references, or else introduce
PRL> two new built-ins -- C and C -- to access the components of a pair.

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

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

[Damian Conway]

   > Are the two values of a pair restricted in anyway? All your examples
   > were scalar.

Yes. The two components must be scalars.
The key is stringified iff it's a bareword.
Otherwise no restrictions.
   
   > What about a plural whatzit or a reference to a plural
   > whatzit?

References are fine. Arrays and hashes are not.

Damian

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

[Bryan C . Warnock]

On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote:
> This method of creating constants has three serious drawbacks:

They're also quite heavy, although I think that CONSTSUB was to take
care of that.

What I never understood, although I'm sure there's a very simple
reason, is why it wasn't simply made a read-only scalar.

 -- 
Bryan C. Warnock
([EMAIL PROTECTED])

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

[Nathan Wiger]

> @array = ( a=>1, b=>2, 'c', 3 );

Isn't this just an array of hashrefs in in disguise? Or am I missing
something?

I don't see a problem for adding more ways to do something, my only
problem would be if the "key" and "value" builtins were the only ways to
get to the data. You should be able to get to the data directly.

-Nate

Re: RFC 85 (v1) All perl generated errors should have a

[Bryan C . Warnock]

On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote:
> All perl generated errors should have a unique identity. So that
> changes in the text should not cause breakage in code.
> 

Good idea.  A lot of programs do this.  It could make it easier to
handle error callbacks.  (If you ever get a 'no space left on device'
type error, call remove_my_entire_directory_tree();)

What about compartmentalization of Perl space and user space, though,
when dealing with use of the actual mechanisms?   Gentlemen's
agreement?  User space caveat scriptor?

> =head1 DESCRIPTION
> 
> Currently many programs handle error returns by examining the text of
> the error returned in $@. This makes changes in the text of the error
> message, an issue for the backwards compatibility police.
> 
> An added benefit, depending upon the actual method of identifing
> errors selected could be a classification scheme for errors.
> 
> =head1 IMPLEMENTATION
> 
> Each unique identifier once assigned as part of a stable release
> of perl will be guarenteed never to be changed, or if the error
> text is removed, never to be reused.
> 
> =head2 Encodings
> 
> I have listed some possiblities. But none of these are ideal.
> 
> =head3 A unique number
> 
> Each error message will be assigned a unique number. The number
> could be made accessible via the $@ in a numeric context.

This would, at least, parallel $!'s magic.  Or new pair value, I
suppose.  (RFC - Request From Conway, Required For Conway :-)


> =item As a floating point number
> 
> The integer part would be the actual identifier. The fractional
> part could encode some classification scheme.

Depending on whether you wanted an error to meet multiple
classifications, it may make more sense to switch the two.

CLASS.ERROR

This may make it easier for users to register their own errors under
pre-existing classes.

Another idea would be two shorts, one for each.  (Where you could
either handle numbers or bitmaps.)

-- 
Bryan C. Warnock
([EMAIL PROTECTED])

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

[Glenn Linderman]

Perl6 RFC Librarian wrote:

> The => operator would cease to be a
> first-argument-stringifying comma operator

I find nothing in the documentation that suggests that => is anything other than a
plain comma operator, yet you call it a "first-argument-stringifying comma
operator".  In fact, the documentation explicitly claims "=>" is a synonym of ","
(see perldata).

So I'm curious where you get this from, and what you mean by it, and whether it is
relevant to this RFC.

> Note that these semantics still support the popular:
>
> sub hash_like_args {
> my %args = @_;
> # etc.
> }
>
> hash_like_args(serial_num=>1234, name=>'demo', rank=>'RFC');

But not the (safer) alternative:

 sub hash_like_args {
   my ( $name, $val );
   while ( @_ >= 2 ) {
 $name = shift;
 $val = shift;
 if ( $name eq 'serial_num' ) { ... }
 elsif ( $name eq 'demo' ) { ... }
 elsif ( $name eq 'rank' ) { ... }
 else
  }
}

> =head2 Pairs and multiway comparisons
>
> Pairs also provide a clean way of implementing multiway comparisons.
>
> It is proposed that when a pair is evaluated in a boolean context, it
> would evaluate to the truth value of its key. But when evaluated as the left
> operand of a comparison operator, it would evaluate to its value,
> I would short-circuit if its key were false.

This is extremely strange, to say the least, but that's no reason not to do it.

While this technique does allow pairs to achieve multiway comparison based on
context tricks together with the above pair evaluation technique, it would require
rewriting every overloaded comparison operator to produce a pair, rather than a
boolean.  Maybe p52p6 could handle most cases of this rewriting, but in general it
would be extremely hard.  But it seems that the existing operators (and overloaded
functions) could continue to be used and achieve the same result, if the language
syntax were enhanced to directly support multiway comparisons.  For an expression
such as

 if (( e1 ) < ( e2 ) < ( e3) < ( e4 ))

the first two operands could be evaluated, saved in temporarys, passed to <, and
based on the pure boolean result, a choice could be made about continuing.  If
false, the whole expression would be false.  If true, e3 could be evaluated, and
the saved value of e2 and e3 passed to <, and proceed as before.

While your pairs certainly achieve the same logic flow, I don't see that this trick
is particularly beneficial... as it forces extra baggage (generation of the pair)
onto binary comparisons.

> RFC 25: Operators: Multiway comparisons

My comments in summary are:

With an appropriate prototyping system, perhaps pairs would be useful for named
scalar arguments to subs.  Quite a few have complained about missing the $ in other
named parameter proposals though, and pairs neither help that, nor provide help for
passing arrays or hashes by name.

Using pairs for multiway comparisons could be an implementation technique, but
seems unnecessary and somewhat more incompatible than just changing the language
definition to support multiway comparison.

Perhaps pairs might even be useful for other things, but what?  They _seem_ like
they could be useful, the syntax proposed doesn't seem too harmful, but I haven't
found a compelling benefit in this RFC.

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

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

[Damian Conway]

   > I find nothing in the documentation that suggests that => is
   > anything other than a plain comma operator, yet you call it a
   > "first-argument-stringifying comma operator". In fact, the
   > documentation explicitly claims "=>" is a synonym of "," (see
   > perldata).

The Perl documentation contains only a second approximation to Perl. :-)

The perl interpreter contains the first approximation.
(For those who are wondering: Larry's brain contains the zero'th approximation)


   > So I'm curious where you get this from,

>From the fact that => currently converts any bareword left operand to a string.


   > and what you mean by it,
   
That => currently converts any bareword left operand to a string.


   > and whether it is relevant to this RFC.

Yes, because it's proposed that this aspect of =>'s behaviour be preserved.


   > > Note that these semantics still support the popular:
   > >  [SNIP]
   > 
   > But not the (safer) alternative:
   >[SNIP]

Sure they do. p52p6 would handle the change in semantics by mapping
every Perl 5 instance of:

bareword => $whatever
to:
'bareword', $whatever

and every remaining instance:

$non_bareword => $whatever
to:
$non_bareword, $whatever

   
   > With an appropriate prototyping system, perhaps pairs would be
   > useful for named scalar arguments to subs. Quite a few have
   > complained about missing the $ in other named parameter proposals
   > though,

And they're wrong. :-)
The variables *shouldn't* appear in the calling scope, only their *names*.

   
   > and pairs neither help that, nor provide help for passing
   > arrays or hashes by name.

This can be correctly handled. The named parameter's context specifier
would be propagated to the right operand of the =>. So:

sub demo ( $name, \%options ) {...}

will accept:

demo(options=>%myopts, name=>'my name');

because the C<\%> prototype for the parameter <\%options> will be
propagated to the right operand of C%myopts>, causing it
to act like C\%myopts>.

Damian

Re: RFC 85 (v1) All perl generated errors should have a

[Peter Scott]

>=head1 TITLE
>
>All perl generated errors should have a unique identifier

This looks awfully similar to RFC 80.  Certainly the exception objects RFC 
80 is thinking about can well have unique numeric attributes.

>All perl generated errors should have a unique identity. So that
>changes in the text should not cause breakage in code.

Amen.  Can this be merged with RFC 80, or do they need to live apart?

>=head1 IMPLEMENTATION
>
>Each unique identifier once assigned as part of a stable release
>of perl will be guarenteed never to be changed, or if the error
>text is removed, never to be reused.
>[...]
>or those of you who have ever read through the IBM Codes and Errors
>manual this will look familiar.
>
>For example
>
>   FIL0001W unable to close filehandle %s properly
>   PAR0003F Can't find label %s

Or %VMS-F-ACCVIO, access violation :-)

>=head2 Classification Schemes
>
>To be defined. Suggestions welcome.

I made a start in RFC 80.
--
Peter Scott
Pacific Systems Design Technologies

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[Peter Scott]

At 02:39 PM 8/10/00 -0500, Jarkko Hietaniemi wrote:
>There are quarter-hour time zones...

And then there's Damian, who lives in a non-linear time zone...

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 80 (v1) Exception objects and classes for builti

[Peter Scott]

At 12:59 PM 8/10/00 -0400, John Porter wrote:
>I'd like to recommend just "catch" instead of "otherwise",
>because sometimes you'll do this:
>
> try {
> # fragile code
> }
> catch {
> # handle other exceptions
> };
>
>And it would look silly to use "otherwise" there.
>
>You could make it so "catch" takes a list of 0 or more exception
>class names.

I like this.  I will modify RFC 63 accordingly, although I note that RFC 88 
is proposing something extremely similar.
--
Peter Scott
Pacific Systems Design Technologies

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

[Chaim Frenkel]

Perhaps a pair is a degenerate pseudo-hash (but then a pseudo-hash is 
degenerate period.)

So the correct access should be

print keys %$array[0]

During the give and take of Topaz, having arrays and hashes have similar
access functions was bandied about. So that one could possibly have
a hash with a well defined array access. (Alphabetical, insertion order)

What such a syntax would look like?

Maybe it would fit in with only allowing a single whatzit under a
single name? (Not that I like that idea. I like having the index
be the same as the array. $account{$account}.)

So that $plural_whatzit[5] would access the 5th key in %plural_whatzit.

Confusion will reign.



> "JE" == Jon Ericson <[EMAIL PROTECTED]> writes:

JE> Damian Conway wrote:
>> > > When a pair reference is assigned (in)to an array, it remains a
>> > > single scalar (referential) value. So:
>> > >
>> > > @array = ( a=>1, b=>2, 'c', 3 );
>> > >
>> > > assigns four elements (not six) to @array.

>> The proposed C and C built-ins (or the extended C and
>> C) would be used on a pair reference:
>> 
>> print key $array[0];# or perhaps: print keys $array[0];
JE> ^^^ Makes sense Mismatch ^ ^ 
>> print value $array[0];  # or perhaps: print value $array[0];
JE>^ 's'

JE> But what does C do?  Or C?

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 76 (v1) Builtin: reduce

[Glenn Linderman]

Damian Conway wrote:

> Currying placeholders are scalars

Is that a general truth?  It wasn't obvious from RFC 23... If you rev it, perhaps
you could make that clearer.

Looking back, the defining example did give a list of (;) in the prototype.  I
suppose it would be pretty complex to infer the type from the expression, unless
the placeholder syntax were extended to ^$_, ^@_, ^%_, and similar for named and
positional placeholders...  Seems like if we get matrix ops (via other RFCs) that
we might want to curry them?

Here I was thinking a placeholder was a whatzitz whatzitz; of unknown cardinality.
Is it, or not?

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



_NetZero Free Internet Access and Email__
   http://www.netzero.net/download/index.html

Re: RFC 80 (v1): Exception objects and classes for builtins

[Peter Scott]

At 05:44 PM 8/10/00 +0100, Graham Barr wrote:
>In fact the syntax could be
>
>   eval {
>   }
>   continue {
>   }
>
>   switch ($@) {
>   } if $@;
>
>I just don't see the need to make perl look like other languages just for
>the sake of makeing it look like other languages.

No, I wasn't thinking that at all.  Although devil's advocate compels me to 
point out that Perl has often included features from other languages for 
the sake of familiarity, and even (according to documentation) on occasions 
when it considered said features broken (example: C operator precedence).

But one could argue at this point that Perl's gravitational pull is now 
sufficient for it to borrow from itself rather than other languages, as you 
have done above.  I just found the try/throw/catch syntax really appealing, 
and it was a bonus that it would be instantly familiar to the C++/Java crowd.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 89 (v1) Controllable Data Typing

[Decklin Foster]

Syloke Soong <[EMAIL PROTECTED]> writes:

>   my $varname type;

The syntax

my $varname : constant; # pun not intended :)

Was brought up earlier (but probably not before this RFC was written).
Perhaps something similar could be used for the sake of consistency.

>   if ($somecondition){push @allowedtypes , double}

Is C a bareword here? (pardon my ignorance...) That may or may
not interfere with the above suggestion.

-- 
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)

Re: RFC 80 (v1): Exception objects and classes for builtins

[Peter Scott]

At 05:44 PM 8/10/00 +0100, Graham Barr wrote:
>Well what is the difference between try and eval ?

There isn't any.  I could have sworn I once read that the block eval was so 
different from the string eval that Larry wanted to use 'try', but didn't 
want to add another keyword, but later wished he had.  I couldn't find 
this, and the current docs give no hint of remorse, so it could all be a 
scurrilous figment of my imagination.

It appears that the majority favors eval, though...

--
Peter Scott
Pacific Systems Design Technologies