Re: RFC 361 (v1) Simplifying split()

[Bryan C . Warnock]

On Sun, 01 Oct 2000, Sean M. Burke wrote:
> If you want to remove trailing fields, under Perl 6 you should have to
> do it explicitly:
> 
>Perl 5:   @x = split /:/, $bar;
>   be synonymous with
>Perl 6:   @x = split ':', $bar;
>  while(@x and !length $x[-1]) { pop @x }

Which, to me, is a good reason to keep the current behavior.

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

RFC 290 (v3) Better english names for -X

[Perl6 RFC Librarian]

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

=head1 TITLE

Better english names for -X

=head1 VERSION

  Maintainer: Adam Turoff <[EMAIL PROTECTED]>
  Date: 24 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 290
  Version: 3
  Status: Frozen

=head1 ABSTRACT

Many programmers who have not used Perl's -X (or sh's -X) file tests
find them to be bizarre, arcane and confusing.

They deserve better 'use english;' names.

=head1 NOTES

The first version of this RFC proposed removing -X entirely, since
it was a throwback to Perl's roots in sh.  That proposal was quite
vigorously shot down.  The discussion centered around creating
good descriptive names around the -X tests.  

While discussing -X, the idea came about to stack multiple tests
into a single tests, e.g. mutate -r && -w && -x into -rwx $file
(or something).  See RFC 320 for details.

=head1 DESCRIPTION

Tom Christiansen proposed this in his perl6storm message:

=item perl6storm #0101

Just like the "use english" pragma (the modern not-yet-written
version of "use English" module), make something for legible
fileops.

is_readable(file) is really -r(file)

note that these are hard to write now due to -s(FH)/2 style
parsing bugs and prototype issues on handles vs paths.

Here is a list of possible 'use english;' names for -X:

-r  freadable()
-w  fwriteable()
-x  fexecable()
-o  fowned()

-R  Freadable()
-W  Fwriteable()
-X  Fexecable()
-O  Fowned()

-e  fexists()
-z  fzero()
-s  fsize()

-f  ffile()
-d  fdir()
-l  flink()
-p  fpipe()
-S  fsocket()
-b  fblock()
-c  fchar()
-t  ftty()

-u  fsetuid()
-g  fsetgid()
-k  fsticky()

-T  ftext()
-B  fbinary()

-M  fage()
-A  faccessed()
-C  fchanged()

=head1 MIGRATION ISSUES

None.  New symbolic names for -X are being added.

=head1 IMPLEMENTATION

Add appropriate hooks into 'use english;', and possibly export
them as 'use english "filetests";'

=head1 REFERENCES

RFC 320:

perl6storm

RFC 287 (v2) Improve Perl Persistance

[Perl6 RFC Librarian]

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

=head1 TITLE

Improve Perl Persistance

=head1 VERSION

  Maintainer: Adam Turoff <[EMAIL PROTECTED]>
  Date: 24 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 287
  Version: 2
  Status: Frozen

=head1 ABSTRACT

Many mechanisms exist to make perl code and data persistant.  They should
be cleaned up, unified, and documented widely within the core
documentation.

=head1 DESCRIPTION

Tom Christiansen proposed this in his perl6storm message:

=item perl6storm #0022

make marshalling easy.  core module?  would this allow for easy
persistence of data structures other than dbm files?
general persistence is hard, right?  can this be an attribute?

Python offers one way to make code/data persistant: the C interface.
More complex serialization can be accomplished through the 'shelve'
interface or DBM files.  This capability is quite useful, widely known and
easily used.

Perl, by comparison, offers Data::Dumper, which can serialize Perl objects
that are rather asymetrically reconstituted by using C or C.  
Perl also offers solid, simple interfaces into DBM and Berkeley DB files,
and offer a well known, low-level serialization mechanism.  

CPAN offers many other serialization modules that are only slightly
different than Data::Dumper.  This plethora of serialization mechanisms
confuses users and adds to code bloat when multiple modules each use
different serialization mechanisms that are all substantially similar.

Something similar to Python's C interface should be added into Perl
as a builtin; this feature should have a symmetric "restore" builtin (eg 
save()/restore(), freeze()/thaw(), dump()/undump()...).

Furthermore, Perl's low level serialization machinery (DBM, SDBM, GDBM,
Berkeley DB) should be unified into a single core module, where the
underlying DBM implementations are pluggable drivers, like DBI's DBD
infrastructure.

=head1 IMPLEMENTATION

First, the issue of adding builtin serialization functions needs to be
addressed.  This is a language issue because serialization should be more
visible than it is today, and the best way to accomplish that is to include
this feature as a pair of builtin functions.  

If this feature is implemented through a core module, that module might
best be presented as a pragmatic module.

Finally, although this proposal describes a simple matter of programming,
some of the issues (such as pluggable interfaces) are best hashed out at a
language-design level, so that they may be used elsewhere, easily.

=head1 REFERENCES

Python Pocket Reference, Chapter 12

perl6storm

RFC 358 (v1) Keep dump capability.

[Perl6 RFC Librarian]

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

=head1 TITLE

Keep dump capability.

=head1 VERSION

  Maintainer: S. A. Janet <[EMAIL PROTECTED]>
  Date: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 358
  Version: 1
  Status: Developing

=head1 ABSTRACT

To simplify distribution of programs in binary form,
support for dump should be kept.

=head1 DESCRIPTION

This would immensely aid distribution of code from one Linux, Windows,
etc. machine to others without requiring all the recipients to be able
to install Perl, compile and install modules required by the program,
and configure their hosts so that Perl find the modules.  There are
also times when pre-loading and pre-processing large amounts of data
are desirable.

=head1 IMPLEMENTATION

RFC 267 wants dump eliminated mainly because it is a common name for
user subroutines, bit also because it can be accomplished with a kill
signal. I really do not care if dump is renamed, but I believe keeping
the capability is in perl's interest for greater acceptance and use.

=head1 REFERENCES

None.

RFC 361 (v1) Simplifying split()

[Perl6 RFC Librarian]

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

=head1 TITLE

Simplifying split()

=head1 VERSION

  Maintainer: Sean M. Burke <[EMAIL PROTECTED]>
  Date: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 361
  Version: 1
  Status: Developing

=head1 ABSTRACT

Perl 5's C function is messy, and should be simplified.

=head1 DESCRIPTION

Perl 5 split does five things that I think are just annoying, and
which I suggest be removed:

=over

=item 1. The first argument to split is currently interpreted as a
regexp, regardless of whether or not it actually is one.  (Yes,
C doesn't split on dot -- it's currently the same an
C.)  I suggest that split be changed to treat only
regexps as regexps, and everything else as literals.

=item 2. Empty trailing fields are currently suppressed (although a
-1 as the third argument disables this).  I suggest that empty trailing
fields be retained by default.

=item 3. When not in list context, split currently splits into @_.  I
suggest that this side-effect be removed.

=item 4. split ?pat? in any context currently splits into @_.  I suggest
that this side-effect be removed.

=item 5. split ' ' (but not split / /) currently splits on whitespace,
but also removes leading empty fields.  I suggest that this
irregularity be removed.

=back

The last three of the above points speak for themselves.  I will focus
on the first two.

Most notably, I suggest that Perl 6 C should work as
most people expect -- splitting on a literal bar.  (Under Perl 5,
C is synonymous with C -- i.e.,
split on nullstring or nullstring [sic].)

So I suggest:

   Perl 5:  split /\|/, ...
  be synonymous with (and be better written as)
   Perl 6:  split '|', ...
   # altho  split /\|/, $bar...  remains valid

And as to the second point, the removal of trailing blanks, I suggest:

   Perl 5:   @x = split /:/, $bar, -1;
  be synonymous with
   Perl 6:   @x = split ':', $bar;

If you want to remove trailing fields, under Perl 6 you should have to
do it explicitly:

   Perl 5:   @x = split /:/, $bar;
  be synonymous with
   Perl 6:   @x = split ':', $bar;
 while(@x and !length $x[-1]) { pop @x }

I believe that the current behavior of removing trailing empty fields is
unintuitive and surprising to learners; nothing about the concept of
splitting a string into a list suggests removing trailing empties.
(Moreover, I find that when I need to remove empties, it's not just the
trailing ones; so the current behavior is rarely just what I want.)

=head1 IMPLEMENTATION

I'll leave the C-coding details to the usual, capable implementers.

But I will note one minor complication with my first suggestion (that
literals and regexps be distinguished).  Consider:

  Perl 6:   @x = split $foo, $bar;

I suggest that the correct approach is to treat $foo's value as a
literal, unless it holds an object of class Regexp (or a class derived
from it?), in which case it should be treated as if the above were:

  Perl 6:   @x = split qr/$foo/, $bar;

In other words, in such cases it is not possible to know at compile time
whether a given "split" operator means literal-split or regexp-split.
I note that such cases are rare.

=head1 ALTERNATIVE APPROACH

In conclusion, I'll note that there is a conservative alternative
approach possible: if any of the above features of Perl 5 split seem
really worth keeping, my suggestion for a "clean split" can be
implemented as a separate operator called, for example, "cleave".

(Consider the precedent of Perl 5 chomp being added alongside Perl 4
chop, not replacing it.)

I would consider this suboptimal, though; I think that an operator with
as straightforward and intuitive a name as "split" should behave in a
straightforward and intuitive way.

=head1 REFERENCES

Nil.

Re: RFC 229 (v2) Variable interpolation on demand.

[Bart Lateur]

On Fri, 29 Sep 2000 15:30:46 -0500, David L. Nicol wrote:

