Re: RFC 34 (v1) Angle brackets should not be used for fi

[Nathan Torkington]

Someone wrote:
> > How about "Deprecate use of file globbing with angle brackets.  Emit a
> > warning when this behaviour is used."

I want to RFC this, but I feel like starting a new language with
deprecated behaviours is a Bad Move.  The whole damn point is so we
can get away from all the deprecated crud in perl5.

Nat

Re: RFC 34 (v1) Angle brackets should not be used for fi

[Glenn Linderman]

[EMAIL PROTECTED] wrote:

> On Fri, Aug 04, 2000 at 10:13:59PM -, Perl6 RFC Librarian wrote:
> >=head1 IMPLEMENTATION
> >
> >Remove the file-globbing behavior of the angle brackets.
>
> How about "Deprecate use of file globbing with angle brackets.  Emit a
> warning when this behaviour is used."

That sounds friendlier (more compatible, apple pie, etc.) on the
surface,
but would still result in the annoying behaviors (choice of <> function
by
form of internal parameter) that the RFC is trying to get rid of.

--
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 34 (v1) Angle brackets should not be used for fi

[skud]

On Fri, Aug 04, 2000 at 10:13:59PM -, Perl6 RFC Librarian wrote:
>=head1 IMPLEMENTATION
>
>Remove the file-globbing behavior of the angle brackets.

How about "Deprecate use of file globbing with angle brackets.  Emit a
warning when this behaviour is used."

K.


-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 10 (v2) Filehandles should use C<*> as a type pr

[skud]

On Fri, Aug 04, 2000 at 03:04:08PM -0700, Nathan Wiger wrote:
>I think this is a good candidate for recording why we decided not to do
>something.
>
>Did we even reach consensus on how to do this? Put a Status: header in
>VERSION?
>
>For recording purposes, maybe once the Status: line is added we should
>add an additional section. Maybe STATUS, JUSTIFICATION, POSTMORTEM, or
>something else, that can just have a one-paragraph explanation, like:
>
>=head1 STATUS
>
>Consensus has been reached that filehandles will be represented as
>scalars or objects in scalars (C<$fh>) everywhere. Therefore, there is
>no need to make a new type out of them.  This RFC has been withdrawn.

I like this solution a lot. Gnat, can we implement it, since there is
now an active need for it?

I'd also like to congratulate and thank Peter for so gracefully
acknowledging that better and more widely accepted alternatives were 
available.  This is a fantastic example of the RFC process at its best.

Thanks to all involved.

K.


-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 22 (v1) Builtin switch statement

[skud]

On Fri, Aug 04, 2000 at 05:16:15PM -0400, John Porter wrote:
>Glenn Linderman wrote:
>> 
>> This is not to detract from the ideas of higher order functions or curried
>> whatever, but I
>> don't think those are or should be necessary to a powerful switch statement.
>
>I vote thus: to have RFC 22 rejected (29 rules?!), and RFC 23 accepted,
>with appropriate ramifications/extensions, so that ppl can write
>switch-like constructs however they want.

Vote all you like :P

I'm not going to be "rejecting" any language RFCs unless there is an
overwhelming, near-unanimous movement against them.  Even then, I'm more
likely to ask the author to redraft or withdraw their RFC, at their own
discretion.

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

sublist request: perl6-language-io

[skud]

WORKING GROUP:  perl6-language-io
CHAIR:  Nathan Wiger <[EMAIL PROTECTED]>
MISSION:Draft and discuss I/O related RFCs, including (but not
limited to) RFCs 14 and 30.
DEADLINE:   3 weeks, extensible on request (end August 26)
DESCRIPTION:Submit I/O related RFCs to the Perl 6 librarian as they
are developed.


-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 22 (v1) Builtin switch statement

[Glenn Linderman]

Ken Fox wrote:

> Then write the switch as:
>
>   switch ( __ ) {
> case $v == 1: { ... }
> case $v == 2: { ... }
> case $v == @foo { ... }
>   }
>
> It might take you a little while to get your head around the __
> symbol. I'm not sure it's useful to think of it as a variable;
> poison is more like it. Or a Midas touch. Any expression it
> touches turns into a subroutine. All the case statement does is
> call the subroutine.
>
> - Ken

I haven't gotten my head around anything curried, except Indian food
but it appears to be powerful, and a kind of like generic programming on
the fly.  I'd like to learn more: if someone would give a tutorial
reference that would be helpful.

However, in this particular example, it is clear that you have attempted
to resolve my negative example by using an extremely powerful construct
to take Damian factored switch statement, and effectively unfactor it:
Remove the "switch ( __ )" part, and you have exactly the syntax and
functionality I suggested in my first reponse to his post.

I don't attempt to claim that Damian's proposal isn't clever, isn't
powerful, or isn't cool.  Just that it doesn't DWIM, is hard to learn
and understand because of its large table of operations, and gets most
of its power from that table, together with this currying thing.

I'd like to see the useful, non-trivial operations in his table
available using simple syntax outside the switch statement; they could
then be expressed in the switch statement conditions, or in if
conditions, or while conditions, or any other useful place, rather than
having the programmer be forced to contrive a switch statement to avoid
writing the non-trivial operation syntax.

Further, rather than have a powerful switch statement embodying all
these operations, and have to use a powerful curry operation to reduce
it to a simple case, wouldn't it be nicer to have a simple, easy to
learn switch statement, and have more powerful operators and this curry
thing when needed to achieve the complexity embodied in this RFC?  Make
easy things easy, and hard things possible.

I'll probably counter-propose as Damian suggested, as it does, indeed,
look like we are quite far apart on this issue, and it would take more
than a few postings to resolve.

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

sublist request: perl6-language-unlink

[skud]

WORKING GROUP:  perl6-language-unlink
CHAIR:  Nathan Wiger <[EMAIL PROTECTED]>
MISSION:Discuss and redraft RFC 29. Draft and discuss an
opposing RFC *or* rename RFC 29 to "ways of dealing with
unlink()" and discuss various viewpoints.
DEADLINE:   1 week (end August 12th)
DESCRIPTION:Submit redrafted RFC 29 to perl6-language.  Optionally 
submit opposing RFC.



-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

sublist request: perl6-langauge-flow

[skud]

WORKING GROUP: perl6-language- flow
CHAIR: uri guttman <[EMAIL PROTECTED]>
MISSION:   Draft, discuss, and revise RFCs relating to flow control
   in Perl 6, eg switch/case, looping, etc.  Suggest/request
   other flowcontrol-related lists if appropriate
DEADLINE:  3 weeks, extensible on request (end 26th August?)
DESCRIPTION:   Submit flowcontrol-related RFCs to the Perl 6 librarian
   as they are developed.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 27 (v1) Coroutines for Perl

[Uri Guttman]

> "s" == skud  <[EMAIL PROTECTED]> writes:

  s> There is currently no such thing as a sub-sublist.  perl6-language-flow
  s> would not independently spawn perl6-language-flow-switch etc. Instead,
  s> the chair of -flow could contact me and suggest a new sublist such as
  s> perl6-language-switch, which would get its own chair and charter
  s> independently of -flow.

ok with me. it was not clear how the lists were organized. in any case
the rfc will cover many issues and proposals.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 16 (v1) Keep default Perl free of constraints su

[skud]

Please take this discussion to the -strict mailing list.

K.


-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 27 (v1) Coroutines for Perl

[skud]

On Fri, Aug 04, 2000 at 02:34:07PM -0400, Uri Guttman wrote:
>
>that is a major reason why i want to move all of those rfc's under the
>flow one so we can properly address that low level design and language
>changes to support them all. i should have my draft rfc done later
>tonight and will post it. it has some missing sections you can fill in
>like on co-routines and completions.

uri, I fear you may be suffering from a bit of confusion wrt the current
state of sublists.

There is currently no such thing as a sub-sublist.  perl6-language-flow
would not independently spawn perl6-language-flow-switch etc. Instead,
the chair of -flow could contact me and suggest a new sublist such as
perl6-language-switch, which would get its own chair and charter
independently of -flow.

I admit this isn't really very different in practical terms, but at
least it means that sublists have some consistentcy in their charters
and timelines, and that they all report back to the same place
(-language).

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 22 (v1) Builtin switch statement

[Ken Fox]

Glenn Linderman wrote:
> For instance,
> 
>   if ( $v == @foo )
> 
> is clearly testing the size of foo against the value of $v.  But
> 
>   switch ( $v ) {
> case 1: { ... }
> case 2: { ... }
> case @foo { ... }
>   }
> 
> does not!

Then write the switch as:

  switch ( __ ) {
case $v == 1: { ... }
case $v == 2: { ... }
case $v == @foo { ... }
  }

It might take you a little while to get your head around the __
symbol. I'm not sure it's useful to think of it as a variable;
poison is more like it. Or a Midas touch. Any expression it
touches turns into a subroutine. All the case statement does is
call the subroutine.

- Ken

ConwayPerl (was Re: RFC 22 (v1) Builtin switch statement)

[Jeremy Howard]

Damian Conway said:
> switch ( $x < __ ) {
>
> case 0 { print "negative" }
> case 1 { print "unity" }
> case any(2..9) { print "small" }
> case @list { print "in range" }
> }
>
Now _that's_ the coolest thing I've seen since, well, umm, this morning,
when I read the original RFC.

Damian, a lot of your RFCs integrate together to provide some pretty
powerful capabilities (what a coincidence ;-) To mere mortals like myself,
some of these are non-obvious. To beings of a higher plane some are
non-obvious too, because some of the RFCs haven't been written yet...

Is there a chance at some point you could give a high-level overview of
ConwayPerl? In particular, how reduce, semi-finite lists, higher-order
functions, generalised iterators, lazy evaluation of argument lists, and
superpositions fit together? Maybe a little snippet of code in ConwayPerl
which defines and then does some interesting operations on and reductions of
columns of a sparse matrix/tensor, for instance?...

I know you've got nothing else to do right now ;-)

RFC 37 (v1) Positional Return Lists Considered Harmf

[Perl6 RFC Librarian]

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

=head1 TITLE

Positional Return Lists Considered Harmful

=head1 VERSION

  Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
  Date: 04 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 37

=head1 ABSTRACT

Perl has traditionally returned from various functions long (>2) lists
of values.  Some traditions are simply bad.

=head1 DESCRIPTION

Functions like stat() and get*ent() return long lists of mysterious
values.  The implementation is assumedly easy: just push some values
out of C structs into the Perl return stack.

Wrong.  And once more, wrong.

Firstly, who can remember which one of the stat() return values was
the atime is or which is the 4th return value of localtime()?  The
perlfunc documentation makes this difficulty painfully obvious by
having to list the indices alongside the values.

Secondly, the current solution is seriously non-extensible.  One
cannot easily add new return values to the APIs because someone may be
expecting an exact number of return values, or someone may be
accessing the values by position from the end of the list Obsoleting
values (or marking them as non-applicable to the current platform) has
to be done by for examples returning undef.

=head1 IMPLEMENTATION

The solution is simple: return hashes instead of lists.  Yes, one
still has to know how the fields are named, so the proposed solution
is still not perfect.

=head1 REFERENCES

  perlfunc
  File::stat
  User::grent
  User::pwent
  
  

Re: RFC 22 (v1) Builtin switch statement

[Damian Conway]

   > None of these perform more than one operation per pair of types.  By doing the
   > factoring, you are constraining the type and specific value of the left hand
   > expression in your matching operation, limiting the set of operations that can
   > be performed quite severely.
   >
   >[snip]
   >
   > In this proposal, it would be the commonality of the parameter, not the
   > commonality of the test.  The test includes parameters and matching operation.
   > The type of the second parameter must be determined before the matching
   > operation can be determined.

No. Because the switch value can be a curried function too, so you can factor the
operation as well:

switch ( $x < __ ) {

case 0  { print "negative" }
case 1  { print "unity" }
case any(2..9)  { print "small" }
case @list  { print "in range" }
}


   >   if ( $v == @foo )
   > 
   > is clearly testing the size of foo against the value of $v.

That's not "clear" at all. It's a learned idiom that *isn't* obvious without
understanding. One might just as readily assume that comparison against
an array disjunctively distributes the comparison across the elements.
Of course, that way lies superpositions!

Sigh. We clearly differ irreconcilably on this issue. I suggest that you
counter-propose your version of case and we move on. Larry may well not like
either! ;-)

Damian

Re: RFC 23 (v1) Higher order functions

[Jeremy Howard]

Ken Fox wrote:
> And neither did you... ;) The last line should be:
> > :  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3]
>
> That's why curried functions should automatically re-curry themselves
> instead of depending upon lazy programmers. ;)
>
But of course I only included this 'intentional' error in order to make a
point ;-)

Re: RFC 2 (v1) Request For New Pragma: Implicit

[Bryan C . Warnock]

On Fri, 04 Aug 2000, Bart Lateur wrote:

> I think it's a bad idea. I would rather do it as the C64 did: use a very
> short function name as an alternative to "print".
> 
>   P "This gets printed!", "\n", "Yeah!\n";