>it's not a new feature.  It's amazing the subtle control you
>can get with s/(\$...)/$1/ge depending on your 
>
>Wrapping such a critter up in a tied scalar sounds like a total
>piece of cake

What will you do with:

${foo}bar
$hash{blah}
$ary[blah]
\xFE
\123
\n\t

etc?

Some huge piece of cake.

-- 
Bart.

RFC 357 (v1) Perl should use XML for documentation instead of POD

[Perl6 RFC Librarian]

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

=head1 TITLE

Perl should use XML for documentation instead of POD

=head1 VERSION

  Maintainer: Frank Tobin <[EMAIL PROTECTED]>
  Date: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 357
  Version: 1
  Status: Developing

=head1 ABSTRACT

Perl documentation should move to using XML as the formatting language,
instead of using POD.  XML has many advantages over POD, and would
address several problems POD is reaching as it expands beyond its
original designs.

=head1 DESCRIPTION

POD, described in L, is currently the de-facto language
for Perl-related documentation.  It is a simple language, with simple tags.
According to L, simplicity was
behind the intended design of POD.  There exist several tools to convert
POD into HTML, manpages, text, and other languages.

However, POD can be confusing to learn, and has many limitations.  XML, on
the other hand, is a document language that is designed for high
extensibility, and little ambiguity.  XML is flexible, relying on Document
Type Definitions, DTD's, (recently, also XML Schemas), which define the
document structure being used by the author.  For example, a copy of the
DTD for XHTML may be found at
C.  Knowledge of how to
write or work with DTD's is not necessary for an XML-author; the author
need only know the effect of the DTD or XML Schema.

In the following few sections I will try to compare various
aspects of POD versus XML.

=head2 Syntax

POD's in-line tags use the general form CbodyE>, while
Primarily, XML uses balanced tags, e.g.,
CtagEbodyE/tagE>.  POD's in-line tags tend to
be single-letters, and this can be thought of an argument
for the readability of POD in it's un-rendered form, but
an XML DTD for Perl documentation could also define
single-letter tags to minimize this.

POD's tagging, althrough simple, can produce confusing code.
For example, to render the following (CbodyE>)
I need to have (CEtagEEltEbodyEEgtEE),
which is horrendous in its own (look at the source to this document).
It is especially hard to understand, since one would expect
C to be an inseparable string; yet, reading, one needs
to use look-ahead to see what is following the E.

XML, on the other hand, uses & as the escaping mechanism, helping
a reader sort-out deeply-nested escapings.

=head2 Use of Tags and Rendering

Several of POD's tags do not necessarily relate to the meaning
of the text, but how the text is rendered.  For instance,
CtextE> is used to italicize text, not give meaning,
although L mentions that this should be used for emphasis
or variables.

This sort of style in having tags say how something
should be rendered is something XHTML and friends have tried
to get away from, instead having the presentation of the document
separate from the structuring/tagging of it.
XHTML and XML user-agents use stylesheets to render documents separately
from the document itself; this allows the developer to merely
give I to the document, instead of deciding how it will
be rendered; the choice of how to render is left to the user, with
the use of a stylesheet.

The use of using tags solely to give meaning also helps accessibility
problems for the visually-impaired; for example, having
bold text (e.g., BEfoobarE) is not quite as meaningful
as strongly-emphasized text (e.g, EstrongEUsing meaning
makes things accessible!E/strongE).

The use of stylesheets along with XML allows
documents to be rendered very well in a variety of
circumstances, such as manpages, a continuous-display browser
(e.g., web-browser), and in printed form.

=head2 Whitespace

This can be confusing for many, as whitespace in most languages
does not have functionality.  However, in POD, lines beginning
with a whitespace character are treated as pre-formatted text.
This has already caused an RFC to take effect, RFC 216.

XML, on the other hand, uses properties to determine the
whitespace handling between different types of tags; for example,
a tag in a Perl XML DTD tag such as EperlE could be used to
surround pre-formatted Perl code.

=head2 Learning Curve

Who knows what languages people will base their knowledge off
of in 2 years?  Noone really does, but HTML-style, balanced-tag
languages are a good guess though, given the web's popularity, and
easy-to-grasp notion of having balanced-tags.  On the other hand,
POD will be Yet Another Language to learn, distinct from other typing systems
the user will know.  While this may not seem
like a problem since POD is designed to just be a simple
language, will likely become more complicated in the future
(see L<"Extensibility">).

=head2 Author Effort

POD has the advantage in that it has syntax that is quick and easy
to type, such as CE$var++E instead of an XML/XHTML
EcodeEvar++EcodeE.

However, author effort pays off immensely on the reader's end.
By using a structured, widely-supported language such as XML,
the reader is able to re

RFC 356 (v2) Dominant Value Expressions

[Perl6 RFC Librarian]

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

=head1 TITLE

Dominant Value Expressions

=head1 VERSION

  Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
  Date: 29 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 356
  Version: 2
  Status: Frozen

=head1 ABSTRACT

An aid to determining if an input  value has an impact on the result of
an expression whole program.  Can also be used for Perl poetry.

=head1 CHANGES

Version 2 adds output function, examples, and freezes.

=head1 DESCRIPTION

This  is an  optional  feature; to  turn  it on,  "use domination;"  is
suggested.

When use domination  is in scope, two new  functions are available, and
new rules for expression evaluation obtain.  Each of these is described
in a subsection below.

=head2 Domination pragma

The "use domination 'output-function-name';" pragma enables the rest of
the  functionality.  It  should be  scoped, affecting  the  current and
nested blocks.  domination;", but allows user specification of a method
to  use  to  convert  dominant  values  to  output  strings.   This  is
implicitly  called only  when an  output  stream is  passed a  dominant
value.   If   an  output-function-name   is  not  supplied   with  "use
domination;", the following function is implied:

  sub output-dominant-value {
return sprintf "DOMINANT(%g)", dominant_weight($_[0]);
  }

The  "no  domination;"  pragma  would  turn  off  the  effect  of  "use
domination;" for the current and nested blocks.  If a dominant value is
encountered  while "no  domination;" is  in  effect, it  is treated  as
"undef" by all scalar operators.


=head2 Dominant operation

The dominant operation takes a  scalar argument, which is considered to
be a weight parameter.  The scalar argument is converted to numeric, if
possible,  with the  resultant  positive weight  parameter producing  a
dominant value with  that given weight.  A scalar  argument that cannot
be automatically converted  to numeric, or that produces  a negative or
zero numeric value produces undef as a result.

   dominant 47# produces a dominant value of weight 47
   dominant 0 # produces undef
   dominant -47   # produces undef
   dominant "ab"  # produces undef
   dominant "14"  # produces a dominant value of weight 14
   dominant undef # produces undef (and a warning if "use warnings")

=head2 Dominant_weight operation

The dominant_weight  operation takes a scalar argument.   If the scalar
argument  is a  dominant value,  it returns  its weight  as  a positive
number.  If the scalar argument is  not a dominant value, the return of
the dominant_weight operation is zero.

   dominant_weight dominant 47   # produces 47
   dominant_weight dominant 0# produces 0
   dominant_weight dominant -47  # produces 0
   dominant_weight dominant "ab" # produces 0
   dominant_weight dominant "14" # produces 14
   dominant_weight 47# produces 0
   dominant_weight 0   # produces 0
   dominant_weight "ab"  # produces 0
   dominant_weight "14"# produces 0
   dominant_weight undef # produces 0 (and a warning if "use warnings")

=head2 Expressions involving dominant values

All scalar operations are affected  by the presence of dominant values.
If a scalar operation other than the dominant_weight operation involves
one  or  more dominant  values,  the result  of  the  operation is  the
heaviest (by weight) dominant value among the operands.  If no dominant
values are  supplied to the operation,  the result of  the operation is
the  same as  it would  be  according to  the usual  definition of  the
operation.

   use domination;
   $w = dominant 3;
   $x = dominant 47;
   $y = 33;
   $z = "abc";

   $x + $y# produces dominant 47
   $w . $z# produces dominant 3
   $w - $x# produces dominant 47
   "$z $x"# produces dominant 47
   $z =~ m/$w/;   # produces dominant 3
   $x =~ m/$z/;   # produces dominant 47
   defined $w # produces dominant 3
   $x == $x   # produces dominant 47
   $w eq $w   # produces dominant 3
   $w > 17# produces dominant 3
   $x > 17# produces dominant 47
   print "Show me: $w\n"  # same result as: print "DOMINANT(3)"

   if ( $w )   # considered false
   if ( dominant_weight $w > 17 )  # false
   if ( dominant_weight $x > 17 )  # true

=head1 COMPATIBILITY

New functionality, no compatibility issues.  The new functionality only
obtains if the "use domination;" pragma is in effect.

=head1 IMPLEMENTATION

The impact  of dominant value  expressions is pervasive,  affecting all
builtin scalar operators  in a minor way.  Any  operators doing item by
item operations  on each scalar  of a list  or hash would  be similarly
affected (various RFCs exist for extending scalar operations to work on
lists of values in "corresponding item" fashion).

=head1 REFER

RFC 142 (v2) Enhanced Pack/Unpack

[Perl6 RFC Librarian]

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

=head1  TITLE

Enhanced Pack/Unpack

=head1  VERSION

  Maintainer: Edwin Wiles <[EMAIL PROTECTED]>
  Date: 22 Aug 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 142
  Version: 2
  Status: Frozen
  Submitted by: Glenn Linderman <[EMAIL PROTECTED]>

=head1  ABSTRACT

Pack and Unpack are percieved as being difficult to use, and
possibly missing desirable features.

=head2  Notes on freeze

Edwin on vacation, co-author deems appropriate to freeze
without changes.  Most discussion happened with "draft" RFCs before
the original submittal, anyway.