> Unfortunately (for you), you can't use '?' because it would be
> ambiguous WRT the ?PATTERN? syntax.

Well, actually, I *did* start off using '?' for print.
(As Damian has proven time and again, import filters are wonderful
toys.  :-)


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

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

[Damian Conway]

   > > This RFC proposes that the right operand of a C<..> operator
   > > may be omitted in a list context, producing a lazily evaluated
   > > semi-finite list. It is further proposed that operations on
   > > such lists also be carried out lazily.
   > > 
   > Why only the right operand? What's wrong with @a[..1]?
   > 
   > Of course then
   >   @negodds = grep { $_%2 } (..-1);
   > needs to start at the top and work down, but that seems OK...

Possible. I'll add it in as a speculation and let Larry veto it :-)

Damian

Re: RFC 23 (v1) Higher order functions

[Damian Conway]

   > Unless I'm missing something here, you're not filling in the args correctly.
   > I think you mean:
   > 
   > $check = sub (;) {
   >   @_==0 ?  __ < 2 + __ * atan($pi/__) or die __
   > : @_==1 ?  $_[0] < 2 + __ * atan($pi/__) or die __
   > : @_==2 ?  $_[0] < 2 + $_[1] * atan($pi/__) or die __
   > : @_==3 ?  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die __
   > :  $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die $_[3]
   > ;
   > };

Yup. Cut-and-paste errors. Serves me right for posting at 3am. %-)


   > > Arguments other than the last can also be bound by the explicit use of
   > > placeholders:
   > 
   > What do you mean 'other than the last'. Isn't your example showing that
   > _all_ the arguments can get bound?

Sorry, what I meant was that, you can bind trailing arguments, just by omitting
them. Non-trailing arguments have to be bound explicitly with an __.

Damian

Re: RFC 23 (v1) Higher order functions

[Damian Conway]

Thanks for the useful insights and pointers, Ken.
Top stuff (as usual :-)

I particularly liked the currying context and notions of explicitly
marking curries. Obviously I'll need to de-jetlag a little more and run
my brain over it again.

However, implicit currying is so damn handy that I suspect that we'll
just cheat and say that only pure assignment *doesn't curry*,
so you have to write:

my $summer = $sum += __;
$root->traverse( $summer );

Or for the truly damned in the audience:

$root->traverse( my $sum = $sum += __ );

Bwah-ha-ha-ha!

Damian

Re: RFC 22 (v1) Builtin switch statement

[Glenn Linderman]

Damian Conway wrote:

>> This switch statement RFC seems to be built on the premise that the
>> reason to have a switch statement is to remove a common parameter
>> from the following limited form conditional expressions.
>
> Yes. As I point out in the paper, that's the *nature* of a switch statement.
> To distribute a test spatially, by factoring.

One could quibble quite extensively about whether that's the nature of the
switch statement, or whether that is a characteristic found in a broad class of
switch statement implementations.  To me the nature of the switch statement is
the selection operation, not the factoring.

>> However, while the table of 16 different ways in which two values
>> could generate a match is interesting, it can only ever perform at
>> most two operations per pair of types (depending on which type is
>> found in which of the two positions).
>
> Not so:

Yes so...

> switch ($value) {
> case 1  {...}   # numeric equality
> case "a"{...}   # string equality
> case $obj   {...}   # referential equality
> case /pat/  {...}   # pattern match
> case %hash  {...}   # hash lookup
> case [1..10]{...}   # list inclusion
> case __<100 {...}   # subroutine return
> }

None of these perform more than one operation per pair of types.  By doing the
factoring, you are constraining the type and specific value of the left hand
expression in your matching operation, limiting the set of operations that can
be performed quite severely.

>> I find it unlikely that the casual Perl programmer, and even many
>> expert Perl programmers, will be able to usefully memorize the list
>> of operations proposed for the type pairs. This inability to
>> memorize the list will no doubt curl the corner of the switch page
>> in the perl documentation.
>
> No. The whole point is that they just DWIM.

Well, they might DWDM, but most of them wouldn't DWIM.
(DWDM=do what Damian means).

That said, there are some useful operations in your list that are complex to
express otherwise; something should be done to make them more easily expressable
if they are common.

>> I think the fundamental purpose of the switch statement is to
>> choose one (generally) of many cases, and that the factoring of one
>> of the parameters is what gets in the way of having a rich set of
>> matching operations.
>
> Just selecting one from many alternatives is a cascaded if's job.

That's one way to do it, at least in Perl we don't get "endif" bloat.

> The defining characteristic of a switch the the factoring of some part
> of the comparisons. And it's an important characteristic, because it
> focussed the reader's mind on the commonality of the test.

In this proposal, it would be the commonality of the parameter, not the
commonality of the test.  The test includes parameters and matching operation.
The type of the second parameter must be determined before the matching
operation can be determined.

>> Hence, I think it suffices to have a single keyword for switch: not
>> "switch", but "case". The block containing "case" would be the
>> switch statement. "case" is simply a rename of "elsif" whose first
>> occurrence in a block simply pretends to follow "if (0) {}".
>
> If that's the consensus, let's just have elsif.
> But I don't think that's the consensus.

elsif makes some of the other features of your proposal harder to do: next would
have to be done with goto/label, for example.  And inter-case statements wind up
requiring cascading blocks, because of the need to separate the else from the
if.  So there is room to beautify a common operation of the language with a
switch statement, without the factoring.

> I appreciate your comments, but I certainly intend to push ahead with
> the proposed syntax -- as I proposed it. A very large number of people
> like it as it is. If I'm wrong, let Larry kill it.

Well, it could be that a very large number of people like it as it is.  Or it
could be that a very large number of people think it is clever, and like the
new, simpler, implicit operators that you've added in your big table of
operators, and haven't thought about how confusing it will be to determine what
is actually happening in a multi-type switch.  The new operations could be
achieved in more flexible ways, rather than only implicitly via the switch
statement.

For instance,

  if ( $v == @foo )

is clearly testing the size of foo against the value of $v.  But

  switch ( $v ) {
case 1: { ... }
case 2: { ... }
case @foo { ... }
  }

does not!  You can argue all day that it is more powerful, and you can even
mention that "case scalar(@foo)" would achieve that goal, but it isn't DWIM.

> Damian

--
Glenn
=
There  are two kinds of pe

Re: RFC 25 (v1) Multiway comparisons

[Ken Fox]

Jonathan Scott Duff wrote:
> On Fri, Aug 04, 2000 at 10:52:24PM -0400, Ken Fox wrote:
> > Why would we ever use source filters when we're going to have a
> > beautiful extend-syntax macro system.
> 
> Because source filters *are* that macro system.  Why would we invent
> yet another language within a language when we can use a language we
> already know--Perl.  We just need to make source filters part of the
> language rather than a module (Perl 5 is already almost there).

Look at the hoops Damian had to go through to implement switch -- he
basically had to *parse perl by hand*. That means the macro system
is weaker than it should be. Any macro system that doesn't know how
to tokenize Perl is too weak.

Source filtering is great for things like compression and encryption.
It's a *long* way from being a good macro system.

- Ken

Re: RFC 23 (v1) Higher order functions

[Ken Fox]

Jeremy Howard wrote:
> Unless I'm missing something here, you're not filling in the args correctly.
> I think you mean:
> 
> $check = sub (;) {
>   @_==0 ?  __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ?  $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ?  $_[0] < 2 + $_[1] * atan($pi/__) or die __
> : @_==3 ?  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die __
> :  $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die $_[3]
> ;
> };

And neither did you... ;) The last line should be:
> :  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3]

That's why curried functions should automatically re-curry themselves
instead of depending upon lazy programmers. ;)

> > Arguments other than the last can also be bound by the explicit use of
> > placeholders:
> 
> What do you mean 'other than the last'. Isn't your example showing that
> _all_ the arguments can get bound?

Not really. In the last case the arguments don't get bound, they get
evaluated. (Since __ doesn't appear, the last case is just a plain
expression.) In all the other cases, the arguments are *not* evaluated
at all, only bound.

Of course, Damian may have meant 'other than the first' and just made
a mistake. The default for a curried function is to re-curry itself if
it is given less than the number of arguments it needs. The re-curry
binds from left to right (first to last). If you don't want the default
left to right binding, then you have to use __ to skip the arguments
you don't want to bind.

- Ken

Re: RFC 25 (v1) Multiway comparisons

[Jonathan Scott Duff]

On Fri, Aug 04, 2000 at 10:52:24PM -0400, Ken Fox wrote:
> Why would we ever use source filters when we're going to have a
> beautiful extend-syntax macro system.

Because source filters *are* that macro system.  Why would we invent
yet another language within a language when we can use a language we
already know--Perl.  We just need to make source filters part of the
language rather than a module (Perl 5 is already almost there).

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 28 (v1) Perl should stay Perl.

[Ken Fox]

Perl6 RFC Librarian wrote:
> not because language design is a fun thing to do of an evening.

Huh? You mean I'm supposed to pretend to not enjoy myself? I keep
all my hair shirts at work, thanks.

> If that's the case, nobody wins if we bend the Perl language out of all
> recognition, because it won't be Perl any more. So let's not do this.

Do you use closures? You know, sub { ... }. That's a blow-your-mind-cool
feature and it's the most important part of Perl *for me*. If you don't
use them that's fine by me, that's what Perl's all about. (Closures didn't
actually work right until around 5.004, but IMHO they were worth waiting
for.)

If anybody proposes a feature that destroys the dialect of Perl you
speak, complain loudly. If somebody proposes a feature you don't
understand, please take the time to learn. I don't see how we can
be a community unless we understand each other. I think I understand
that Perl might be a fragile thing and we should be careful when
changing it. However, it might be a fragile thing that dies because
we don't put any new ideas into it. (Very unlikely problem with
Damian around...)

With that said, I could agree with RFC 28 if the insulting and anti-
community rhetoric about computer science and new-ideas-are-bad was
toned down. (Remember Larry's slide with the Perl influences on it?
Linguistics, Art, Common Sense *and* Computer Science.)

- Ken

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

[Jeremy Howard]

> This RFC proposes that the right operand of a C<..> operator
> may be omitted in a list context, producing a lazily evaluated
> semi-finite list. It is further proposed that operations on
> such lists also be carried out lazily.
> 
Why only the right operand? What's wrong with @a[..1]?

Of course then
  @negodds = grep { $_%2 } (..-1);
needs to start at the top and work down, but that seems OK...

Re: RFC 23 (v1) Higher order functions

[Jeremy Howard]

> $check = sub (;) {
>   @_==0 ?  __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ?  $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ?  $_[0] < 2 + $_[1] * atan($pi/__) or die __
> : @_==3 ?  $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die __
> :  $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die $_[1]
> ;
> };
>
Unless I'm missing something here, you're not filling in the args correctly.
I think you mean:

$check = sub (;) {
  @_==0 ?  __ < 2 + __ * atan($pi/__) or die __
: @_==1 ?  $_[0] < 2 + __ * atan($pi/__) or die __
: @_==2 ?  $_[0] < 2 + $_[1] * atan($pi/__) or die __
: @_==3 ?  $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die __
:  $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die $_[3]
;
};

> Arguments other than the last can also be bound by the explicit use of
> placeholders:

What do you mean 'other than the last'. Isn't your example showing that
_all_ the arguments can get bound?

Re: RFC 25 (v1) Multiway comparisons

[Ken Fox]

Jonathan Scott Duff wrote:
> If implemented via source filters, $x < $y < $z would get translated
> to $x < $y && $y < $z, which, of course, short circuits.   No need for
> "$y (but true)"  (Although, we already have "0 but true" until someone
> submits an RFC to remove it ;-)