=head1  DESCRIPTION

The existing pack and unpack methods depend upon a simple
grammar which leads to opaque format specifications, which are
often difficult to get right, and which carry no information
regarding variable names.

A more descriptive grammar, which includes variable name
associations, would make pack and unpack easier to use.

=head1  IMPLEMENTATION

Given the expressed desire to shrink the overall size of the
perl executable, this should be implemented as a seperate
module; included with the core distribution.

=head2 Definition

$foo = new Structure(...definition...);

Define a new structure type.  Can use previously defined
user data types.  See the section on definitions.

Structure::define( $typename, \&from_sub, \&to_sub );

Define a user data type.  The 'from_sub' extracts data
from the packed form.  The 'to_sub' puts data back into
the packed form.  See the section on user defined types.

=head2 Input

$foo->read();
# sysread binary data from given IO reference.

$foo->set($var);
# accept binary data from normal perl
# variable.

$foo->append($var);
# append binary data to the existing data in
# the structure.

=head2 Output

$foo->write();
# syswrite binary data to given IO reference.

$var = $foo->get();
# output binary data to normal perl variable.

=head2 Maniuplation

$foo->{'name'} = $val;  # set "name" to value
$val = $foo->{'name'};  # get value of "name"

[Note: There is an alternative method, using the Class::Class
method of exposing the variables via their names.  That is
still a possibility, but this is deemed easier to implement at
this time.]

=head2  Data Definition

DEFINITION := '[' ELEMENTS ']'

ELEMENTS := ELEMENT [',' ELEMENTS]

ELEMENT := NAME '=>' TYPE

NAME := Text used to identify the variable for further use.
You may not use 'array', it is reserved.  You may not
embed whitespace.

TYPE := ''' BASETYPE [ '/' MODIFIERS ] '''
 |  '[' ARRAYDEF ']'
 |  USERDEFINED [ '/' UDEFARGS ]

BASETYPE := 'short'
 |  'long'
 |  'int'
 |  'double'
 |  'float'
 |  'char'
 |  'byte'

 In each of the above, unless otherwise modified, the
 type defaults to the signedness, endianness, and bit
 length that your system normally uses.  The one
 exception to this is 'char', which Unicode may cause
 to be larger than a single byte, even if your system
 normally considers a 'char' to be a single byte.

 |  'chars' A null terminated string of characters.
If unicode is used, this may be more
than one byte per character.  For use
with indefinite length strings, where
a "count" is not provided.  If the
array modifier is used, then you're
expecting that many null terminated
strings.

 |  'bytes' A null terminated string of bytes.
If the array modifier is used, then
you're expecting that many null
terminated strings of bytes.

 [Note: Other basetypes desired can certainly be
 added.  It were best if they were added at this
 phase.  Inform me of any additional base types
 desired, with justifications.]

UDEFARGS := UDEFARG [ ',' UDEFARGS ]

UDEFARG := User defined argument, meaning dependent upon user
   defined code.  Pretty much, any legal Perl
   constant.  At least, by the time it hits this
   module, it better be constant.

USERDEFINED := A user defined type name, see the section on
   user defined data types.

  

Re: RFC 339 (v1) caller->eval BLOCK

[Greg Williams]

On Sep 30 2000 22:38:58, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:

>=head1 ABSTRACT
>
>C is extended to allow complete access to the "call frame" of
>the current subroutine call.
>

would this be better suited by the previously proposed (i'm not sure for perl6 though) 
C pragma?  Looks like Nathan Wiger has already proposed a 'scope' pragma in 
RFC 64, but it does not cover this functionality as far as I know...

as I remember, the C pragma, when used, would simply act as if the 
enclosing scope were not in place, enabling such things as:
if ($ints) {
  no scope;
  use integer;
}

Tom Christiansen brought up the idea on p5p at:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00863.html

.greg

RFC 115 (v3) Overloadable parentheses for objects

[Perl6 RFC Librarian]

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

=head1 TITLE

Overloadable parentheses for objects

=head1 VERSION

  Maintainer: pdl-porters team <[EMAIL PROTECTED]>
  Date: 16 Aug 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 115
  Version: 3
  Status: Frozen

=head1 DISCUSSION

There was hardly any response to this RFC. That can be
interpreted in a number of ways C<;)>. RFC 231 suggests
an alternative way to get what we tried to get from
this RFC: Syntactical ease of making slices of multidim
array objects. RFC 231 suggests

   $a->[1..3; 4] * $b->[];

>From our point of view this is not too bad but we would like
to get rid of the requirement for C<-E>. An extended C
mechanism with possibility of overloaded operations on those
arrays might do it. But then again, if we get all those
polymorphic methods we could also allow the one suggested by
this RFC -- TIMTOWTDI.

=head1 ABSTRACT

This RFC proposes syntactic support for a polymorphic method
that can be defined for blessed references. It would
allow the parentheses C<()> to be used for a variety of convenient
syntaxes for objects. This is principally motivated by a need
of PDL for a simple syntax of PDL object slicing.

=head1 DESCRIPTION

=head2 Motivation

Currently, PDL objects have to use quite an unwieldy syntax
for the all important slicing and indexing. In perl5 the syntax is

  $n1 = $n-1;   # since we need to stringify
  $y = $x->slice("0:$n1:4");
  $y = $x->slice("0:${\($n-1)}:4"); # even more horrible
  
This should be contrasted with the less cluttered syntax offered
by numerical Python and commercial systems such as Matlab and IDL:

  y = x[0:n-1:4]; 
  
In perl we desire to say:

 $y = $x(0:$n-1,4); # or, depending on the choice of separator
 $y = $x(0:$n-1;4); # see also RFC 169

Note that we need to keep l-value subs in perl6 to avoid related
types of syntactical clumsiness if C<$x()> can invoke a subroutine
(see below).

  $x(0:$n-1:4) *= 2;

should be allowed, as well as the long form

  $x->slice(0:$n-1:4) *= 2;

L and related RFCs propose introducing ranges as part of the
syntax cleanup, this RFC proposes C<()> overloading for
objects.

=head2 Overloading C<()>'s

If classes allowed the definition of a method that is invoked with a
syntax akin to one used with sub refs (but without the need for the
C<&> dereferencing) we could have the cake and eat it.  The parentheses
method notion seems general enough to be useful for other classes.

=head2 Examples:

A possible scenario could be as follows. The class PDL
defines a default method that is invoked when a syntax
like

  $(args)

is used, where C<$Evariable_nameE> is supposed to be an
instance of the class in question (here PDL).

The PDL package would contain the definition of the
method C (a polymorphic method along the lines of RFC 159):

  package PDL;

   

  sub PARENTHESES {
my $this = shift;
$this->slice(@_);
  }

This would allow for the creation of a variety of powerful syntaxes
for different kinds of objects. For example in PDL we might
wish to use C<()> to slice by index value and in a derived class
PDL::World C<()> would slice by physical real-value coordinate.

One could think of this as saying that C<()> is an
operators which can be overloaded.

Note that we still would like to have such a feature even if
Perl 6 provided its own multi-dim array type. It would
give us the freedom to provide an object oriented interface
to these arrays and/or derive classes from it I have
convenient slicing syntax.

=head1 IMPLEMENTATION

Changes to the parser to allow the new syntax.
We are not aware of any other conflicts with existing
or proposed language features.

=head1 SEE ALSO

RFC 159: True Polymorphic Objects

RFC 117: Perl syntax support for ranges

RFC 81: Lazily evaluated list generation functions

RFC 169: Proposed syntax for matrix element access and slicing

RFC 231: Data: Multi-dimensional arrays/hashes and slices

L (http://pdl.sourceforge.net/PDLdocs)

http://pdl.perl.org

Numerical Python:

http://starship.python.net/~da/numtut/

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

[Damien Neil]

On Fri, Sep 29, 2000 at 07:24:38PM -0400, Dan Sugalski wrote:
> >   $foo = """Things like ', ", and \ have no special meaning in here.""";
> 
> Argh! *NO*! That way lies madness, or at least DCL's quoting mania. My 
> record, in a command procedure that wrote other command procedures that 
> submitted command procedures to batch, was 13 quotes in a row. Let's *not* 
> go there, thanks.

Python doesn't allow that degree of quoting.  You can just use triple
quotes as an alternative to single quotes.

Certainly no more insane than qq{}, qq[], qq(), qq##, , qq!!, ...

  - Damien

Re: RFC 288 (v2) First-Class CGI Support

[Russ Allbery]

Bart Lateur <[EMAIL PROTECTED]> writes:

> But anyway: whould this imply that URL- and simple HTML escaping and
> back, will now be available through pack()/unpack()? Just like UUE?
>   ;-)

Adding base64 encoding/decoding and quoted-printable would also be useful.
Either that, or taking uuencode out of pack and putting it plus those
other things into a standard module.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 288 (v2) First-Class CGI Support

[Bart Lateur]

On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian wrote:

>Perl6 make it *easier* to write CGI programs than Perl5.  

That is a strange sentence.

But anyway: whould this imply that URL- and simple HTML escaping and
back, will now be available through pack()/unpack()? Just like UUE?
  ;-)

-- 
Bart.