Why would we ever use source filters when we're going to have a
beautiful extend-syntax macro system. (I hope!) Is anybody going to
put out a macro RFC? The one I have in mind is R. Kent Dybvig's
hygenic macro system for Chez Scheme. (There's a paper floating
around here someplace. When I find it I'll post pointers to it.)

- Ken

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

[Dan Sugalski]

At 09:38 PM 8/4/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> >$foo = 12;
> >$bar = something();
> >$bar = $foo;
> >
> > could work out to:
> >
> >$foo = $bar = 12;
> >something();
>
>If $foo is a lexical variable and it hasn't been aliased then
>you might be able to do that optimization. The following is just
>as good and safer:
>
>$foo = 12;
>scalar(something());
>$bar = $foo;

Integer constant assignment may well be cheaper than scalar copies. You're 
right about the scalar bit, though, since it's not the same as void context.

> > Where if you tie, we have *no* idea what you're doing. This:
> >
> >tie $foo, SomeModule;
> >$foo = 12;
> >
> > could well reboot some server in outer mongolia for all we know. Tied
> > variable access counts as a function call, which smacks optimization all by
> > itself.
>
>Do we have to worry about pass-by-ref semantics and @_ assignments
>too? This is a weird edge case that I've never ran into. That's going
>to put a big damper on optimization with subs.

Probably not with tie, but with function calls in general, sure. We can do 
some flow control analysis on the subs and propagate it outwards so we 
might know, for example, that:

   sub foo {
 my (@vars) = @_;
 return scalar @vars;
   }

doesn't change its args or any globals, so can be safely optimized around 
to some extent.

>Actually, we have this problem without tie if we allow external
>code to register new primitive types. For example, we assume that +
>is commutative so that we can re-order expressions and fold constants.
>That would break a module that implemented some weird + that wasn't
>commutative.

Yup. It's an issue for things that implement any non-standard semantics for 
existing ops, especially if those ops are overridden at runtime so the 
optimizer doesn't know. It's one thing to mess with tied variables, its 
another entirely to make + behave differently.

I think we'll need to get a ruling from Larry at some point on this one.

>Anybody that does this has to define a new operator, i.e. if they
>use the standard operators, they have to live with the standard
>semantics. (This is why string concatentation should never use +!)

That works for me.

>I really need to start playing with a parser and dataflow analysis
>before thinking too much more about this. It might be that we need
>something *way* more strict than use strict before aggresive
>optimization is possible.

Well, we can still do some pretty aggressive things, but there will be some 
significant limits to code movement and such. Luckily (?) perl's not fast 
enough that rescheduling's a big deal--it's not like with machine code 
where you want to reorder to avoid cache misses and pipeline stalls and 
such. Hoisting code out of a loop, like so:

foreach (1..10) {
  $i = $_;
  print $i;
}

to

   foreach (1..10) [
 print $_;
   }
   $i = 10;

Or, I suppose, this:

   print "12345678910";
   $i=10;

will be a win, but when exactly assignments happen isn't nearly as big a 
deal. I think. Maybe.

Dan

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

Re: RFC 23 (v1) Higher order functions

[Ken Fox]

[Could we get the librarian to cc: the RFC owner and hide
 replies from the announcement list?]

Perl6 RFC Librarian wrote:
> That is, the expression:
> 
> $check = __ < 2 + __ * atan($pi/__) or die __;
> 
> is equivalent to:
> 
> $check = sub (;) {
> $_[0] < 2 + $_[1] * atan($pi/$_[3]) or die $_[4]
> };

I *really* like it. If the internals implement this well (and it
has to be *really* fast and slim) this could have enormous impact.
This feature combined with a decent macro system could implement
many core-like special forms in external modules.

> $root->traverse( $sum += __ );

There's a syntactic ambiguity here. I assumed that __ "poisons" an
expression so that an entire parse tree gets transformed into a
closure. If you isolate the parse tree based on expression precedence,
then I'm not sure why the += example works.

And this one is worse:

> $check = sub (;) {
>   @_==0 ?  __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ?  $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ?  $_[0] < 2 + $_[1] * atan($pi/__) or die __
> : @_==3 ?  $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die __
> :  $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die $_[1]
> ;
> };

Why isn't the ?: operator part of the curry?

I think we need a curry context and that all curries must be surrounded
by parens. There should be a curry prototype for subs too. reduce can be
written as:

  sub reduce (_@) { ... }

Curries formed outside of a default curry context must be forced into
the context with curry().

If we adopt curry context and parens, then the __ can be automatically
inserted in some situations.

Here are some examples.

  sub traverse ($_);
  my $sum = 0;
  $root->traverse(($sum += __));

  my @flattened = ();
  $root->traverse((push @flattened, __));

  sub reduce (_@);
  $sum = reduce (+) (0, @nums);

  $pred = shift || curry(__ ne '');
  if (&$pred($x)) { ... }

The use of parens as the curry delimiter is probably a poor choice
because of confusion with function call syntax and list context. I'm
pretty certain the parser could handle it, but I'm not sure about
the perl programmers...

- Ken

Re: RFC 17 (v1) Organization and Rationalization of Perl

[William Setzer]

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
:
: =head2 Disadvantages
: 
: Literally none have been broached on the various C mailing lists.

Potential disadvantage, depending on implementation:

The loss of distinctiveness.  Right now, when one sees a $
variable, they notice its specialness and have a visual clue to take
care.  $ stands out, and as some of these variables have
wide-reaching side-effects, it might be worth it to try and maintain
this distinctiveness.


William

Re: Proposed sublist: flowcontrol

[Uri Guttman]

> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:

> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
  UG> dispatch  - discuss support of the multiple ways to control
  UG> dispatching of perl ops (event loops, threads,
  UG> co-routines, etc.)

  UG> the dispatch list should eventually split off lists that focus on
  UG> the semantic details of each technology. the final RFCs from those
  UG> lists will be coordinated and hopefully presented as a unified
  UG> design of the control flow of Perl.

  CF> Why is this not -internals?

because it is very tricky to isolate flow control issues to pure
language or internals. my plan is to do as many language flow rfc's as
we can and then move the list (or a clone) to the internals. knowing all
the needed language features helps design the op disptach mechanism to
support them and that affects how the different techniques interact with
each other. i just think it should start in the language world first and
migrate to internals later once we have a proper set of rfc's.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

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

[Ken Fox]

Dan Sugalski wrote:
>$foo = 12;
>$bar = something();
>$bar = $foo;
> 
> could work out to:
> 
>$foo = $bar = 12;
>something();

If $foo is a lexical variable and it hasn't been aliased then
you might be able to do that optimization. The following is just
as good and safer:

$foo = 12;
scalar(something());
$bar = $foo;

> Where if you tie, we have *no* idea what you're doing. This:
> 
>tie $foo, SomeModule;
>$foo = 12;
> 
> could well reboot some server in outer mongolia for all we know. Tied
> variable access counts as a function call, which smacks optimization all by
> itself.

Do we have to worry about pass-by-ref semantics and @_ assignments
too? This is a weird edge case that I've never ran into. That's going
to put a big damper on optimization with subs.

Actually, we have this problem without tie if we allow external
code to register new primitive types. For example, we assume that +
is commutative so that we can re-order expressions and fold constants.
That would break a module that implemented some weird + that wasn't
commutative.

Anybody that does this has to define a new operator, i.e. if they
use the standard operators, they have to live with the standard
semantics. (This is why string concatentation should never use +!)

I really need to start playing with a parser and dataflow analysis
before thinking too much more about this. It might be that we need
something *way* more strict than use strict before aggresive
optimization is possible.

- Ken

Re: New Group proposed: subs (was Re: named parameters)

[J. David Blackstone]

Glenn Linderman wrote:
> Now what good meanings could we attribute to $myself and $I
> ?

  Right.  Remember, if it looks like Perl (and with the addition of
$ME, it will), then it probably is Perl. :)

J. David

Re: New Group proposed: subs (was Re: named parameters)

[J. David Blackstone]

Andy Wardley wrote:
> What about '$me'?   It ties in nicely with 'my' (although perhaps for the
> wrong reasons), it's half as much typing as 'self' or 'this' and we get
> to annoy both sets of religious zealots at once.  :-)=

  Yes!  I love it!

Re: RFC 29 (v1) unlink() should be left alone

[Tim Jenness]

On Fri, 4 Aug 2000, Damien Neil wrote:

> My opinion on the unlink()/remove() debate: Ignoring our history is
> foolish.  Why suddenly transform every Perl program that uses unlink(),
> which has been valid for over a decade, into one using an outmoded and
> deprecated construct?  unlink() is, in my opinion, actually clearer
> than remove(), for it more accurately specifies what the operation
> does.

I agree with this. Changing the name of a function without any gain in
functionality seems a bit mad. localtime is under "attack" for specific
reasons unrelated to its name.

When I first started perl (coming from Fortran) I also had trouble sifting
through the docs working out how to remove a file but once I knew it was
unlink I simply used it because that was the perl command for "rm".

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: RFC 29 (v1) unlink() should be left alone

[Tom Christiansen]

Gosh, just unlink() leave it as it is.  

--tom

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

[Glenn Linderman]

John Porter wrote:

> Glenn Linderman wrote:
> >
> > What good are comments if you can't find them when you need them?
>
> There's not thinging to stop you from writing
>
> qc/*** MAGIC HERE */;

Oh so true, but there's nothing that makes me want to do that either.
When using an inline comment, I want to spend my character budget mostly
on the comment, and just enough on the delimiters to see it
effectively.  #< magic here ># would do quite nicely, and is quite
related to existing Perl comment syntax.

> Nor from typing
>
> /qc
>
> in vi (if you use vi).
>
> --
> John Porter

Oh so true, but there's nothing that makes me want to do that either.
When reading a script, I'd like to be able to quickly distinguish the
comments using my eyeballs and brain, without the need to involve my
fingers and editor and not all scripts are in my editor (which isn't
vi) anyway.  Some are on glossy magazine paper, which makes it
annoyingly difficult to involve my editor (without, if available, first
downloading the script from somewhere).

--
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 29 (v1) unlink() should be left alone

[Spider Boardman]

> On Fri, 4 Aug 2000 16:33:41 -0700, Damien Neil wrote (in part):

Damien> On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman
Damien> wrote:
>> The C (POSIX.1) remove() function is NOT just unlink() in
>> drag.

Damien> Not everywhere, at least:

Damien> REMOVE(3) FreeBSD Library Functions Manual REMOVE(3)

Hmm.  OK, the reference I have is a combined one for UNIX95, so
this may be a question of XPG-only or of *which* POSIX.1 (199309
or 199506), but at least *some* versions of remove(3) are not
simply unlink(2) by another name.

-- 
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.http://www.ultranet.com/~spiderb
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89  F6 B2 C2 A0 1C AB 1F DC

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

[Jeremy Howard]

Karl Glazebrook wrote:
> OK I will raise to the bait
>
> I think it's a bit unfair to say that PDL people have failed to 'bite',
> there was quite a bit of discussion on our list after your post. Also
> some concern about how much of perl6 is vapourware.
>
I do apologise, Karl. It turns out that I had a problem with my PDL-P list
subscription so I didn't see that there were some comments made. It would be
great to keep perl6-language involved anyway (as seems to be happening now).