Re: RFC 355 (v1) Leave $[ alone.

[Bart Lateur]

I should have said: file-scoped lexical.

On Sat, 30 Sep 2000 21:56:43 +0100, Nicholas Clark wrote:

>If it's lexically scoped, would it be for arrays declared in that scope, or
>for arrays accessed in that scope?
>I'm not sure. I think I see potential breakage both ways.

You don't declare Perl arrays. They just exist. Well... except for my'ed
arrays.

My idea is that if anybody sets $[ to 1 in a script, all accesses to
array in that script would use 1 as the index of the very first item:
$ary[1]. But if you pass this array (for example, a reference to it) to
a function in a module that doesn't set $[, it would access the same
first item through index 0: $ary[0] or $ref->[0].

And vice versa (swap "module" and "script").

-- 
Bart.

Re: RFC 355 (v1) Leave $[ alone.

[Glenn Linderman]

Bart Lateur wrote:

> On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:
>
> >But setting $[ = 1 is the mathematically correct method for
> >array addressing and makes it easier for ordinary mortals to do
> >basic tasks with C, array addressing and the like.
>
> I sure don't want the fact that a scripter decides to change $[, make
> used modules fail, because the module's author didn't anticipate that.
>
> Does this not imply that $[ should become lexically scoped?

Or maybe $[ should become a lexically scoped pragma

   use arraybase '1';

--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
   -- Will Rogers


___
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 288 (v1) First-Class CGI Support

[Bart Lateur]

On Sat, 30 Sep 2000 16:39:04 -0400, Adam Turoff wrote:

>I repeat:
>
>> >All of the other features offered by Lincoln Stein's CGI.pm should remain,
>> >but should not be deeply integrated into Perl6.
>  ^^^
>:-)
>
>The proposed 'use cgi;' pragma is concerned with gluing Perl into a cgi
>context.  No more, no less.

Good.

>I'm open to suggestions if the nominclature/distinction is too confusing.

It *is* confusing. It sounded as if you wanted the whole CGI.pm module
to be turned into a pragma.

I like taint. I like %CGI. I like %HTTP. Form processing, basic header
generation; I think that should be it.

-- 
Bart.

Re: RFC 355 (v1) Leave $[ alone.

[Nicholas Clark]

On Sat, Sep 30, 2000 at 09:56:43PM +0100, Nicholas Clark wrote:
> Similarly modules' formatting breaks if you set $/;
  $\;

D'oh

> How many of the punctuation variables would be better with less-than-global
> scope?

 Nicholas Clark

Re: RFC 355 (v1) Leave $[ alone.

[Nicholas Clark]

On Sat, Sep 30, 2000 at 10:34:40PM +0200, Bart Lateur wrote:
> On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:
> 
> >But setting $[ = 1 is the mathematically correct method for
> >array addressing and makes it easier for ordinary mortals to do
> >basic tasks with C, array addressing and the like.

I agree. Make easy things easy, and hard things possible.

> I sure don't want the fact that a scripter decides to change $[, make
> used modules fail, because the module's author didn't anticipate that.

Similarly modules' formatting breaks if you set $/;
How many of the punctuation variables would be better with less-than-global
scope?

> Does this not imply that $[ should become lexically scoped?

Or the function of $[ becomes per-array.
(What would be the syntax to read and set it? pos @array?
it seems to be syntactically legal but undef both as rval and lval)

If it's lexically scoped, would it be for arrays declared in that scope, or
for arrays accessed in that scope?
I'm not sure. I think I see potential breakage both ways.

Nicholas Clark

Re: RFC 288 (v1) First-Class CGI Support

[Adam Turoff]

On Sat, Sep 30, 2000 at 07:30:03PM +0200, Bart Lateur wrote:
> >All of the other features offered by Lincoln Stein's CGI.pm should remain,
> >but should not be deeply integrated into Perl6.
> 
> Eek, no! I don't want no steenking p() functions etc. to generate HTML
> on the fly! That is one feature I never ever use. 

I repeat:

> >All of the other features offered by Lincoln Stein's CGI.pm should remain,
> >but should not be deeply integrated into Perl6.
  ^^^
:-)

The proposed 'use cgi;' pragma is concerned with gluing Perl into a cgi
context.  No more, no less.  That's why %CGI and taint are important
(and the http headers from Nate's RFC), and everything else is more
heavyweight and placed elsewhere (e.g. CGI.pm, CGI::*.pm).

I'm open to suggestions if the nominclature/distinction is too confusing.

Z.

Re: RFC 355 (v1) Leave $[ alone.

[Bart Lateur]

On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:

>But setting $[ = 1 is the mathematically correct method for
>array addressing and makes it easier for ordinary mortals to do
>basic tasks with C, array addressing and the like.

I sure don't want the fact that a scripter decides to change $[, make
used modules fail, because the module's author didn't anticipate that.

Does this not imply that $[ should become lexically scoped?

-- 
Bart.

Re: my and local

[Bart Lateur]

On Thu, 28 Sep 2000 10:18:34 +0100, Tom Christiansen wrote:

>my is fine, but local
>should be changed to something like "temporary" (yes, that
>is supposed to be annoying to type) or "dynamic".

I like "temporary" best, because it says exactly what the purpose is:

temporary $x = $x+2;

This $$x is a temporary value. It's indeed long to type, which might
indeed be a Good Thing, because it discourages using it. I guess that is
what Tom means when he says that it "is supposed to be annoying to
type".

Other words, like "save" etc. say how it works, not what it's for.
That's a Bad Thing.

"dynamic" is a bit vague in meaning.

dynamic $x = $x + 2;

Huh?

-- 
Bart.

RFC 328 (v3) Single quotes don't interpolate \' and \\

[Perl6 RFC Librarian]

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

=head1 TITLE

Single quotes don't interpolate \' and \\

=head1 VERSION

  Maintainer: Nicholas Clark <[EMAIL PROTECTED]>
  Date: 28 Sep 2000
  Last Updated: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 328
  Version: 3
  Status: Frozen

=head1 CHANGES

Reissued on [EMAIL PROTECTED] - I goofed the list.

Clarified the description slightly; by single quoted string I mean '' and q()

Updated discussion section

Frozen not withdrawn (see discussion section)

=head1 DISCUSSION

I'm in two minds as to whether to freeze or retract this RFC

Reaction was strongly polarised; three strongly against and one strongly
for. People valued their ability to use single quotes to easily make
strings containing single quotes. Michael Fowler expresses

Whew.  Disallowing escapes in a single-quote string does not make easy
things easier and hard things possible.

I'm not arguing that we should keep it simply because people are used
to it, but instead we should keep it because it's useful.

My view was that the majority are against the change, but views were from
B perl users [who do you expect as the majority on perl6 lists?
:-)]. The change would penalise existing perl users, but benefit new perl
users (and presumably people teaching perl).

However, I'm wrong on that. Hildo Biersma states

   Now, I have been teaching perl for a number of years, and nobody's ever
   had trouble with understanding how single quotes and the two escapes
   work.  Plenty of people find double-quotes either too powerful or too 
   limited (see the various RFCs), but I think single quotes are fine

However, there was no comment on the secondary issue of how single
quotes treat unrecognised escapes. To me the following seems wrong:

   $  perl -lwe "print q(Quoted \( \\ \) Not \' \t \z)"
   Quoted ( \ ) Not \' \t \z

And from the archives:

   Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? 
 
(Steve Fink, http://www.mail-archive.com/perl6-language@perl.org/msg04008.html)

I conclude

=over 4

=item 1 Removing C<\> escaping of C<\> and the delimiter from '' and q() would make 
perl less useful to the majority

=item 2 How '' and q() deal with C<\> followed by a non-escaped character isn't a 
major concern to perl programmers

=back

hence escaping as is should remain, but it would be possible to change the
unrecognised escape behaviour (say C<\z> maps to C like a "" string)
without causing pain, if this change were deemed sensible. My view is that
(2) should be considered, hence I freeze rather than withdraw the RFC.

=head1 ABSTRACT

Remove all interpolation within single quotes and the C operator, to
make single quotes 100% shell-like. C<\> rather than C<\\> gives a single
backslash; use double quotes or C if you need a single quote in your
string.

=head1 DESCRIPTION

Camel III (page 7) says "Double quotation marks (double quotes) do
I and I while single quotes
suppress interpolation."  Page 60 qualifies this with "except for C<\'> and
C<\\>".

In perl single quotes are used to generate strings. Double quotes also generate
strings.

In C single quotes are used to make character constants. Double quotes are
used to make string constants. Backslash interpretation is performed in
single quotes in C. While multi-character constants are allowed by C, they
are strongly discouraged as they are non-portable, and a character constant
in C is a type distinct from a string constant. Hence double quotes and
single quotes signify different things.

In shell, single quotes are used to make strings. Double quotes also make
strings. Within single quotes backslashes are ordinary characters, and do
not quote anything. As one can't quote a C<'> with a C<\> there is no way to
interpolate a single quote within a single quoted string, but a workaround
such as C<'don'\''t'> relying on the concatenation of C<'don'> C<\'> and
C<'t'> achieves the desired results.

Hence perl's single quoted strings are analogous to shell's single quoted
strings, not C's. However, they're not identical, as perl allows C<\\> to
mean an embedded C<\>, C<\'> to mean an embedded C<'>.

This RFC argues that the exception is confusing and proposes to remove it.
This makes perl more regular in shell terms, and slightly more easy to learn
for the shell programmer.

It also makes perl internally simpler more regular. Currently the behaviour
for C strings is that C<\(> C<\)> and C<\\> map to 1 character,
C<\>I for all other I maps to 2 characters. C differs as
C<\>I maps to 1 character both when I is recognised as a backslash
escapes, B when it is unrecognised. A further irregularity is that
currently single quoted here docs don't interpolate C<\\> or C<\'>. The
consequence of this is that currently

'foo\\bar' eq 'foo\bar'

which sure looks odd.

With this RFC it is proposed that in a single quoted string and the q()
operator C<\> is not special. Hence C<\>I alway

RFC 277 (v3) Method calls SHOULD suffer from ambiguity by default

[Perl6 RFC Librarian]

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

=head1 TITLE

Method calls SHOULD suffer from ambiguity by default

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 24 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 277
  Version: 3
  Status: Frozen

=head1 ABSTRACT

RFC 244 proposes special-casing -> to quote the left operand, and
eliminating the bareword indirect object syntax entirely.

These are both bad ideas, in the author's opinion, and will likely cause
a large number of longtime Perl hackers to run away screaming.

Many people, myself included, view the ability to type:

   $q = new CGI;
   $val = shift->{fullname};

And have Perl DWIM is what makes Perl Perl, and fun. Forcing me to
write:

   $q = new {'CGI'};
   $val = shift()->{fullname};

Because this ambiguity upsets a few people is just plain silly. And
very un-fun.

Tightening this syntax by default makes no sense. Rather, this is
something that can easily be added to C. See B for
details on C and C.

=head1 DESCRIPTION

In Perl 5, there are already plenty of ways in which people can
B disambiguate the above:

   $q = new 'CGI';   # main::new('CGI');
   $q = CGI::->new;  # or 'CGI'->new;

   $val = shift::->{fullname};   # or 'shift'->{fullname}
   $val = shift()->{fullname};   # main::shift()->{fullname}

And if people want this to be enforced, then they can easily C as specified in RFC 278. Or, those who despise indirect
objects may be able to say C using a
mechanism like that in RFC 329.

Perl 6 should be a value add to Perl 5. It should not take away
established, widely-used syntax just because of a little ambiguity. This
is hardly the only syntactic ambiguity in Perl.

=head1 IMPLEMENTATION

Perl 6 should tokenize the above just like Perl 5.

=head1 MIGRATION

None. Why would we want there to be?

=head1 REFERENCES

RFC 28:  Perl should stay Perl.

RFC 278: Additions to 'use strict' to fix syntactic ambiguities

RFC 244: Method calls should not suffer from the action on a distance

RFC 329: C

RFC 356 (v1) Dominant Value Expressions

[Perl6 RFC Librarian]

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

=head1 TITLE

Dominant Value Expressions

=head1 VERSION

  Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
  Date: 24 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 356
  Version: 1
  Status: Developing

=head1 ABSTRACT

An aid to determining if an input  value has an impact on the result of
an expression whole program.  Can also be used for Perl poetry.

=head1 DESCRIPTION

This  is an  optional  feature; to  turn  it on,  "use domination;"  is
suggested.

When use domination  is in scope, two new  functions are available, and
new rules for expression evaluation obtain.  Each of these is described
in a subsection below.

=head2 Domination pragma

The "use domination;" pragma enables the rest of the functionality.  It
should be scoped, affecting the current and nested blocks.

The  "no  domination;"  pragma  would  turn  off  the  effect  of  "use
domination;" for the current and nested blocks.  If a dominant value is
encountered  while "no  domination;" is  in  effect, it  is treated  as
"undef" by all scalar operators.


=head2 Dominant function

The dominant function  takes a scalar argument, which  is considered to
be a weight parameter.  The scalar argument is converted to numeric, if
possible,  with the  resultant  positive weight  parameter producing  a
dominant value with  that given weight.  A scalar  argument that cannot
be automatically converted  to numeric, or that produces  a negative or
zero numeric value produces undef as a result.

=head2 Weight function

The weight function takes a scalar argument.  If the scalar argument is
a dominant value,  it returns its weight as a  positive number.  If the
scalar  argument is  not a  dominant value,  the return  of  the weight
function is zero.

=head2 Expressions involving dominant values

All scalar operations are affected  by the presence of dominant values.
If a scalar operation involves  one or more dominant values, the result
of the operation  is the heaviest (by weight)  dominant value among the
operands.  If  no dominant  values are supplied  to the  operation, the
result of  the operation is  the same as  it would be according  to the
usual definition of the operation.


=head1 COMPATIBILITY

New functionality, no compatibility issues.  The new functionality only
obtains if the "use domination;" pragma is in effect.

=head1 IMPLEMENTATION

The impact  of dominant value  expressions is pervasive,  affecting all
builtin scalar operators  in a minor way.  Any  operators doing item by
item operations  on each scalar  of a list  or hash would  be similarly
affected (various RFCs exist for extending scalar operations to work on
lists of values in "corresponding item" fashion).

=head1 REFERENCES

RFC 263: Add null() keyword and fundamental data type

RFC 355 (v1) Leave $[ alone.

[Perl6 RFC Librarian]

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

=head1 TITLE

Leave $[ alone.

=head1 VERSION

  Maintainer: Fred Heutte <[EMAIL PROTECTED]>
  Date: 29 September 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 355
  Version: 1
  Status: Developing

=head1 ABSTRACT

The array base directive $[ is not just deprecated, it is dissed.
But setting $[ = 1 is the mathematically correct method for
array addressing and makes it easier for ordinary mortals to do
basic tasks with C, array addressing and the like.  On the
other hand, the strong C legacy of starting every integral sequence
with 0 is culturally bound and should not be disturbed.  Therefore,
the correct approach is to make it explicit policy that the status
quo will continue.

=head1 DESCRIPTION

The first Camel states (p. 68),

  The special variable $[ is the current array base, ordinarily 0,
  as we mentioned.  You can change it to 1 if you prefer the
  FORTRAN approach, and then $#whatever will be equal to @whatever.
  Most Perl programmers prefer to leave $[ at 0.

Those like myself who use Perl extensively alongside database programming
find it highly annoying to have two different array bases when dealing
with the same data.  $[ = 1 provides a nice out for us, since we like
to $zipcode = $myaddressline[7] when the Zip Code really is the 7th
element, or $lastname = substr($myrecord, 26, 15) for surnames starting
at the 26th character of a string.

C programmers find this highly annoying since they are attuned since
time immemorial to thinking in binary or vector terms where the count
always starts with 0.  Given both the machine and cultural realities,
it is correct for Perl to have this as the default behavior.

However, $[ always existed for us lesser mortals who prefer the
ordinary usage with C, array subscripts and other
similar work.  This allows us to align our work across the landscape
of work contexts from Perl to, say, SQL.  (For those who are
old-fashioned, from 3GL to 4GL and beyond).

The second Camel takes things much further.  $[ is not only deprecated,
it is dissed in two separate footnotes on p. 49:

  *For historical reasons, the special variable can be used to
   change the array base.  Its use is not recommended, however.
   In fact, this is the last we'll even mention it.  Just don't
   use it.

  +Unless you've diddled the deprecated $[ variable.  Er, *this*
   is the last time we'll mention it ...

This qualifies as a uniquely dogmatic position in a language and culture
otherwise refreshingly free of rigid dogmatism.

For those who prefer the array base to be 0 at all times, the issue
may be one of purity, and the value to those of us who like $[ = 1
to be mere convenience.  But convenience is a virtue too.

If I want to grab the 16th member of an array, I don't want to have to
remember always to subtract one in my head and do something with
$myarray[15].  This feels unnatural, which is a clue that perhaps it
is.  This kind of arithmetic is what machines are good for, and it is
an inefficient use of human attention to do so, at least for some of us.

Furthermore, it is mathematically more valid to use an option base of 1
for many common tasks.  In Joe Celko's book "Data & Databases: Concepts
in Practice" (Morgan Kaufmann, 1999), which I highly recommend in any
event, he has this to say (p. 83):

  An ordinal number represents a position (first, second, third, ...)
  in an ordering ...

  This question of position leads to another debate: Is there such a
  thing as the zeroth ordinal number?  Computer people like to have
  a zeroth position because it is handy in implementing data structures
  with relative positioning.  For example, in the C language and many
  versions of BASIC, arrays start with the element zero.  This allows
  the compiler to locate an array element with the displacement formula:

 + ( * )

  The idea of a zeroth ordinal number is a mild mathematical heresy.
  To be in the zeroth position in a queue is to have arrived in the
  serving line before the first person in line.

In the end, the correct implementation is the one Perl has always had:
make array base 0 the default, for the benefit of programmers and
systems with that perspective, but allow a different option base for
those who prefer it, partly for convenience and productivity reasons,
and partly to retain a state of grace mathematically speaking.

=head1 IMPLEMENTATION

None.  We won't even mind snide asides and patronizing glances if you
just leave $[ alone.

=head1 BUGS

Something changed in the behaviors related to $[ in 5.6, at least in
my usual world (ActiveState).  Specifically, $[ is silently overridden
in the following case:

  $[ = 1 ;

  @files = (<$ARGV[1]>) ;

Then substr("ABCDE", 3, 1) returns "D".  Ouch.

I mentioned this to Gurusamy Sarathy at Usenix in San Diego and he
didn't know about it, but it's replicable, and whatever causes this
should be fixed or isolated so that the effective meaning of $[ =

Re: IDEA: lexically scoped subs anyone

[Simon Cozens]

On Sat, Sep 30, 2000 at 03:48:07PM +0300, Ariel Scolnicov wrote:
> This is done in Lisp, and other functional languages.  Lisp lets you
> declare mutually recursive objects using the (letrec ...)  form.  In
> Scheme, say:
> 
> (letrec ((even? (lambda (x) (if (= x 0) t   (odd?  (- x 1)
>  (odd?  (lambda (x) (if (= x 0) nil (even? (- x 1))
>   (even? 11))
> 
> [No, this is not a good way to write these functions.]
> 
> I'm unsure how to write this Perlishly.

Hm. How about something like this:

{
my sub odd;
my sub even;

sub odd  { return !even(shift)}
sub even { return !odd (shift)}
}

-- 
It took the computational power of three Commodore 64s to fly to the moon.
It takes a 486 to run Windows 95.
Something is wrong here.

RFC 327 (v3) C<\v> for Vertical Tab

[Perl6 RFC Librarian]

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

=head1 TITLE

C<\v> for Vertical Tab

=head1 VERSION

  Maintainer: Nicholas Clark <[EMAIL PROTECTED]>
  Date: 26 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 327
  Version: 3
  Status: Frozen

=head1 CHANGES

Reissued on [EMAIL PROTECTED] - I goofed the list.
So far no comments on it.

Summarised discussion and changed status to frozen

=head1 DISCUSSION

Very little comment was made. Russ Allbery notes

The last time I used a vertical tab intentionally and for some
productive purpose was about 1984.

but states that this isn't an objection to the RFC.

=head1 ABSTRACT

perl5 includes all of C's escapes except C<\v> (vertical tab). Treating
C<\v> the same as C<\a> C<\b> C<\e> C<\f> C<\h> C<\r> C<\t> would remove a
special case.

=head1 DESCRIPTION

man perl says:

   Perl combines (in the author's opinion, anyway) some of
   the best features of C, sed, awk, and sh, so people
   familiar with those languages should have little
   difficulty with it. 

However, lack of C<\v> represents a special case for a C programmer to
learn.  C<\v> isn't used for anything else in double quoted strings, nor is
it used in regular expressions, so it won't require removal of an existing
feature to add it. Currently a C<\v> in a double quoted strings will be
treated as C, with a warning about unknown escape issued if warnings are
in force.

Vertical tab was also omitted from the range of characters considered
whitespace by C<\s> in regular expressions.

This RFC proposes

=over 4

=item 1

C<\v> becomes a recognised escape for a vertical tab in interpolated
contexts (double quoted strings and regular expressions)

=item 2

That vertical tab is moved from the C<\S> (non-whitespace) to C<\s>
(whitespace) class in regular expressions.

=back

=head1 IMPLEMENTATION

Shouldn't be hard. Here are patches for perl 5.7.0

=over 4

=item C<\v>

--- toke.c.orig Fri Sep 15 04:14:57 2000
+++ toke.c  Tue Sep 26 12:54:30 2000
@@ -469,7 +469,7 @@
for (t = s; !isSPACE(*t); t++) ;
e = t;
 }
-while (SPACE_OR_TAB(*e) || *e == '\r' || *e == '\f')
+while (SPACE_OR_TAB(*e) || *e == '\r' || *e == '\f' || *e == '\v')
e++;
 if (*e != '\n' && *e != '\0')
return; /* false alarm */
@@ -1196,7 +1196,7 @@
: UTF;
 const char *leaveit =  /* set of acceptably-backslashed characters */
PL_lex_inpat
-   ? "\\.^$@AGZdDwWsSbBpPXC+*?|()-nrtfeaxcz0123456789[{]} \t\n\r\f\v#"
+   ? "\\.^$@AGZdDwWsSbBpPXC+*?|()-nrtfveaxcz0123456789[{]} \t\n\r\f\v#"
: "";
 
 while (s < send || dorange) {
@@ -1540,6 +1540,9 @@
case 'f':
*d++ = '\f';
break;
+   case 'v':
+   *d++ = '\v';
+   break;
case 't':
*d++ = '\t';
break;
@@ -2700,7 +2703,7 @@
Perl_croak(aTHX_ 
   "\t(Maybe you didn't strip carriage returns after a network transfer?)\n");
 #endif
-case ' ': case '\t': case '\f': case 013:
+case ' ': case '\t': case '\f': case '\v':
 #ifdef MACOS_TRADITIONAL
 case '\312':
 #endif
--- t/op/pat.t.orig Tue Aug 29 13:54:13 2000
+++ t/op/pat.t  Tue Sep 26 12:56:36 2000
@@ -469,27 +469,27 @@
 print "ok $test\n";
 $test++;
 
-print "not " unless qr/\b\v$/i eq '(?i-xsm:\bv$)';
+print "not " unless qr/\b\y$/i eq '(?i-xsm:\by$)';
 print "ok $test\n";
 $test++;
 
-print "not " unless qr/\b\v$/s eq '(?s-xim:\bv$)';
+print "not " unless qr/\b\y$/s eq '(?s-xim:\by$)';
 print "ok $test\n";
 $test++;
 
-print "not " unless qr/\b\v$/m eq '(?m-xis:\bv$)';
+print "not " unless qr/\b\y$/m eq '(?m-xis:\by$)';
 print "ok $test\n";
 $test++;
 
-print "not " unless qr/\b\v$/x eq '(?x-ism:\bv$)';
+print "not " unless qr/\b\y$/x eq '(?x-ism:\by$)';
 print "ok $test\n";
 $test++;
 
-print "not " unless qr/\b\v$/xism eq '(?msix:\bv$)';
+print "not " unless qr/\b\y$/xism eq '(?msix:\by$)';
 print "ok $test\n";
 $test++;
 
-print "not " unless qr/\b\v$/ eq '(?-xism:\bv$)';
+print "not " unless qr/\b\y$/ eq '(?-xism:\by$)';
 print "ok $test\n";
 $test++;
 

=item C<\S> to C<\s>

--- handy.h.origThu Sep 14 15:44:20 2000
+++ handy.h Tue Sep 26 13:04:30 2000
@@ -295,8 +295,9 @@
 #define isIDFIRST(c)   (isALPHA(c) || (c) == '_')
 #define isALPHA(c) (isUPPER(c) || isLOWER(c))
 #define isSPACE(c) \
-   ((c) == ' ' || (c) == '\t' || (c) == '\n' || (c) =='\r' || (c) == '\f')
-#define isPSXSPC(c)(isSPACE(c) || (c) == '\v')
+   ((c) == ' ' || (c) == '\t' || (c) == '\n' || (c) =='\r' || (c) == '\f' \
+|| (c) == '\v')
+#define isPSXSPC(c)

RFC 320 (v2) Allow grouping of -X file tests and add C builtin

[Perl6 RFC Librarian]

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

=head1 TITLE

Allow grouping of -X file tests and add C builtin

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 25 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 320
  Version: 2
  Status: Frozen

=head1 ABSTRACT

Currently, file tests cannot be grouped, resulting in very long
expressions when one wants to check to make sure some thing is a
readable, writeable, executable directory:

   if ( -d $file && -r $file && -w $file && -x $file ) { ... }

It would be really nice if these could be grouped instead:

   if ( -drwx $file ) { ... }

Notice how much easier this is to read and write.

=head1 NOTES ON FREEZE

Everyone liked it (I even heard Tom say so :), the only concern raised
was that it makes the direct negation of subs impossible because of the
way C<-[a-zA-Z]+> would have to be tokenized. See the MIGRATION and also
REFERENCES sections for details on this.

=head1 DESCRIPTION

=head2 File Test Grouping

See above. Multiple file tests, when grouped, should be ANDed together.
This RFC does not propose a way to OR them, since usage like this:

   if ( -d $file || -r $file || -w $file || -x $file ) { ... }

Is highly uncommon, to say the least.

Notice this has the nice side effect of eliminating the need for C<_> in
many cases, since this:

   if ( -d $file && -r _ && -w _ && -x _ ) { ... }

Can simply be written as a single grouped file test, as shown above. If
you need to check for more complex logic, you still have to do that
separately:

   if ( -drwx $file and ! -h $file )  { ... }

This is the simplest and also probably the clearest way to implement
this.

=head2 New C Builtin

This RFC also proposes a new C builtin that is actually what
is used for these tests. The C<-[a-zA-Z]+> form is simply a shortcut to
this builtin, just like <> is a shortcut to C. So:

   if ( -rwdx $file ) { ... }

Is really just a shortcut to the C builtin:

   if ( filetest $file, 'rwdx' ) { ... }

Either form could be used, depending on the user's preferences (just
like C). Note that this C builtin is designed to
supposedly make the implementation of this easier, but if it doesn't,
then it's unnecessary and should not be added.

=head1 IMPLEMENTATION

This would involve making C<-[a-zA-Z]+> a special token in all contexts,
serving as a shortcut for the C builtin. This means that you
will no longer be able to directly negate subroutine calls; see below.

=head1 MIGRATION

There is a subtle trap if you are negating subroutines:

   $result = -drwx $file;

And expect this to be parsed like this:

   $result = - &drwx($file);

However, usage such as this is not common, since negating subs only
makes sense in a very few cases. In Perl 6, instead of writing:

   $num = -exp($foo);

You would have to write:

   $num = - exp($foo);

The author personally feels this is not too much of a burden for the
benefit of grouped filetests. Note that this is already required for
people that use subs named r, w, d, or any other filetest character.

To fix this issue, the p52p6 translator simply has to look for
C<-([a-zA-Z]{2,})> and replace it with C<- $1>, since injecting a
single space will break up the token. See the below links for more
details on the discussions of this.

=head1 REFERENCES

http://www.mail-archive.com/perl6-language%40perl.org/msg04649.html

http://www.mail-archive.com/perl6-language%40perl.org/msg04658.html

Re: RFC 320 (v1) Allow grouping of -X file tests and add C builtin

[Bart Lateur]

On Tue, 26 Sep 2000 11:13:30 -0700, Nathan Wiger wrote:

>   -{rwx};   # negation of a hashref

That's a weird hashref. Odd number of arguments, anyone?

If rwx is supposed to be a sub, we could say that this is an exception,
just like $hash{bareword} is an exception. So, if you want the sub, use
parens:

-{rwx()}

Need I still say that this one is my favourite?   :-)

-- 
Bart.

RFC 292 (v2) Extensions to the perl debugger

[Perl6 RFC Librarian]

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

=head1 TITLE

Extensions to the perl debugger

=head1 VERSION

  Maintainer: David Storrs <[EMAIL PROTECTED]>
  Date: 25 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 292
  Version: 2
  Status: Frozen

=head1 ABSTRACT

The perl debugger is good, but there are several features it lacks (or at
least, that it lacks convenient, single-key commands for) that would be
extremely useful.  

=head1 DESCRIPTION

The following features appear in many modern IDEs, but not in the perl
debugger.   It is generally possible to duplicate this functionality by
writing an appropriate command string, but there should be easy ways to do
these things.

=over 4

=item 1

The ability to easily retrieve and edit your N most recent commands to the
debugger (much like a bash_history).

=item 2

A better default pager.  The default pager should assume a 24x80 term
window and use an absolute minimal number of control characters (e.g., use
spaces in preference to horizontal tab) to format things.  This is not
particularly fast or efficient but people who want that can reset it to
something else, and using an absolute minimal one will make life easier
for people (like me!) who use limited telnet clients to get to the box
which runs Perl for them.

=item 3

The ability to look at an object and, with just one or two keystrokes,
list 

=over 4

=item (A) 

the names of all its ancestors, 

=item (B) 

the names of all its descendants, 

=item (C) 

the names of everything in its inheritance hierarchy (i.e., all of its
ancestors, itself, all of its descendants).  

=back

Note that it is possible (generally by error) to construct cyclic
inheritance graphs; the debugger would need to detect this and cope with
it.

=item 4

The ability to provide a function name (preferably just the first unique
section of its name) and 

=over 4

=item (A) 

jump to where that function is defined, 

=item (B) 

list the names of all functions that call that function, 

=item (C) 

show all lines in the current package or file which call that function, 

=item (D) 

show all lines in the program (including linked modules) which call that
function, 

=item (E) 

list all user-defined functions that that function calls
=back

=item 5

The debugger should be better at storing state.  I should be able to do
this:

 $foo = 2
 p $foo

and have it print "2"

=item 6

It should be possible to enter multiline commands into the debugger
without having to backslash each new line.  This could be done by using
prefix and postfix command strings as markers (perhaps ML: and :LM) to
show where the multiline begins and ends, or by simply making the engine
smarter (difficult, I know).

=item 7

The O command should be extended to allow user modification of what is
printed when the debugger must display an undef value (e.g., O
undef_str=**UNDEF**).  If the default value is "", then we will maintain
backwards compatibility.

=cut

=head1 IMPLEMENTATION

1) The history functionality only requires a buffer in which to store the
most recent N strings.

2) The pager should be relatively straightforward; it is intended to be
extremely minimalist, after all.

3) Showing the ancestors of an object is easy (just dump @ISA), but
showing the descendants might be harder, since it requires scanning the
@ISAs of all known objects (unless there is some magic from -internals?).
The best might be to construct a giant @ISA graph of all classes at
runtime.  Note the possibility of circular inheritance graphs, and the
fact that @ISA can be modified at runtime, which would require modifying
the graph.

4) The function tracking will be difficult, and will require much help
from the -internals people.

5) I'm not sure how to handle this one.  I'm tempted to say that the
debugger should simply store its state in the program's stash, but that
might cause problems.  It will mean that the debugger cannot simply "eval"
all commands and then forget them.

6) See RFC 184 for discussion on this.

7) This should be straightforward, I hope.

=head1 REFERENCES

perldebug man page

RFC 184: Perl should support an interactive mode.

RFC 279 (v2) my() syntax extensions and attribute declarations

[Perl6 RFC Librarian]

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

=head1 TITLE

my() syntax extensions and attribute declarations

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 24 Sep 2000
  Last Modified: 30 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 279
  Version: 2
  Status: Frozen

=head1 ABSTRACT

This RFC fleshes out variable declarations with C, and also proposes
a way to assign attributes without the need for a C anywhere. Much
of this stuff has been hinted at, so this is just a formalization.

Please note this entire document is B, intended for those that
need this type of control. Perl is not a B&D language (by default, at
least :).

=head1 DESCRIPTION

Camel-3 shows some interesting hints of what's been proposed for C
declarations:

   my type $var :attr1 :attr2 = $value;

And we all know that you can use C to declare a group of variables:

   my($x, $y, $z);

Here's the issues:

   1. How do the two jive together?
  
   2. Should it be possible to assign attributes to individual elements
  of hashes/arrays? (yes)

=head2 Cohesive C syntax

This RFC proposes that you be able to group multiple variables of the
same type within parens:

   my int ($x, $y, $z);
   my int ($x :64bit, $y :32bit, $z);

It seems most logical that:

   1. The type will be the same across variables; this is common
  usage in other languages because it makes sense.

   2. The attributes will be different for different variables.

As such, multiple attributes can be assigned and grouped flexibly:

   my int ($x, $y, $z) :64bit;   # all are 64-bit
   my int ($x, $y, $z :unsigned) :64bit; # plus $z is unsigned

Note that multiple types cannot be specified on the same line. To
declare variables of multiple types, you must use separate statements:

   my int ($x, $y, $z) :64bit;
   my string ($firstname, $lastname :long);

This is consistent with other languages and also makes parsing
realistic.

=head2 Assigning attributes to individual elements of hashes/arrays

This is potentially very useful. ":laccess", ":raccess", ":public",
":private", and others spring to mind as potential candidates for this.
This RFC proposes that in addition to attributes being assigned to a
whole entity on declaration:

   my int @a :64bit;   # makes each element a 64-bit int
   my string %h :long; # each key/val is long string

They can also be declared on individual elements, without the need for
C or C:

   $a[0] :32bit = get_val;   # 32-bit
   $r->{name} :private = "Nate"; # privatize single value
   $s->{VAL} :laccess('data') = "";  # lvalue autoaccessor

Assigning attributes to individual elements has the advantage over
keywords of allowing them to be grouped:

   $self->{name} :public :roaccess('getname') = "Nathan Wiger";

However, a problem arises in how to assign types to singular elements,
since this requires a C:

   my int $a[0] :64bit; # just makes that single element
# a lexically-scoped 64-bit int?

   my string $h{name} = ""; # cast $h{name} to string, rescope %h?

Currently, lexical scope has no meaning for individual elements of
hashes and arrays. However, assigning attributes and even types to
individual elements seems useful. There's two ways around this that I
see:

   1. On my'ing of an individual hash/array element, the
  entire hash/array is rescoped to the nearest block.

   2. Only the individual element is rescoped, similar
  to what happens when you do this:

  my $x = 5;
  {
 my $x = 10;
  }

Either of these solutions is acceptable, and they both have their pluses
and minuses. The second one seems more consistent, but is potentially
extremely difficult to implement.

=head1 IMPLEMENTATION

Hold on.

=head1 MIGRATION

None. This introduces a more flexible syntax but does not break old
ones.

=head1 REFERENCES

RFC 337: Common attribute system to allow user-defined, extensible attributes

RFC 319: Transparently integrate C

Camel for the C syntax.

C man page for details on attributes.

RFC 278 (v2) Additions to 'use strict' to fix syntactic ambiguities

[Perl6 RFC Librarian]

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

=head1 TITLE

Additions to 'use strict' to fix syntactic ambiguities

=head1 VERSION

   Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
   Date: 24 Sep 2000
   Last Modified: 30 Sep 2000
   Mailing List: [EMAIL PROTECTED]
   Number: 278
   Version: 2
   Status: Frozen

=head1 ABSTRACT

Several RFCs and many people have voiced concerns with different parts
of Perl's syntax. Most take issue with syntactic ambiguities and the
inability to easily tokenize Perl.

This RFC shows how these all boil down to a three central issues, and
how they can be solved with some simple additions to C. By
default, Perl should remain as flexible as possible. By adding these
flags to C, those who desire them can have all the benefits
of a stricter syntax, without hurting those that like these features.

=head1 DESCRIPTION

=head2 The Problems

=head3 Indirect Objects

RFC 244 proposes eliminating the bareword indirect object syntax because
this:

   print STDERR @stuff;

Can be parsed as either of these:

   STDERR->print(@stuff);
   print(STDERR(@stuff));

Depending on your usage of C other places in your program.
However, many of us like writing:

   $q = new CGI;

Quite a bit, and consider this DWIMish.

=head3 Barewords vs. Functions

RFC 244 and others mention several problems with barewords such as:

   Class->stuff(@args);   # Class()->stuff or 'Class'->stuff ?

Again, the fact that Perl can figure this out correctly is quite
DWIMish, and this functionality should not be removed by default.

=head3 Special Cases

Many special cases abound, such as the bare C mentioned in RFC 135.
Again, this is stuff that makes Perl fun, and should not be taken out
of the language.

=head2 The Solutions

At first, these may not seem related. However, they very much are, and
in fact all boil down to only three issues which can be resolved with
additions to C.

=head3 Function Parens - C

This imposes a very simple restriction: barewords are not allowed. They
must be either quoted or specified with parens to indicate they are
functions. Note this solves the C<%SIG> problem from Camel:

   use strict 'words';
   $SIG{PIPE} = Plumber;# syntax error
   $SIG{PIPE} = "Plumber";  # use main::Plumber
   $SIG{PIPE} = Plumber();  # call Plumber()

In addition, this also forces users to disambiguate certain functions:

   use strict 'words';

   name->stuff(@args);  # syntax error
   'name'->stuff(@args);# 'name'->stuff
   name::->stuff(@args);# ok too, same thing
   name()->stuff(@args);# name()->stuff

   $result = value + 42;# syntax error
   $result = value() + 42;  # value() + 42
   $result = value(  + 42); # value(42)
   $result = 'value' + 42;  # ok, if you think this is Java...

It's simple: barewords are not allowed.

=head3 Indirect Objects - C

Another major problem is ambiguous indirect objects. Under C, the indirect object I be surrounded by braces:

   use strict 'objects';
   no strict 'words';

   print STDERR @stuff; # print(STDERR(@stuff))
   print 'STDERR' @stuff;   # syntax error
   print {'STDERR'} @stuff; # 'STDERR'->print(@stuff)

   print $fh @junk; # syntax error
   print {$fh} @junk;   # $fh->print(@junk)

This eliminates the possibility of ambiguity with indirect objects. When
combined with C, code becomes even less ambiguous:

   use strict qw(words objects);

   $q = new 'CGI';  # syntax error
   $q = new {'CGI'};# 'CGI'->new
   $q = new ('CGI');# new('CGI')
   $q = new (CGI());# new(CGI())

   $q = new 'CGI' @args;# syntax error
   $q = new {'CGI'} (@args);# 'CGI'->new(@args)
   $q = new (CGI (@args));  # new(CGI(@args))

=head3 Syntactic Problems - C

There are many other "little ambiguities" throughout Perl. Adding
C would remove these and require the user to specify
them explicitly. In this category fits the bare C problem mentioned
in RFC 135, as well as several common "bugs" (mistakes).

Under this rule, the following would apply:

   1. No more // by itself, you must use m//

   2. Trailing conditionals would require parens

   3. Precedence other than for basic math and boolean ops would
  not apply

This is designed to force you to write clean, unambiguous code that
borders on being non-Perlish:

   use strict 'syntax';
   next if /^#/ || /^$/;   # syntax error
   next if m/^#/ || m/^$/; # syntax error
   next if (m/^#/ || m/^$/);   # ok

   use strict 'syntax';
   $data = $a + $b / $c - $d || $default or die;  # no way
   $data = ($a + $b / $c - $d) || $default or die;# nope
   ($data = ($a + $b / $c - $d) || $default) or die;  # ok

Basically, the idea is to impose a truly unambiguous style so that
people don't get carried away with precedence and special cases.

=head2 Combining all these together

Let's look at an example of how all these would be combined. With the
additions to C proposed in this RFC, the existing Perl 5
code snippet:

   $

Re: RFC 288 (v1) First-Class CGI Support

[Bart Lateur]

On 25 Sep 2000 06:01:57 -, Perl6 RFC Librarian wrote:

>All of the other features offered by Lincoln Stein's CGI.pm should remain,
>but should not be deeply integrated into Perl6.

No cookie support, please. Cookies should remain in a module.

-- 
Bart.

Re: RFC 288 (v1) First-Class CGI Support

[Bart Lateur]

On 25 Sep 2000 06:01:57 -, Perl6 RFC Librarian wrote:

>Perl6 should be *easier* to write CGI programs than Perl5.

>To make CGI programming easier, this option/pragma should:
...
>Parse the CGI context, returning CGI variables into %CGI

I like that one.

>Not take up gobs of memory

That too.

>All of the other features offered by Lincoln Stein's CGI.pm should remain,
>but should not be deeply integrated into Perl6.

Eek, no! I don't want no steenking p() functions etc. to generate HTML
on the fly! That is one feature I never ever use. It also conflicts with
the remark about memory usage. Plus, do we need a new Perl upgrade every
time a new HTML tag comes out? I think not. Keep HTML tags out of Perl.
If people want it, they can use an easiliy updateble module.

CGI::Minimal would be more like it.

-- 
Bart.

Re: RFC 229 (v2) Variable interpolation on demand.

[Glenn Linderman]

"David L. Nicol" wrote:

> >
> > This is a new feature, so name conflict is the only issue.
> >
> > Thisseems   compatiblewith   otherextensionsto   string
> > interpolation... whatever  extensions get implemented  should work here
> > too.
>
> it's not a new feature.  It's amazing the subtle control you
> can get with s/(\$...)/$1/ge depending on your 

Hmm.  I'll have to think about your expression some more, it is not immediately
obvious how it achieves the goal of the RFC, but I differ with your semantics
regarding the word feature.  The RFC describes a new feature.  The functionality is
not new, but the feature makes the functionality more accessible in simpler ways.

> Wrapping such a critter up in a tied scalar sounds like a total
> piece of cake

Perhaps. If you do the wrapping, please forward.  I have no experience yet with tie.

--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
   -- Will Rogers



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

Re: Why -> cannot autoquote the LHS (was Re: RFC 244 (v1) Method calls should not suffer...)

[Glenn Linderman]

Nathan Wiger wrote:

> (And if the RFC is proposing autoquoting only barewords, then I think
> that's _really_ inconsistent and should not be done.)

Isn't autoquoting only barewords precisely the type of autoquoting that => does?
So there is a precedent.  I've been assuming all along that that is exactly what
the RFC is proposing.

--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
   -- Will Rogers



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

Re: RFC 229 (v2) Variable interpolation on demand.

[Glenn Linderman]

"John L. Allen" wrote:

> On 29 Sep 2000, Perl6 RFC Librarian wrote:
>
> > Make Perl's powerful string interpolation facilities are available to
> > variables, in addition to literals.
> >
> > =head1 DESCRIPTION
> >
> > Given:
> >
> > $foo = 'def';
> > $bar = 'ghi';
> > $x = "abc$foo$bar";
> > $y = 'abc$foo$bar';
> >
> > There is no  way to turn obtain the  value of $x from the  value of $y.
> > In other  words, while  $foo and $bar  were interpolated into  $x, they
> > were not interpolated into $y.  It would be nice to get Success! from:
>
> Um, what would your proposal gain you over
>
>   $z = eval "qq{$y}";
>
> other than conciseness, elegance and speed (which may be quite enough!) ?

Correctness.  Your solution fails if $y contains '}' characters.  This was
noted in the next version, which I froze.  The cost of prechecking to choose
an appropriate delimiter, which if $y contains at least one instance of all
legal characters may not even exist, could be enormous (compared to the cost
of the operation) and unsuccessful.

That said, your solution works if the set of possible content of $y is
sufficiently constrained.

--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
   -- Will Rogers


___
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 333 (v1) Add C and C funtions to coredistribution

[Nathan Wiger]

Alan Gutierrez wrote:
> 
> This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers:
> 
> The field value may be preceded by any amount of LWS, though a single SP
> is preferred. Header fields can be extended over multiple lines by
> preceding each extra line with at least one SP or HT.

Yes, similar requirements are in RFC 822, which talks about SMTP
headers. The header and unheader function would be able to support them.

Let's take up further concerns by addressing the Text::Header module
itself; I'll check out your other emails and see what can be integrated.
Feel free to email me offline as well.

Thanks,
Nate

Re: IDEA: lexically scoped subs anyone

[Ariel Scolnicov]

Simon Cozens <[EMAIL PROTECTED]> writes:

> On Fri, Sep 29, 2000 at 04:13:46PM +0100, Piers Cawley wrote:
> > Did anyone suggest the following yet?
> > package Foo;
> > my sub _helper_function { ... }
> 
> Todo:
> lexically scoped functions: my sub foo { ... }
> the basic concept is easy and sound,
> the difficulties begin with self-referential
> and mutually referential lexical subs: how to
> declare the subs?

This is done in Lisp, and other functional languages.  Lisp lets you
declare mutually recursive objects using the (letrec ...)  form.  In
Scheme, say:

(letrec ((even? (lambda (x) (if (= x 0) t   (odd?  (- x 1)
 (odd?  (lambda (x) (if (= x 0) nil (even? (- x 1))
  (even? 11))

[No, this is not a good way to write these functions.]

I'm unsure how to write this Perlishly.

-- 
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd.  |Tel: +972-2-5713025 (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 327 (v2) C<\v> for Vertical Tab

[Nicholas Clark]

On Fri, Sep 29, 2000 at 05:29:26PM -0700, David Olbersen wrote:
> -> -Original Message-
> -> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> -> Just out of curiosity, and I'm not objecting to this RFC, has anyone
> -> reading this mailing list actually intentionally used a vertical tab for
> -> something related to its supposed purpose in the past ten years?
> 
> I don't even know what a vertical tab is, it doesn't sound like anything
> very useful.

I've never used one, and I doubt I will (apart from including it in
"\r\t\f\v \n" in any whitespace in parsing code I write in C)

My reasoning was that one of the criticisms usually levelled against perl by
its detractors was that it is confusing because there are so many special
cases and irregularities. In my opinion "Double quoted strings have all the C
backslash constructions (except \v)" is an irregularity, not a feature. Every
non-useful irregularity removed aids advocacy, teaching and documenting,
without hindering programming.

Nicholas Clark

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

[Bart Lateur]

On Thu, 28 Sep 2000 10:16:43 +0100, Tom Christiansen wrote:

>Try thinking of it this way: it's only a bareword if 
>it would make use strict whinge at you.

So every bareword would be recognized as a sub. That, is nice. For
starters, Perl parsers can more easily recognize a sub name, without a
need of having loaded every use'd module.

And, hasn't anybody else ever been wondering about things like:

tie %hash, 'Any_DBMFile', $filename, O_CREAT | O_RDWR;

and have it bark back at you that:

O_SVWST isn't numeric

? It turns out that Fcntl wasn't loaded, and the flags were treated as
literal strings. Ugh.


Would that not make "strict subs" always in effect?


>Visit our website at http://www.ubswarburg.com
>...

And this appears in every single one of TomC's messages. Tom, can you at
least put a "-- " line after your message, so that this may
automatically bne recognized as a footer? I think some people would
appreciate that. We could even filter it out...  ;-)

-- 
Bart.