> I definitely support embedding many of the key PDL ideas into the language
> - they key one is a much easier syntax for a multi-dim slice. We are
currently
> driven to
>
> $a->slice("10:100,30:200");
>
> compared to IDL AND NumPy: a[10:100,30:200]
>
It's not just that it's ugly. It's hard to optimise, and it doesn't work on
infinite lists (which don't actually exist yet ;-)

> perl6 should provide simple arrays, but they should be allowed to be
> replaced with objects with no change of syntax. So
>
> @a[10:100,30:200];
>
> Would work whether @a was a perl list of lists or a PDL compact array.
>
> So would @a * @b
>
Well, ideally, there wouldn't be a 'PDL compact array'. Instead, compact
arrays would be part of perl 6, and would be used as appropriate. But yes,
the same syntax should always 'just work'.

> Loop unrolling sounds really good, their should be hooks for objects to
> provide their own implementation. Proper overloading and ability to
> overload by arg type are required, i.e.
>
> sub myfunc{ float x, complex y }
> sub myfunc{ float x, float y }
>
There's been some discussion of this on perl6-internals. Dan Sugalski and
Ken Fox have pointed out that a general change towards thinking of lists as
pointers and streams would allow for nice optimisations when doing
reductions, as well as more generally speeding up passing lists as
parameters.
>
> Their should also be hooks for slices, for example if one is implementing
> a complex objects (e.g. representing a map) - one might want a slice in
> physical units instead of array indices.
>
> I'd even propose getting rid of @a for arrays and $a for scalars and just
> making the "a". I've never really liked that feature of perl - I am sure
> some users agree and some disagree - might be worth taking a straw poll.
> In this age where everything may (or may not) be an object are $ and @
really
> required? There are too many objects types and not enough funny symbols..
> even with Unicode.
>
This has been discussed before. It didn't go down awfully well ;-) 'Keeping
perl as perl' was a common argument...

Re: PDL-P: indexing

[Jeremy Howard]

Joshua N Pritikin wrote:
> <...>
> Also, you can specify a non-default step size:
>
>   @pdl(1:9:2, 1:9:2);  # (1,1) (3,1) (5,1) (7,1) (9,1) (1,3) (3,3) ...
>
> Although I'm not sure how frequently custom step sizes are used in PDL
> code...
>
More generally, we need to be able to specify:
- Slices: non-default step sizes here allow n-dimensional tensors to be
handled gracefully
- Indirect indexes: eg. @a=(3,4,7); @b[@a] works as in perl now
- Masks: eg. @a=(0,0,1,1,0,0,1); @b->mask[@a] works as above

As you can see, in terms of the semantics, simple slice() and mask()
functions can on the face of it be used to generate the indirect index
approach that perl already supports.

Unless your array is of infinite size of course... maybe we don't want to
get into that right now...

There's a bit to be done in the implementation to make sure that real
numerical programs don't grind to a halt. For instance, it's not unusual to
want to say (this is not real code):
@a = sumover(@b[$INDEX::j]*@c[$INDEX::j])
where $INDEX::j is a column iterator, and @c and @b are matrices, and '*' is
component-wise multiplication. @a then becomes the sum of the component-wise
multiplications of columns in @b and @c.

Now what if @c and @b are sparse matrices? That means they're actually:
@c = @craw[@cindexes]; @b = @braw[@bindexes];
Then in every loop we're following the indirect index, doing a lookup to
find the right spot in column vector, and in the worst case generating a
temporary matrix of the size of @b and doing a redundant loop.

Perl has all the information it needs at compile time though to combine the
indirect index and the slice, and to avoid the redundant memory copy and
loop in the reduce (as I've mentioned previously on perl6-internals).

Sparse arrays/matrices/tensors are not rare. Transposing them is common too,
as is reducing along one dimension. Languages which don't deal with these
issues gracefully at compile time simply can't be used for numerical
programming (because they can be an order of magnitude slower by not doing
the optimisations I've mentioned).

As Karl Glazebrook described so eloquently, PDL currently jumps through all
kinds of hoops to do appropriate optimisations. However, because this all
has to be done in C, it's hard for us Mere Mortals so write our own
functions. It would be just _so_ fun to do all this in pure perl.

Re: RFC 29 (v1) unlink() should be left alone

[Damien Neil]

On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman wrote:
> The C (POSIX.1) remove() function is NOT just unlink() in drag.

Not everywhere, at least:

>REMOVE(3)  FreeBSD Library Functions Manual  REMOVE(3)
...
> The remove() function is an alias for the unlink(2) system call.  It
> deletes the file referenced by path.

I unfortunately don't have a copy of either the ISO C standard or POSIX.1
handy at the moment, so I can't comment on what they say about it.  Given
that ISO C doesn't say anything about directories, I suspect that this
is conforming C at least.


My opinion on the unlink()/remove() debate: Ignoring our history is
foolish.  Why suddenly transform every Perl program that uses unlink(),
which has been valid for over a decade, into one using an outmoded and
deprecated construct?  unlink() is, in my opinion, actually clearer
than remove(), for it more accurately specifies what the operation
does.

The opinion that remove() should exist and search-and-destroy all links
to a file is even more foolish.  Even if this were somehow practical
on any filesystem in common use, this would be an exceptionally
dangerous and destructive operation.  If there is a remove() function,
novices will find it before they come across unlink().  Do we really
want the first file-removal operation they discover to perform such
horrible action at a distance?

I would have no objection to adding remove() as a synonym for unlink(),
or as a unlink()/rmdir() hybrid.  It is certainly true that when a
novice goes hunting for a way to remove a file, unlink() is going to
take a while to discover.  Why not provide a name that they are likely
to look for quickly?  (Especially given the prior art of the C remove().)

- Damien

Re: Avoid memory copy and redundant loops in reduce/fold

[Jeremy Howard]

Ken Fox wrote:

> > $a = sum(@b*@c+@d)
>
> I'm not strong in math, but I do remember a bit about row and column
> vectors. Isn't @b*@c ambiguous? Shouldn't it normally be interpreted
> as a dot product, i.e. treat all vectors the same?
>
It depends on what perl6-language comes up with. Probably '*' will mean
component-wise product and 'x' will mean inner product (or visa-versa). I'm
talking about the component-wise product version.

> > The normal problem with this type of structure is that the previous
> > statement would create 2 array copies, and 3 loops for most compilers.
In
> > perl speak, it might look like:
> > $dummy1[$_] = $b[$_]*$c[$_] for (0..$#b-1);
> > $dummy2[$_] = $d[$_]+$dummy1[$_] for (0..$#dummy1-1);
> > $sum+=$_ for (@dummy2);
>
> A simpler rule would be to treat an array as an implicit stream
> whenever it's used in a scalar+reduce context. Then the following
> code would be generated:
>
>   $dummy1 = stream @b;
>   $dummy2 = stream @c;
>   $dummy3 = stream @d;
>   while ($dummy4 = $dummy1->next * $dummy2->next + $dummy3->next) {
> $sum += $dummy4;
>   }
>
Excellent! There are C++ libraries that use the stream approach, and they're
_really_ fast! But they're a pain to use. This is just the kind of extra
optimisation I was hoping that perl 6 could achieve.

> > $sum+=$b[$_]*$c[$_]+$d[$_] for (0..$#b-1);
>
> Shouldn't that be
>
>   $sum+=$b[$_]*$c[$_]+$d[$_] for (0..min($#b, $#c, $#d));
>
Actually, we're still trying to decide on perl6-language what this means. It
might be even be max(), with undef passed in for short arrays. I was just
being lazy to show an example.

> > Without this optimisation, array semantics become next to useless for
> > numeric programming, because their overhead is just so high.
>
> I think talking about array semantics instead of vector and matrix
> semantics is next to useless too, but I'm not a math guy.
>
I really mean 'tensor semantics', which is a generalisation of matrices to n
dimensions. But I was worried that non-math guys might see 'tensor' and
their brains would explode ;-)

Anyway, tensors are just a generalisation. Ideally, good slicing, masking,
and indirect indexing on arrays allow the user to easily create any kind of
multi-dimensional structure they want, including sparse structures. Then
it's just a case of creating wrappers to make them look like real tensors.

...As long as the overhead is stripped away at compile time, of course.

Re: RFC 29 (v1) unlink() should be left alone

[Russ Allbery]

Myers, Dirk <[EMAIL PROTECTED]> writes:

> If a remove() is added, it should (IMHO) seek-and-destroy.

This is impossible on a Unix file system.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

RFC 34 (v1) Angle brackets should not be used for fi

[Perl6 RFC Librarian]

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

=head1 TITLE

Angle brackets should not be used for file globbing.

=head1 VERSION

  Maintainer: Jon Ericson <[EMAIL PROTECTED]>
  Date: 4 August 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 34

=head1 ABSTRACT

Angle brackets have two separate meanings in Perl - file globbing and
line input from a filehandle.  This means that perl attempts to Do What
I Mean and often misinterprets me.  Since file globbing can be
accomplished with the glob function and since file input is the more
common use of angle brackets, they should not be used for file globbing.

=head1 DESCRIPTION

=head2 Background

>From perlop/"I/O Operators":

If angle brackets contain is a simple scalar variable (e.g.,
<$foo>), then that variable contains the name of the
filehandle to input from, or its typeglob, or a reference to the
same.  For example:

$fh = \*STDIN;
$line = <$fh>;

If what's within the angle brackets is neither a filehandle nor a simple
scalar variable containing a filehandle name, typeglob, or typeglob
reference, it is interpreted as a filename pattern to be globbed, and
either a list of filenames or the next filename in the list is returned,
depending on context.  This distinction is determined on syntactic
grounds alone.  That means C<< <$x> >> is always a readline() from
an indirect handle, but C<< <$hash{key}> >> is always a glob().
That's because $x is a simple scalar variable, but C<$hash{key}> is
not--it's a hash element.

One level of double-quote interpretation is done first, but you can't
say C<< <$foo> >> because that's an indirect filehandle as explained
in the previous paragraph.  (In older versions of Perl, programmers
would insert curly brackets to force interpretation as a filename glob:
C<< <${foo}> >>.  These days, it's considered cleaner to call the
internal function directly as C, which is probably the right
way to have done it in the first place.)  For example:

while (<*.c>) {
chmod 0644, $_;
}

is roughly equivalent to:

open(FOO, "echo *.c | tr -s ' \t\r\f' '\\012\\012\\012\\012'|");
while () {
chop;
chmod 0644, $_;
}

except that the globbing is actually done internally using the standard
C extension.  Of course, the shortest way to do the above
is:

chmod 0644, <*.c>;

A (file)glob evaluates its (embedded) argument only when it is
starting a new list.  All values must be read before it will start
over.  In list context, this isn't important because you automatically
get them all anyway.  However, in scalar context the operator returns
the next value each time it's called, or C when the list has
run out.  As with filehandle reads, an automatic C is
generated when the glob occurs in the test part of a C,
because legal glob returns (e.g. a file called F<0>) would otherwise
terminate the loop.  Again, C is returned only once.  So if
you're expecting a single value from a glob, it is much better to
say

($file) = ;

than

$file = ;

because the latter will alternate between returning a filename and
returning false.

It you're trying to do variable interpolation, it's definitely better
to use the glob() function, because the older notation can cause people
to become confused with the indirect filehandle notation.

@files = glob("$dir/*.[ch]");
@files = glob($files[$i]);

=head2 Areas of confusion

=over

=item Complex filehandle references

my %filesystem;
my $filename = '/etc/shells';
open $filesystem{$filename}, $filename 
or die "can't open $filename: $!";
print <$filesystem{$filename}>;
__END__

GLOB{0xa042284}

=item Simple file glob variables

my $fileglob = '/etc/sh*';
print <$fileglob>;
__END__

[nothing printed]

=item Why don't these have the same output?

$ perl -e 'print '
/etc/shells

$ perl -e 'print <>' /etc/sh*
/bin/sh
/bin/bash

=back

=head2 The glob function exists

Now that we have a function interface to file globbing, why do we need
the obscure operator interface?

=head2 The readline meaning is more common

Angle brackets are a shortcut for either glob() or readline().  If we
are going to eliminate one meaning, it should be the less common
meaning.  

=head1 IMPLEMENTATION

Remove the file-globbing behavior of the angle brackets.

=head1 REFERENCES

perlop/"I/O Operators", perlfunc/glob, perlfunc/readline

Re: New Group proposed: subs (was Re: named parameters)

[Tom Christiansen]

>Andy Wardley wrote:

>> What about '$me'?   It ties in nicely with 'my' (although perhaps for the
>> wrong reasons), it's half as much typing as 'self' or 'this' and we get
>> to annoy both sets of religious zealots at once.  :-)=

>Yes, absolutely.  Now what good meanings could we attribute to $myself and $I

Predefines ought to be all capped!
--tom

Re: RFC 10 (v2) Filehandles should use C<*> as a type pr

[Nathan Wiger]

I think this is a good candidate for recording why we decided not to do
something.

Did we even reach consensus on how to do this? Put a Status: header in
VERSION?

For recording purposes, maybe once the Status: line is added we should
add an additional section. Maybe STATUS, JUSTIFICATION, POSTMORTEM, or
something else, that can just have a one-paragraph explanation, like:


=head1 STATUS

Consensus has been reached that filehandles will be represented as
scalars or objects in scalars (C<$fh>) everywhere. Therefore, there is
no need to make a new type out of them.  This RFC has been withdrawn.

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

[Russ Allbery]

Steve Simmons <[EMAIL PROTECTED]> writes:

> m4.

> IMHO perl6 should continue the rich tradition of stealing from the best
> rather than re-inventing an only marginally better wheel.  m4 is better
> than cpp, and was intended to be a general macro package.  Are there
> versions available which are not strongly unfettered by license issues?

Yes, BSD m4 should be usable, and IIRC the OpenBSD version has sufficient
power to handle autoconf (which pounds the hell out of m4, much more so
than we'd be likely to).

However, cpp has the significant advantage that its active syntax is
designed to be embedded in a programming language and are Perl comments.
This is *not* true of m4, which would be horribly, horribly confused by a
Perl script.  m4 was not designed with embedding in a programming language
in mind, and lots of things like macro invocation syntax and default
quoting characters would interact very poorly with Perl.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

RFC 33 (v1) Eliminate bareword filehandles.

[Perl6 RFC Librarian]

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

=head1 TITLE

Eliminate bareword filehandles.

=head1 VERSION

 Maintainer: Peter Scott <[EMAIL PROTECTED]>
 Date: 4 Aug 2000
 Version: 1
 Mailing List: [EMAIL PROTECTED]
 Number: 33

=head1 ABSTRACT

Now that scalars (objects) can be used for filehandles, the bareword form 
should be eliminated.

=head1 DESCRIPTION

The venerable bareword form of the filehandle leads to code that is 
unnecessarily abstruse given that they can now be stored in 
scalars.  Bareword filehandles are not lexical, and require the use of 
typeglobs and C to pass them to subroutines, concepts unnecessarily 
advanced for such a beginner-type operation.

=head1 IMPLEMENTATION

Easy, hopefully.

=head1 REFERENCES

L

RFC 10 (v2) Filehandles should use C<*> as a type pr

[Perl6 RFC Librarian]

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

=head1 TITLE

Filehandles should use C<*> as a type prefix if typeglobs are eliminated.

=head1 VERSION

 Maintainer: Peter Scott <[EMAIL PROTECTED]>
 Date: 4 Aug 2000
 Version: 2
 Mailing List: [EMAIL PROTECTED]
 Number: 10

=head1 ABSTRACT

Version 1 of this RFC stated: "The lack of a type-defining punctuation 
character prefix for filehandles makes them second-class variables in Perl. 
If typeglobs are eliminated in Perl 6, the C<*> character would become 
available as a type prefix character and could be used for filehandles."

Version 2 withdraws this request, contingent upon the removal of bareword 
filehandles in Perl 6.  If scalars or objects in scalars (C<$fh>) are used 
for filehandles everywhere then there is no need to make a new type out of 
them.  The rest of the original RFC is left below for archival purposes.

=head1 DESCRIPTION

To pass filehandles around one either has to use a typeglob (C) 
or put them in a scalar (C or the 5.6 C), at which point you can't tell that they're filehandles without the 
right context.

There have been serious proposals to eliminate typeglobs in Perl 6. If they 
get axed, the C<*> character could be reused for another datatype and the 
filehandle is fortuitously closely related.

The mental jump is fairly small, since most people other than module 
developers only ever saw C<*> used for filehandles anyway:

 local *FH;
 open (FH, ...);

This proposal would change that to

 open (my *fh, ...);

=head1 IMPLEMENTATION

Backwards compatibility takes a hit unless the current filehandle syntax is 
grandfathered in; I am not taking a position on whether it should be. Since 
it is contingent upon typeglobs being eliminated, it won't break any 
existing code that already uses typeglobs that won't be broken anyway.

Use of Cs will now look like

 while (<*fh>) { ...

which means that the use of the angle operator for globbing also has to go. 
As if an excuse were needed.

This proposal also applies to directory handles.

=head1 REFERENCES

L

Re: RFC 22 (v1) Builtin switch statement

[Damian Conway]

   > This switch statement RFC seems to be built on the premise that the
   > reason to have a switch statement is to remove a common parameter
   > from the following limited form conditional expressions.

Yes. As I point out in the paper, that's the *nature* of a switch statement.
To distribute a test spatially, by factoring.
   
   > However, while the table of 16 different ways in which two values
   > could generate a match is interesting, it can only ever perform at
   > most two operations per pair of types (depending on which type is
   > found in which of the two positions).
   
Not so:

switch ($value) {
case 1  {...}   # numeric equality
case "a"{...}   # string equality
case $obj   {...}   # referential equality
case /pat/  {...}   # pattern match
case %hash  {...}   # hash lookup
case [1..10]{...}   # list inclusion
case __<100 {...}   # subroutine return
}

Granted one would rarely want all these at once, but a non-trivial subset
is entirely plausible:

sub classify {
switch ($_[0]) {
case 0  { return 'zero' }
case \&odd  { return 'odd' }
case [1..9] { return 'even' }
case /[a-f]/i   { return 'hex' }
}
}

   
   > I find it unlikely that the casual Perl programmer, and even many
   > expert Perl programmers, will be able to usefully memorize the list
   > of operations proposed for the type pairs. This inability to
   > memorize the list will no doubt curl the corner of the switch page
   > in the perl documentation.

No. The whole point is that they just DWIM.

   
   > I think the fundamental purpose of the switch statement is to
   > choose one (generally) of many cases, and that the factoring of one
   > of the parameters is what gets in the way of having a rich set of
   > matching operations.

Just selecting one from many alternatives is a cascaded if's job.

The defining characteristic of a switch the the factoring of some part
of the comparisons. And it's an important characteristic, because it
focussed the reader's mind on the commonality of the test.


   > Hence, I think it suffices to have a single keyword for switch: not
   > "switch", but "case". The block containing "case" would be the
   > switch statement. "case" is simply a rename of "elsif" whose first
   > occurrence in a block simply pretends to follow "if (0) {}". 

If that's the consensus, let's just have elsif.
But I don't think that's the consensus.

I appreciate your comments, but I certainly intend to push ahead with
the proposed syntax -- as I proposed it. A very large number of people
like it as it is. If I'm wrong, let Larry kill it.

Damian

Re: RFC 22 (v1) Builtin switch statement

[John Porter]

Glenn Linderman wrote:
> 
> This is not to detract from the ideas of higher order functions or curried
> whatever, but I
> don't think those are or should be necessary to a powerful switch statement.

I vote thus: to have RFC 22 rejected (29 rules?!), and RFC 23 accepted,
with appropriate ramifications/extensions, so that ppl can write
switch-like constructs however they want.

-- 
John Porter

Re: RFC 16 (v1) Keep default Perl free of constraints su

[Chaim Frenkel]

You would need two (or more) perl executables.

The downloaded CPAN (or other source) scripts/modules that don't follow
the conventions would either have to be ported to the local environment.
Or they would need their own executable that doesn't follow the standard.

One or more groups will suffer.



> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:

PS> At 10:59 AM 8/4/00 +0200, Johan Vromans wrote:
>> >   What if the default strictness of vars was a compile-time option to
>> > be decided by the administrator of each site?
>> 
>> Good grief, no! Perl should be perl, and not depend on site issues.
>> And, in anticipation: yes, there _is_ a difference between "you must
>> install module FooBar.pm 3.14 before you can use this" and "you need
>> to rebuild your perl".

PS> It would not be "you need to rebuild your perl", but "the administrator of 
PS> this site does not allow unstrict programming by default."

PS> Letting sites set strictness by default is just a way of giving some 
PS> control to the ones who want it, not denying it to the ones who don't.

PS> I would like to go further and allow sites the ability to make perls that 
PS> *can't* disable certain strictnesses, although that may not be viable with 
PS> the strictnesses we have right now.  Perl doesn't outlaw fascism (witness 
PS> closures-as-objects); it just requires it be optional.

PS> This is a (not *the*) key to the acceptance of Perl for large projects in 
PS> large institutions.  You don't have to work for one or like the way they go 
PS> about things, but if we can give them something that doesn't hurt everyone 
PS> else then it's a win.  At least by the "Big House" philosophy.
PS> --
PS> Peter Scott
PS> Pacific Systems Design Technologies




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

Re: RFC 22 (v1) Builtin switch statement

[Glenn Linderman]

This switch statement RFC seems to be built on the premise that the reason to have a 
switch
statement is to remove a common parameter from the following limited form conditional
expressions.  For that reason, two new keywords are required: switch: to define the 
common
parameter, and case: to introduce the second parameter of the matching operation.  The 
second
typical behavior regarding switch statements is embodied in the proposal, that of 
executing
(generally) one sub-statement per switch statement.

However, while the table of 16 different ways in which two values could generate a 
match is
interesting, it can only ever perform at most two operations per pair of types 
(depending on
which type is found in which of the two positions).  Anything else must be performed 
via a
sub ref.  And when sub ref's are used, the repetitive nature of specifying the implied
parameter led to another keyword "__".

I find it unlikely that the casual Perl programmer, and even many expert Perl 
programmers,
will be able to usefully memorize the list of operations proposed for the type pairs.  
This
inability to memorize the list will no doubt curl the corner of the switch page in the 
perl
documentation.

Other posters have pointed out ideas for extending this RFC to have things other than 
the
first parameter of a match operation factored out: the match op-code, both a parameter 
and an
operator, etc.

I think the fundamental purpose of the switch statement is to choose one (generally) 
of many
cases, and that the factoring of one of the parameters is what gets in the way of 
having a
rich set of matching operations.

Hence, I think it suffices to have a single keyword for switch: not "switch", but 
"case".
The block containing "case" would be the switch statement.  "case" is simply a rename 
of
"elsif" whose first occurrence in a block simply pretends to follow "if (0) {}".  So 
we have,
for example:

{ case ( 0 <= $a <= 9 )  { print "single digit\n" }
  case ( 10 <= $a )  { print "digits\n" }
  case ( $a == 7 )   { print "lucky seven"\n" }
}

In some sense, this is simply "syntactic sugar" around the existing if statement; the 
other
features (next, statements between cases, etc.) from the original proposal could be 
added to
this one, which would make it more than "syntactic sugar".

Regarding the particular implied match operations in the original proposal, if the 
benefit of
the switch statement is that the implied operation is hard to express so the switch 
statement
makes it easy so therefore the switch statement is good, then perhaps it would be a 
good idea
to RFC the syntax of those operations to produce an easier operator syntax that could 
be used
outside the context of the switch statement as well as inside a simpler switch 
statement.

This is not to detract from the ideas of higher order functions or curried whatever, 
but I
don't think those are or should be necessary to a powerful switch statement.

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

Re: RFC 30 (v1) STDIN, STDOUT, and STDERR should be rena

[John Porter]

> STDIN, STDOUT, and STDERR should follow suit and be renamed
> $STDIN, $STDOUT, and $STDERR.



$TDIN, $TDOUT, $TDERR



-- 
John Porter

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

[Chaim Frenkel]

lazy as an operator or attribute was discussed (a year ago?) on
p5p.

This would be needed to allow user subs to operate exactly like built-ins.

sub foo : lazy { ... }

or 
&foo lazy @foo, &bar(), ...

(Hmm, 
Actually, putting a code ref/closure on the stack, then the @_ iterator
would then execute/iterate over it.
)



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


AS> This would be nice, but I think should be folded into something more
AS> general, like tieable first-class iterators.  I'm still trying to pull
AS> my thoughts together on this one, but lazy lists could be a special
AS> case of iterators.

AS> An `iterator' should have properties somewhat like these; the idea is
AS> to allow the implementation of `map', `grep', `zip', `reduce', `for',
AS> and maybe others.  Also, as a first-class type, users should be able
AS> to use all iterator facilities.


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

RFC 30 (v1) STDIN, STDOUT, and STDERR should be rena

[Perl6 RFC Librarian]

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

=head1 TITLE

STDIN, STDOUT, and STDERR should be renamed

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 04 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: 30

=head1 ABSTRACT

Consensus has been reached that filehandles (currently
barewords) will be renamed to use the leading $ type, to
make them consistent with Perl.

STDIN, STDOUT, and STDERR should follow suit and be renamed
$STDIN, $STDOUT, and $STDERR.

=head1 DESCRIPTION

Currently, filehandles are barewords, such as FILE and
PIPE. However, for Perl 6 these are planned to be renamed
to true "single-whatzitz" types (thanks Tom) and prefixed
with a $. So, the current:

   print FILE "$stuff\n";

Will become something like:

   print $fh "$stuff\n";

STDIN, STDOUT, and STDERR need to follow suit. We should
change 

   print STDERR "$stuff\n";

to:

   print $STDERR "$stuff\n";

This makes them consistent with other Perl variables, such
as @ARGV, %INC, $VERSION, etc, all of which have the correct
distiguishing prefix for their type.

=head1 IMPLEMENTATION

All references to STDIN, STDOUT, and STDERR will have to
be changed.

We may also want to consider making them readonly. Consider
the implications of:

   $STDOUT = $fh;
   print "$stuff\n";

This would potentially have the same effect as current:

   select($fh);
   print "$stuff\n";

Perhaps we want this behavior, it is pretty cool. But maybe
we don't.

=head1 REFERENCES

RFC14, Modify open() and opendir() to return handle objects

RFC: "Empty But True" Special String Value (was Re: RFC 25)

[John Porter]

-- 
John Porter

Re: RFC 25 (v1) Multiway comparisons

[Damian Conway]

   > > > This RFC proposes that multiway comparisons such as:
   > > >
   > > > if ( 0 <= $x < 10 ) { print "digit" }
   > > >
   > > > should do what the user means.
   > 
   > I think this should mean what it means in Icon, namely, that
   > $x < $y  evaluates to false if $x >= $y, and evaluates to
   > "$y (but true)" if $x < $y.  This allows the operators to be
   > nested, i.e.   $x < $y < $z would be ( $x < $y ) < $z, which
   > performs the $y < $z comparison iff $x < $y.

I very much like Icon's failure model, but I was loathe to try and
graft it wholesale onto Perl 6. Doing it properly would require a
substantial rethink of the exception mechanism, flow control, the
nature of scalars, undef, etc., etc.

In the end I concluded that simple DWIMity on multiway comparisons 
was enough.

But don't let that stop you counter-proposing the fuller mechanism. :-)

Damian

Re: RFC 25 (v1) Multiway comparisons

[Jonathan Scott Duff]

On Fri, Aug 04, 2000 at 04:48:24PM -0400, John Porter wrote:
> I think this should mean what it means in Icon, namely, that
> $x < $y  evaluates to false if $x >= $y, and evaluates to
> "$y (but true)" if $x < $y.  This allows the operators to be
> nested, i.e.   $x < $y < $z would be ( $x < $y ) < $z, which
> performs the $y < $z comparison iff $x < $y.

If implemented via source filters, $x < $y < $z would get translated
to $x < $y && $y < $z, which, of course, short circuits.   No need for
"$y (but true)"  (Although, we already have "0 but true" until someone
submits an RFC to remove it ;-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 25 (v1) Multiway comparisons

[John Porter]

> > This RFC proposes that multiway comparisons such as:
> >
> > if ( 0 <= $x < 10 ) {
> > print "digit"
> > }
> >
> > should do what the user means.

I think this should mean what it means in Icon, namely, that
$x < $y  evaluates to false if $x >= $y, and evaluates to
"$y (but true)" if $x < $y.  This allows the operators to be
nested, i.e.   $x < $y < $z would be ( $x < $y ) < $z, which
performs the $y < $z comparison iff $x < $y.

But this is all off the top of my head; the Icon references
should be consulted on this.

-- 
John Porter

Re: Different points of view, a little perspective.

[John Porter]

We're here to work on perl6.  Let's stay focused.  

-- 
John Porter

Re: RFC 25 (v1) Multiway comparisons

[Damian Conway]

   > I suspect it already has a different meaning, based on operator
   > precedence rules, left to right evaluation, etc., but I strongly
   > doubt there is much use of it in that manner, and would encourage
   > this redefinition to be used instead.

It's currently an error (even if you redefine operators so it should work!)
It *does* have a different (and stupid) meaning in C, but let's not go there.

Damian

Re: RFC 25 (v1) Multiway comparisons

[Glenn Linderman]

Great idea!  (Don't accuse me of apathetic lurking!)

I suspect it already has a different meaning, based on operator precedence rules,
left to right evaluation, etc., but I strongly doubt there is much use of it in
that manner, and would encourage this redefinition to be used instead.

Perl6 RFC Librarian wrote:

> This RFC proposes that multiway comparisons such as:
>
> if ( 0 <= $x < 10 ) {
> print "digit"
> }
>
> should do what the user means.

--
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 29 (v1) unlink() should be left alone

[Spider Boardman]

The C (POSIX.1) remove() function is NOT just unlink() in drag.
It's something like this (in perl):

sub remove ($) {
if ( !-l $_[0] && -d _ ) {
rmdir $_[0];
}
else {
unlink $_[0];
}
}

In other words, it's rmdir() if its argument is a directory, and
unlink() otherwise.

-- 
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.http://www.ultranet.com/~spiderb
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89  F6 B2 C2 A0 1C AB 1F DC

Re: RFC 22 (v1) Builtin switch statement

[Damian Conway]

   > Does "goto odds" mean start evaluating all cases after the
   > "odds:" label? Meaning that the below is equivalent to the above?
   > I think this is what the original poster was asking; if not, I'd
   > like to ask it!

That's exactly what it means.

   > 
   >  switch ($val) {
   > case 3  { print "three"; goto morecases }
   > case 4  { print "three"; goto morecases }
   > 
   >  morecases:
   >  case __%2!=0{ print "that's odd" }
   >  case __%2==0{ print "that's even" }
   > }

Damian 

Re: RFC 22 (v1) Builtin switch statement

[Glenn Linderman]

Damian Conway wrote:

>> Could a way be found to control the flow so that the next case (not always
>> the one next in the order of the statment) could be executed? For example
>> you have cases 1-10. You want all odd cases to also execute case 9 and the
>> even cases to also execute case 10. So in case 3 you would say something
>> like: pergo(9);
>
> Not necessary.
>
> switch ($val) {
> case 3  { print "three"; goto odds }
> case 4  { print "three"; goto evens }
>
>   odds: case __%2!=0{ print "that's odd" }
>  evens: case __%2==0{ print "that's even" }
> }

Does "goto odds" mean start evaluating all cases after the "odds:" label?  Meaning
that the below is equivalent to the above?  I think this is what the original
poster was asking; if not, I'd like to ask it!

 switch ($val) {
case 3  { print "three"; goto morecases }
case 4  { print "three"; goto morecases }

 morecases:
 case __%2!=0{ print "that's odd" }
 case __%2==0{ print "that's even" }
}
--
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 18 (v1) Immediate subroutines

[Dan Sugalski]

At 04:08 PM 8/4/00 -0400, Chaim Frenkel wrote:
>I've never used it, but PL/I' preprocessor and ASMG's preprocessor ,
>If I recall correctly, both worked this way. The text of the arguments
>and the actual input stream were available for manipulation. The
>return value (or emitted strings) were used as input to the parser.
>
>This would be quite close to a BEGIN time subroutine with the rest
>of the input stream supplied as a FILEHANDLE. This could allow those
>folks who want to turn perl into a different language, enough rope.

Yup. I misunderstood what he was talking about at first. Now I understand. 
I don't think this'll be much of a big deal over and above BEGIN. (How much 
of a pain that is is a separate issue)

> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> At 09:38 PM 8/4/00 +0200, Jean-Louis Leroy wrote:
> >> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >>
> >> > This does complicate the job of the parser/lexer rather
> >> > considerably.
> >>
> >> Why? Isn't it 'just' a matter or making the lexer read from a
> >> hot-redirectable input stream?
>
>DS> If it is, then it's not that big a deal, nor would it be all that useful.
>DS> Wiht substitutions it's more than that, and if we're going to do this, we
>DS> ought *not* essentially duplicate C's #define stuff. Macros mean the 
>parser
>DS> needs to keep source around, possibly snapshot its current state and then
>DS> do an on-the-fly rework of the input buffers. (Maybe. Depends on what 
>this
>DS> does)
>
>DS> The cleverer the preprocessor, the more work the lexer/parser needs to 
>do.
>DS> Which is dandy but, as I said, if you're going to do it, do it once 
>and do
>DS> it with some force.
>
>
>
>
>
>--
>Chaim FrenkelNonlinear Knowledge, Inc.
>[EMAIL PROTECTED]   +1-718-236-0183


Dan

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

Re: Problems with perl6-rfc address??

[Nathan Wiger]

Ignore this, I'm an idiot. I thought perl6-rfc was totally automated.
Sorry.

-Nate

Nathan Wiger wrote:
> 
> Sorry for the broadcast, but anyone else having problems with perl6-rfc?
> I sent two separate RFC's in from separate mail servers but haven't seen
> anything happen with them. It's been a good hour, too.
> 
> Thanks,
> Nate

Re: Proposed sublist: flowcontrol

[Chaim Frenkel]

> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:

UG> dispatch- discuss support of the multiple ways to control
UG>   dispatching of perl ops (event loops, threads,
UG>   co-routines, etc.)

UG> the dispatch list should eventually split off lists that focus on the semantic
UG> details of each technology. the final RFCs from those lists will be
UG> coordinated and hopefully presented as a unified design of the control
UG> flow of Perl.

Why is this not -internals?

-language-* should only be interested in the user's view of the world.
How -internals-* takes care of the dirty details, is a seperate issue.

I.e. What, not how.


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

Re: PDL-P: indexing

[Joshua N Pritikin]

On Fri, Aug 04, 2000 at 10:02:05AM -1000, [EMAIL PROTECTED] wrote:
> On Fri, 4 Aug 2000, Tuomas Lukka wrote:
> > On 4 Aug 2000, Ariel Scolnicov wrote:
> > Well, first of all, 
> > 
> > 10:100, 30:200
> > 
> > is not the same: in Perl it comes out as
> > 
> > 10..100, 30..200
> > 
> > 10, 11, ... , 100, 30, 31, .., 200
> 
> Additionally, generically it would not necessarily have to be a range of
> integers. The range could be specified as floating point if we are
> specifying a slice in physical coordinates.

Also, you can specify a non-default step size:

  @pdl(1:9:2, 1:9:2);  # (1,1) (3,1) (5,1) (7,1) (9,1) (1,3) (3,3) ...

Although I'm not sure how frequently custom step sizes are used in PDL
code...

-- 
May the best description of competition prevail.
  (via, but not speaking for Deutsche Bank)

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

[Tuomas Lukka]

> > Well, first of all, 
> > 
> > 10:100, 30:200
> > 
> > is not the same: in Perl it comes out as
> > 
> > 10..100, 30..200
> > 
> > 10, 11, ... , 100, 30, 31, .., 200
> > 
> 
> Additionally, generically it would not necessarily have to be a range of
> integers. The range could be specified as floating point if we are
> specifying a slice in physical coordinates.

If someone is going to write the RFC, remember also the third arg: 

a:b:c

is the sequence

a, a+c, a+2*c, ... a+n*c

where n is the largest integer such that a+n*c <= b (important that it's
greater than or equal!).

a:b

is always the same as

a:b:1

Also, the usual Perl index tricks should work (these should be specified
in the span so that the code interpreting the span can use its knowledge):

:   # all the things on this dimension: full span
5:-1# 5..last
5:-1:2  # Every second item, up to the last or second last
-1:7:3  # Start with last item, then fourth last, etc. until 7.

Note that there need to be different contexts: if floats or negative
integers are allowed then -1 cannot stand for the end but it has to stand
for -1.

Tuomas

Problems with perl6-rfc address??

[Nathan Wiger]

Sorry for the broadcast, but anyone else having problems with perl6-rfc?
I sent two separate RFC's in from separate mail servers but haven't seen
anything happen with them. It's been a good hour, too.

Thanks,
Nate

Re: RFC 18 (v1) Immediate subroutines

[Chaim Frenkel]

I've never used it, but PL/I' preprocessor and ASMG's preprocessor ,
If I recall correctly, both worked this way. The text of the arguments
and the actual input stream were available for manipulation. The
return value (or emitted strings) were used as input to the parser.

This would be quite close to a BEGIN time subroutine with the rest
of the input stream supplied as a FILEHANDLE. This could allow those
folks who want to turn perl into a different language, enough rope.



> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

DS> At 09:38 PM 8/4/00 +0200, Jean-Louis Leroy wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>> 
>> > This does complicate the job of the parser/lexer rather
>> > considerably.
>> 
>> Why? Isn't it 'just' a matter or making the lexer read from a
>> hot-redirectable input stream?

DS> If it is, then it's not that big a deal, nor would it be all that useful. 
DS> Wiht substitutions it's more than that, and if we're going to do this, we 
DS> ought *not* essentially duplicate C's #define stuff. Macros mean the parser 
DS> needs to keep source around, possibly snapshot its current state and then 
DS> do an on-the-fly rework of the input buffers. (Maybe. Depends on what this 
DS> does)

DS> The cleverer the preprocessor, the more work the lexer/parser needs to do. 
DS> Which is dandy but, as I said, if you're going to do it, do it once and do 
DS> it with some force.





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

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

[Tim Jenness]

On Fri, 4 Aug 2000, Tuomas Lukka wrote:

> On 4 Aug 2000, Ariel Scolnicov wrote:
> 
> Well, first of all, 
> 
>   10:100, 30:200
> 
> is not the same: in Perl it comes out as
> 
>   10..100, 30..200
> 
>   10, 11, ... , 100, 30, 31, .., 200
> 

Additionally, generically it would not necessarily have to be a range of
integers. The range could be specified as floating point if we are
specifying a slice in physical coordinates.

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: Language RFC Summary 4th August 2000

[Steve Simmons]

On Fri, Aug 04, 2000 at 03:37:08PM +1000, [EMAIL PROTECTED] wrote:
> 
> 1. put their hands up to write the "up for grabs" RFCs
> 2. work towards getting the "requested/promised" and "draft" RFCs up to
>the point where they can be submitted to the librarian.
> 3. let me know if you think an RFC needs a sublist to discuss it

> Drafts, etc
> ---
> Removing/fixing $[line noise here] variables
>   Corwin Brust <[EMAIL PROTECTED]>

That one is now out as RFC 16.  An updated version will be out to you
tonight, the `up-to-the-instant' version is available at
  http://http://www.nnaf.net/~scs/Perl6/RFC17.html
but it's literally changing minute by minute.  A new version will be
submitted to the librarian once I've integrated the current comments.

My hand is also in the air for module versioning, I should have it banged
out tonight as well.

$DEITY, how does Damien do it?

RE: RFC 29 (v1) unlink() should be left alone

[Fisher Mark]

>   5. Other operating systems/ file systems have, or could have
>  hypothetically, the same operation.  I.e. just because NTFS
>  doesn't have multiple links now (or does it?) doesn't mean
>  it won't in the future.

NTFS does support hard links right out of the box, although the first
versions didn't come with tools for setting up the links (except for the
POSIX subsystem tools).  I don't know what tools NT comes with now for
making hard links, actually, as  I use MKS Toolkit on NT which provides
ln(1) among its many Unix-compatible commands.
===
Mark Leighton Fisher[EMAIL PROTECTED]
Thomson Consumer ElectronicsIndianapolis IN
"Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

[Tuomas Lukka]

On 4 Aug 2000, Ariel Scolnicov wrote:

> Karl Glazebrook <[EMAIL PROTECTED]> writes:
> 
> > OK I will raise to the bait
> > 
> > I think it's a bit unfair to say that PDL people have failed to 'bite',
> > there was quite a bit of discussion on our list after your post. Also
> > some concern about how much of perl6 is vapourware.
> > 
> > I am game to take part in discussions. 
> > 
> > It has always been apparent to me that Numerical Python is better integrated
> > than PDL. Some language changes in core python WERE made to accomodate it,
> > also Python had less syntax clutter to get around.
> > 
> > I definitely support embedding many of the key PDL ideas into the language
> > - they key one is a much easier syntax for a multi-dim slice. We are currently
> > driven to
> > 
> > $a->slice("10:100,30:200");
> > 
> > compared to IDL AND NumPy: a[10:100,30:200]
> 
> Perl doesn't have multi-dimensional arrays (yet, I hope), but it
> *does* spell `:' as "..", even today.  @x[7..9] is a 3-element list,
> which I don't see as any different from @x[7:9].  Does the slice share 
> the elements of @a in your example?

Well, first of all, 

10:100, 30:200

is not the same: in Perl it comes out as

10..100, 30..200

10, 11, ... , 100, 30, 31, .., 200

whereas what we want is

Span(10, 100), Span(30, 200)

where Span is some suitable object telling that this span is a parameter.
There are also other syntaxes for slice we would like to have but these
can probably be kludged.
 
> > I'd propose simply building the a:b syntax into the core of Perl6. It's
> > convenient and almost standard.
> 
> Put the dots sideways, and it's Perl.

No it's not. Perl concatenates the two lists, which is not what we want.

> Regarding multi-dimensional arrays, the PDL porters are undoubtable
> champions; what is required?

Well, the PDL distro is our answer to that ;) ;)

Tuomas

RE: RFC 22 (v1) Builtin switch statement

[Lipscomb, Al]

Not a bad solution, at least for the example I put forth. I like the ability
to have the specific as well as the general in the case statement ('2' and
'__%2 != 0'). Thanks.


   > Could a way be found to control the flow so that the next case (not
always
   > the one next in the order of the statment) could be executed? For
example
   > you have cases 1-10. You want all odd cases to also execute case 9 and
the
   > even cases to also execute case 10. So in case 3 you would say
something
   > like: pergo(9); 

Not necessary.

switch ($val) {
case 3  { print "three"; goto odds }
case 4  { print "three"; goto evens }

  odds: case __%2!=0{ print "that's odd" }
 evens: case __%2==0{ print "that's even" }
}

Or for those who hate pasta:

sub odds  { print "that's odd" }
sub evens { print "that's even" }

switch ($val) {
case 3  { print "three"; odds }
case 4  { print "three"; evens }

case __%2!=0{ odds }
case __%2==0{ evens }
}


Damian

RE: RFC 29 (v1) unlink() should be left alone

[Myers, Dirk]

Ariel Scolnicov:

> It so happens that remove() is standard C (library) for removing a
> file.  It therefore makes sense to use *that* name, if any change is
> made.

IMHO, it's poorly named (though using remove() at least has the virtue of
not conflicting with/overloading the existing "delete").

> Regarding the existence of multiple links -- That is probably an
> implementation detail of the platform on which the library is 
> running.  Since all remove() does is break the association between the 
> name and the contents, links are a red herring.

No, remove() is a red herring, because it's only guaranteed to unlink() the
file, not actually remove it :).  This is *why* I think it's poorly named
(on at least some platforms).  If you're going to provide a way to remove()
(or delete(), or nuke(), or abolish(), or whatever word it goes by) a file,
the file should either go away or you should get an error.  If all the call
does is break a link... you're unlink()'ing, not remove()'ing, and using
unlink() to be explicit about what's going on is a Good Thing.

If a remove() is added, it should (IMHO) seek-and-destroy.  No, that's not
what the existing C function does... but if we're requiring people to be
aware of C functions, why not just stick with unlink()?  (At least if there
aren't hordes of people out there who use perl who are aware of the standard
C libraries but who aren't familiar with standard Unix syscalls.  I suspect
this is the case, but may be wrong.)

Overall, though, my main objections to changing unlink() are that (a) a
suitable replacement isn't obvious (to me, anyway ;) ) and (b) I don't see
any clear point at which to stop renaming things -- if we change unlink(),
shouldn't we also change chmod() and chown()?  Should we change STDIN to
INPUT and STDOUT to OUTPUT  and STDERR to ERROR ?

Although this is probably way more discussion than the subject warrants, so
I'll shut up now.

Dirk Myers

Different points of view, a little perspective.

[Michael Mathews]

Snippet from O'Reilly's upcoming fictional novel, the first in a new series
written for its loyal audience of CS professionals:
"Young Perl had definitely reached that 'awkward stage' in life -- not quite
a fully-accepted adult, but definitely not a child anymore. Her parents,
/they/ loved her, she couldn't deny that. They always said they wanted what
was 'best for her', but what did /they/ know?! Perl looked around the party,
seeing all the other kids who seemed to have it all, money, friends -- boy,
they had it /easy/, she thought! Not her. She was just a quiet, but talented
daughter from a blue-collar family --someone her teachers called, kindly,
'hard-working'. Anything but galamorous. She suddenly became intensely
self-aware. 'Just once!', she wondered, 'why can't /I/ be popular?'."

Quoted from David Rook's "A Language Collector Comments On: Java, Perl &
Python"
"Perl has been rumored to stand for Pathologically Eclectic Rubbish Lister.
I agree. Even after years of working with it, I don't feel comfortable
writing Perl without the most current Camel Book [Programming Perl by Wall &
Schwartz, O'Reilly & Assoc] by my side. For whatever reason, I just can't
get comfortable. It's a little like C, but not enough. For instance, in Perl
you can write "exit if $x ne 'continue'" or you can write a more C-like if
($x ne 'continue') {exit} Unfortunately, you can use both styles in the same
program, resulting in confused readers. Perl has different operators for
string comparison and number comparison, even though it will (invisibly)
convert a string to a number. If I only wrote Perl, this might not be a
problem, but I tend to use a number of different tools, and switching into
Perl mode continues to be a difficult transition. Fortunately, I've found an
able replacement for those system administration tasks I previously would
have written in Perl. So, without throwing more stones at Perl, lets go on
to Python..."

Quoted from /The Perl Journal/
"The true measure of a language's merit is not how many people use it, but
whether they like it. People like Perl."

Re: RFC 28 (v1) Perl should stay Perl.

[Buddha Buck]

At 02:17 PM 8/4/00 -0500, Jonathan Scott Duff wrote:

>I'm with Chaim on this one.  One of the things I *love* about perl is
>that it doesn't constrain me to a particular paradigm and moreover it
>almost naturally supports other paradigms (like functional
>programming).  I'm always touting this aspect of Perl and often people
>from other backgrounds (scheme, lisp, Java, etc.) are surprised and
>delighted when perl lowers the barrier to their entry and
>understanding.
>
>That said, if perl starts looking more like lisp than perl, I'll be
>here to yell bloody murder! along with Simon  :-)

I think what is likely to happen is that some people's perl will look very 
OO, some people's perl will look very functional, and others will look like 
"classic perl".  I see no problem with that.

Perl has a history of taking the best from all over the place.  Taking the 
best ideas of functional programming, and the best ideas of OO programming, 
and allowing you to use what works for you is good.

I'd like a language where I can write object-oriented quick-and-dirty 
scripts with a functional flair.

>-Scott
>--
>Jonathan Scott Duff
>[EMAIL PROTECTED]

Re: RFC 22 (v1) Builtin switch statement

[Jonathan Scott Duff]

On Sat, Aug 05, 2000 at 05:09:28AM +1000, Damian Conway wrote:
> Not necessary.
> 
>   switch ($val) {
>   case 3  { print "three"; goto odds }
>   case 4  { print "three"; goto evens }

And "goto" could be spelt "next" too?  That would make sense to me,
but the semantics of "last odds" or "redo odds" escape me.  Perhaps
"last odds" would me "evaluate the block labeled by odds, then exit
the switch" and "redo odds" would me "re-evaluate this case, then jump
to the block labelled odds".

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

[Karl Glazebrook]

Also on the issue of loop unrolling and efficient looping.

PDL has what we call 'threading'.

This allows a C-level function to specify the dimensionality of
the arguments it accepts. For example a function addtoline() which
hyptheticaly adds a constant to a row vector might
have a 'signature'

a(n); b(); [o]c(n);

So a(n) is a 1D input, b() is a scalar (0D) which addtoline might add
to all the elements of a(n) and c(n) is the output 1D.

What is really useful is that if you add extra dimensions they
get looped over automatically, at the C-level so really fast.

e.g. a(100,10), b(10), c(100,10)

- adds to all 10 rows of a.

ALSO they way it is implemented is the array pointers are calculated
by C macros in such a way as to support transpositions and slicing
with zero memory overhead. Thus if I want to add one to every *column*
of a, in a slice:

addtoline $a->xchg(0,1)->slice("10:20,20:40"), 10, $c

here xchg creates a virtual transposition of the first two dims, and slice
creates a virtual slice. This is all done by storing extra info in the
$a object.

I think these ideas would be of use in any discussion of perl6 numerical
efficiency - there are other ways I guess. The core idea is to try and stay
in compiled loops.

The other advantage of this 'threading' is that it then automatically parallelizes
the problem - we even have an experimental PDL implementation which can use
multiple CPUs to do 'threads'.

One problem we are continually faced in PDL is we do all this at the C-level
- but then we run into problems where if we have pure-perl PDL functions they
can't do these tricks. 

Another problem though is while one can usually write many complicated multi-dim
problems with threading tricks, and avoid loops, it is sometimes a bit taxing
on the brain! One often wishes one could just write it as C/fortran style
loops and have the language figure out how to do the loops efficiently.

Anyway some integration of concepts for handling large numerical computation
into the core would definitely be a good thing.

Karl Glazebrook

Re: Language RFC Summary 4th August 2000

[Damian Conway]

   > What I'm planning to RFC is a simple format() built-in (probably
   > in a pragma) very similar to the form() subroutine described in:

http://www.csse.monash.edu.au/~damian/TPC/2000/Autoformat/paper.html

Damian

Re: RFC 28 (v1) Perl should stay Perl.

[Jonathan Scott Duff]

> > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> 
> PRL> =item Functional Programming
> 
> PRL> Just because Perl has a C operator, this doesn't make it a
> PRL> functional programming language. Perl has always been squarely
> PRL> procedural, and so things like C and C and other cookery
> PRL> terms are somewhat out of place; they can be far more easily and
> PRL> appropriately implemented as extension modules I. By all
> PRL> means, let's generalise the problem, and make it easier to define your 
> PRL> own syntax, but let's not add the entirety of LISP and ML to the core.
> PRL> The CS types may love it, but I'm a programmer and I don't.

On Fri, Aug 04, 2000 at 02:50:39PM -0400, Chaim Frenkel wrote:
> I'm not quite buying into this.

I'm with Chaim on this one.  One of the things I *love* about perl is
that it doesn't constrain me to a particular paradigm and moreover it
almost naturally supports other paradigms (like functional
programming).  I'm always touting this aspect of Perl and often people
from other backgrounds (scheme, lisp, Java, etc.) are surprised and
delighted when perl lowers the barrier to their entry and
understanding.

That said, if perl starts looking more like lisp than perl, I'll be
here to yell bloody murder! along with Simon  :-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

RE: RFC 22 (v1) Builtin switch statement

[Damian Conway]

   > Could a way be found to control the flow so that the next case (not always
   > the one next in the order of the statment) could be executed? For example
   > you have cases 1-10. You want all odd cases to also execute case 9 and the
   > even cases to also execute case 10. So in case 3 you would say something
   > like: pergo(9); 

Not necessary.

switch ($val) {
case 3  { print "three"; goto odds }
case 4  { print "three"; goto evens }

  odds: case __%2!=0{ print "that's odd" }
 evens: case __%2==0{ print "that's even" }
}

Or for those who hate pasta:

sub odds  { print "that's odd" }
sub evens { print "that's even" }

switch ($val) {
case 3  { print "three"; odds }
case 4  { print "three"; evens }

case __%2!=0{ odds }
case __%2==0{ evens }
}


Damian

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

[Ariel Scolnicov]

Karl Glazebrook <[EMAIL PROTECTED]> writes:

> OK I will raise to the bait
> 
> I think it's a bit unfair to say that PDL people have failed to 'bite',
> there was quite a bit of discussion on our list after your post. Also
> some concern about how much of perl6 is vapourware.
> 
> I am game to take part in discussions. 
> 
> It has always been apparent to me that Numerical Python is better integrated
> than PDL. Some language changes in core python WERE made to accomodate it,
> also Python had less syntax clutter to get around.
> 
> I definitely support embedding many of the key PDL ideas into the language
> - they key one is a much easier syntax for a multi-dim slice. We are currently
> driven to
> 
> $a->slice("10:100,30:200");
> 
> compared to IDL AND NumPy: a[10:100,30:200]

Perl doesn't have multi-dimensional arrays (yet, I hope), but it
*does* spell `:' as "..", even today.  @x[7..9] is a 3-element list,
which I don't see as any different from @x[7:9].  Does the slice share 
the elements of @a in your example?

> I'd propose simply building the a:b syntax into the core of Perl6. It's
> convenient and almost standard.

Put the dots sideways, and it's Perl.

Regarding multi-dimensional arrays, the PDL porters are undoubtable
champions; what is required?

[...]

-- 
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: Language RFC Summary 4th August 2000

[Damian Conway]

   > >> It definitely is, since formats do things that can't be done in modules.
   > >
   > >Such as???
   > 
   > Well, the easy binding of variables for later use. When one declares a 
   > format, variables in it are saved for later use without needing refs. 
   > Formats are sort of like a quote where the variables are referenced rather 
   > than interpolated when defined, with the values pulled (and possibly 
   > altered) when the quote is used.

What I'm planning to RFC is a simple format() built-in (probably in a pragma)
very similar to the form() subroutine described in:


I would envisage that the correct way to set up the kinds of
referenced-not-interpolated templates is by creating a subroutine or closure:

sub format1 {
format "> >>> [",
   $bullet,
   $text;
}

which you can then interpolate at need:

print format1;

Alternatively, one could make the format nicely parametric using higher-order
functions:

my $format2 = 
format "> >>> [",
  __, __;

and later:

print $format2->($magic_bullet, $special_text);

or partially fill it in:

my $format3 = $format2->($magic_bullet);

I'll get to work on the format RFC as soon as possible, so that you can
see what I mean.

   
   > :) I promised Kirrily that I'd race you in the RFC count...

That's hardly fair on you: I can just pull any crazy idea out of my head
whereas *you* have to be able to implement yours! :-)

Damian

Re: Language RFC Summary 4th August 2000

[Dan Sugalski]

At 04:00 AM 8/5/00 +1000, Damian Conway wrote:
>> It definitely is, since formats do things that can't be done in modules.
>
>Such as???

Well, the easy binding of variables for later use. When one declares a 
format, variables in it are saved for later use without needing refs. 
Formats are sort of like a quote where the variables are referenced rather 
than interpolated when defined, with the values pulled (and possibly 
altered) when the quote is used.

>> If they yank formats out (which is just dandy by me) that means
>> that some means of providing format's functionality needs has to
>> be designed in.
>
>I'm working on it.

:) I promised Kirrily that I'd race you in the RFC count...

Dan

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

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

[Ted Ashton]

Thus it was written in the epistle of Damian Conway,
> 
> I have an RFC coming on that :-)

I think Skud asked the wrong questiong :-).  Would you please submit a
comprehensive of the topics on which you are not about to produce an RFC.  That
will allow others to focus their work.  Thank you very much.

Ted "really glad we have DC on our side--
 he'd be downright dangerous elsewhere :-)" Ashton
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
There are three kinds of lies: lies, damned lies, and statistics.
-- Disraeli, Benjamin
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 29 (v1) unlink() should be left alone

[Ariel Scolnicov]

Nathan Wiger <[EMAIL PROTECTED]> writes:

> > I say this as a Unix weenie, albeit a Unix *user* rather than a Unix
> > *programmer*.  I'm quite used to navigating the Unix filesystem but,
> > having never braved Unix systems programming, had no conceptual link
> > between deleting/"rm"ing files, and the term "unlink".  It tooks me
> > quite a bit of camel-petting to find the right function, when I first
> > needed it.
> 
> >From a user level, it might seem odd ("Where's rm?"). However, there is
> one key distinction here: A Perl program runs file operations at a
> system level. It needs to be able to handle everything the system can.
> 
> I am open to the possiblity of *adding* a remove() command if it had a
> different fundamental ability from unlink(). For example, one could make
> remove() remove *all* the links for a file, whereas unlink() only
> removes one.

It so happens that remove() is standard C (library) for removing a
file.  It therefore makes sense to use *that* name, if any change is
made.

Regarding the existence of multiple links -- That is probably an
implementation detail of the platform on which the library is
running.  Since all remove() does is break the association between the 
name and the contents, links are a red herring.

[...]


-- 
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 22 (v1) Builtin switch statement

[Lipscomb, Al]

Could a way be found to control the flow so that the next case (not always
the one next in the order of the statment) could be executed? For example
you have cases 1-10. You want all odd cases to also execute case 9 and the
even cases to also execute case 10. So in case 3 you would say something
like: pergo(9); 

-Original Message-
From: Ted Ashton [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 04, 2000 2:29 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Graham Barr
Subject: Re: RFC 22 (v1) Builtin switch statement


Thus it was written in the epistle of Damian Conway,
> 
> But a switch is not a loop.
> Within a loop the logic is:
> 
>   next -> try next case
>   last -> this was the last case

As it has already caused a little confusion, could we go with another word
instead of next?  'fallthrough' seems a bit much to type.  How about
'proceed',
'fall', 'exinde', 'porro', or (my favorite at the moment) 'pergo' ;-).

>> this would mean that fallthrough would be the default and the user
>> would need a last; to break out;
> 
> Long and bitter experience indicates that fallthrough is a poor default
> (but a good *option*).

Righto.  Well said,
Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==

I think that there is a moral to this story, namely that it is more
important to have beauty in one's equations that to have them fit
experiment. . . .  It seems that if one is working from the point of view of
getting beauty in one's equations, and if one has really a sound insight,
one is on a sure line of progress.
-- Dirac, Paul Adrien Maurice (1902-
)
  ==

 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 28 (v1) Perl should stay Perl.

[Chaim Frenkel]

I'm not quite buying into this.

There are some things that are just easier with this style of thinking.

Its a higher level construct. Akin to telling your interior decorator
that you'd like the furniture to match the wallpaper. You've left
out all the details but the decorator can easily see what you're talking
about. 

So calling, adding a little bit of Prolog, is hard to call anti-perl.

Another way of looking at it, is why have everybody and his dog write
the code when perl can get it right.

I just prefer to avoid writing loops. It just adds to the likelyhood
of bugs. using map/grep, and family would just reduce the incidence.

And reduce (and perhaps some of the more interesting APL operators may
be worthwhile. Just as a method of avoiding hand coding loops.)

Why bother having hashes? Isn't easily implemented in a Module?

I would respectfully suggest that you fine tune the algorithm that
would help decide how to decide where to file items

fundemental built-in (perl, mini/micor/nano-perl)
understood by perl, and loaded on demand
shipped with perl
CPAN
or
not now, some other time

get out of here and never come back.



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

PRL> =item Functional Programming

PRL> Just because Perl has a C operator, this doesn't make it a
PRL> functional programming language. Perl has always been squarely
PRL> procedural, and so things like C and C and other cookery
PRL> terms are somewhat out of place; they can be far more easily and
PRL> appropriately implemented as extension modules I. By all
PRL> means, let's generalise the problem, and make it easier to define your 
PRL> own syntax, but let's not add the entirety of LISP and ML to the core.
PRL> The CS types may love it, but I'm a programmer and I don't.

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

Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]

[Karl Glazebrook]

OK I will raise to the bait

I think it's a bit unfair to say that PDL people have failed to 'bite',
there was quite a bit of discussion on our list after your post. Also
some concern about how much of perl6 is vapourware.

I am game to take part in discussions. 

It has always been apparent to me that Numerical Python is better integrated
than PDL. Some language changes in core python WERE made to accomodate it,
also Python had less syntax clutter to get around.

I definitely support embedding many of the key PDL ideas into the language
- they key one is a much easier syntax for a multi-dim slice. We are currently
driven to

$a->slice("10:100,30:200");

compared to IDL AND NumPy: a[10:100,30:200]

I'd propose simply building the a:b syntax into the core of Perl6. It's
convenient and almost standard.

perl6 should provide simple arrays, but they should be allowed to be
replaced with objects with no change of syntax. So

@a[10:100,30:200];

Would work whether @a was a perl list of lists or a PDL compact array.

So would @a * @b

Loop unrolling sounds really good, their should be hooks for objects to
provide their own implementation. Proper overloading and ability to 
overload by arg type are required, i.e.

sub myfunc{ float x, complex y }
sub myfunc{ float x, float y }


Their should also be hooks for slices, for example if one is implementing
a complex objects (e.g. representing a map) - one might want a slice in
physical units instead of array indices.

I'd even propose getting rid of @a for arrays and $a for scalars and just
making the "a". I've never really liked that feature of perl - I am sure
some users agree and some disagree - might be worth taking a straw poll.
In this age where everything may (or may not) be an object are $ and @ really
required? There are too many objects types and not enough funny symbols..
even with Unicode.

Karl Glazebrook


Jeremy Howard wrote:
> 
> > > BTW, I'd like to see a more lightweight currying mechanism too. The
> > > challenge is to find a 'perlish' but not heavyweight approach...
> >
> > Ah, good.  I assume that having established the challenge, you'll be
> > rising to it? :-)
> >
> Yes of course. But I want to first of all see the following RFCs from Damian
> he's promised:
> 
> > * Built-ins: min() and max() functions and acceptors
> >
> > * Built-ins: reduce() function
> >
> > * Data structures: Semi-finite (lazy) lists
> >
> > * Subroutines: higher order functions
> >
> > * Subroutines: lazy evaluation of argument lists
> >
> > * Superpositions: vector operations via superpositions
> 
> Damian is likely to write these in a way that is nicely integrated together,
> based on past experience. What I'd then like to do is to see how these fit
> together to fill in the stuff I mentioned earlier today:
> 
> - Matrix ops
> - Support for lazy evaluation
> - Compile time expression unrolling (e.g. so that $a = sum(@b*@c+@d) does
> just one loop and no memory copy, as would occur with expression templates
> in C++)
> - Ability to specify infinite lists (e.g. like in Haskell)
> - Generic programming (iterators, algorithms, etc, eg. like in the STL)
> 
> 
> I think the way I'd like to do this is to try and implement a couple of
> interesting bits of code that I've found are good tests of numerical
> programming environments. Stuff that just looks beautiful in Mathematica
> (which supports functional, rule-based, and procedural programming), but is
> full of loops and control structures in most languages. That way any bits
> that are missing will be pretty obvious (at least bits that matter to me!)
> 
> I've tried to get input from PDL porters by cross-posting a couple of times,
> but haven't got much of a bite yet. I'm nervous about finding that we either
> reinvent the wheel, or break useful stuff that they've done... Are there any
> PDL gurus here who are interested in getting involved in some of these
> perl6-language issues?

Re: RFC 16 (v1) Keep default Perl free of constraints su

[Jonathan Scott Duff]

On Fri, Aug 04, 2000 at 11:37:30AM -0700, Peter Scott wrote:
> It would not be "you need to rebuild your perl", but "the administrator of 
> this site does not allow unstrict programming by default."

The original poster said "a compile-time option to be decided by the
administrator of each site".  I (and Johan) took that to mean "decided
when perl was compiled".

Letting administrators set a certain strictness level on *every*
program run sounds like we should make perl always read /etc/perlrc if
it exists.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

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

[Damian Conway]

   > From [EMAIL PROTECTED]  Sat Aug 
 5 04:36:31 2000
   > Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8])
   >by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id EAA20410
   >for <[EMAIL PROTECTED]>; Sat, 5 Aug 2000 04:36:31 +1000 (EST)
   > Received: from tmtowtdi.perl.org ([209.85.3.25])
   >  by vaxh.cc.monash.edu.au (PMDF V5.2-31 #29714)
   >  with SMTP id <[EMAIL PROTECTED]> for
   >  [EMAIL PROTECTED]; Sat, 5 Aug 2000 04:36:28 +1000
   > Received: (qmail 11194 invoked by uid 508); Fri, 04 Aug 2000 18:36:24 +
   > Received: (qmail 11182 invoked from network); Fri, 04 Aug 2000 18:36:23 +
   > Date: Fri, 04 Aug 2000 21:35:55 +0300
   > From: Ariel Scolnicov <[EMAIL PROTECTED]>
   > Subject: Re: RFC 24 (v1) Semi-finite (lazy) lists
   > In-reply-to: Perl6 RFC Librarian's message of "4 Aug 2000 15:00:16 -"
   > Sender: [EMAIL PROTECTED]
   > To: [EMAIL PROTECTED]
   > Message-id: <[EMAIL PROTECTED]>
   > Organization: Compugen, Ltd.
   > MIME-version: 1.0
   > Content-type: text/plain; charset=us-ascii
   > Content-transfer-encoding: 7BIT
   > Precedence: bulk
   > Delivered-to: mailing list [EMAIL PROTECTED]
   > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
   > User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/20.4 (Emerald)
   > Lines: 57
   > References: <[EMAIL PROTECTED]>
   > X-Authentication-warning: selena.compugen.co.il: ariels set sender to
   >  [EMAIL PROTECTED] using -f
   > List-Post: 
   > List-Subscribe: 
   > List-Unsubscribe: 
   > List-Help: 
   > 
   > Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
   > 
   > [...]
   > 
   > > This RFC proposes that the right operand of a C<..> operator
   > > may be omitted in a list context, producing a lazily evaluated
   > > semi-finite list. It is further proposed that operations on
   > > such lists also be carried out lazily.
   > 
   > This would be nice, but I think should be folded into something more
   > general, like tieable first-class iterators.  I'm still trying to pull
   > my thoughts together on this one, but lazy lists could be a special
   > case of iterators.

I have an RFC coming on that :-)

Damian

Re: Proposed sublist: flowcontrol

[Damian Conway]

   > > i think damian's influence on perl6
   > > is our real triple top secret weapon. 
   > 
   > This realization has hit me on the head really hard.
   > My prediction is that Perl6 will have to be dual-credited.

I doubt it: Lucifer doesn't get a by-line on the Bible.

There's only one Larry. 
We're just fortunate that he's a sufficiently large value of one.

Damian

Re: New Group proposed: subs (was Re: named parameters)

[Glenn Linderman]

Andy Wardley wrote:

> What about '$me'?   It ties in nicely with 'my' (although perhaps for the
> wrong reasons), it's half as much typing as 'self' or 'this' and we get
> to annoy both sets of religious zealots at once.  :-)=

Yes, absolutely.  Now what good meanings could we attribute to $myself and $I
?

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