Tuomas Lukka wrote:
> > Do we really need PDL objects in perl 6? How about we investigate building
> > compact arrays into the language? We're already talking about how we can add
> > typing to the language--I would have thought that if these semantics make it
> > in, we could look to optimise ho
"Jeremy Howard" <[EMAIL PROTECTED]> writes:
> > Oops, a correction. [..] should mean 'the set of all integers'. _Not_ the
> > univeral set. So my code snippet should be:
> > @i = [..];# @i contains the integers
> > $s = sum (grep 0<__<=100 @i);
> > print "The sum of the 1st 100 integers
Then a mechanism for uplevel manipulation of variables should be used.
uplevel 0, $Perl:Warnings=1;# Hit everyone
uplevel -1, $Perl:Warnings=0; # Hit my wrapper
(I think something better was proposed, but I don't recall what it was.)
> "DS" == Dan Sugalski <[EMAIL PR
At 11:40 AM 8/5/00 +, Nick Ing-Simmons wrote:
>Damian Conway <[EMAIL PROTECTED]> writes:
> > > It definitely is, since formats do things that can't be done in
> modules.
> >
> >Such as???
>
>Quite.
>
>Even in perl5 an XS module can do _anything at all_.
It can't access data the lexer's alr
At 12:58 PM 8/5/00 -0700, Peter Scott wrote:
>Another one for my wish list: deep copying support built in. A devil
>inside me thinks this should be a new assignment
>operator. Damian? Sounds like this is up your alley. I want to do a
>sanity check before taking up RFC space.
Regardless of
At 01:21 AM 8/6/00 -0400, Chaim Frenkel wrote:
>I think there are two problems. One is the naming convention, the
>second, the global effects.
>
>Why not split them. The names could be improved.
>
>And the global nature (of the name) abolished.
I'm not entirely sure that tossing the global nature
I think there are two problems. One is the naming convention, the
second, the global effects.
Why not split them. The names could be improved.
And the global nature (of the name) abolished.
So $^W becomes $Perl::Warnings and only has a local scope effect?
One would use whatever mechanism will
I thought the WG sublists creation was a recursive definition.
I can see a discussion with the chair(uplevel) for guidance, but the
working groups should be left to their own devices. They should only
be responsible to return their final document. Otherwise treat it
as a black box.
> "s" =
> "s" == skud <[EMAIL PROTECTED]> writes:
s> On Fri, Aug 04, 2000 at 10:13:59PM -, Perl6 RFC Librarian wrote:
>> =head1 IMPLEMENTATION
>>
>> Remove the file-globbing behavior of the angle brackets.
s> How about "Deprecate use of file globbing with angle brackets. Emit a
s> warning whe
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> I very much like Icon's failure model, but I was loathe to try and
DC> graft it wholesale onto Perl 6. Doing it properly would require a
DC> substantial rethink of the exception mechanism, flow control, the
DC> nature of scalars, undef,
Source filters, look at the _entire_ input stream. So unless the input
stream implements a perl parser, it is limited to a simple textual
replacement system.
A macro system, is _handed_ a portion of text, (and possibly the input
stream) and asked to return a blob of text to be further parsed.
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> On Sat, Aug 05, 2000 at 11:47:47PM +1000, Jeremy Howard wrote:
>> I feel that your RFC misses the inclusive nature of perl.
SC> Then I withdraw it. Perl should not stay Perl, fuck it. Call me when it's
SC> time to get coding.
I think y
i don't know if anyone (other than me) has subscribed to the new flow
list yet. my rfc on asynch I/O has been posted there. i feel i should
repost it to language but i am not going to yet. in any case if you are
interested in threads, event loops, safe signals, coroutines, and asynch
I/O and call
At 09:34 PM 8/5/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote:
> >>All functions that return time values (seconds since epoch) should use
> >>floating point numbers to return as much precision as the platform
> >>supports.
On Sat, Aug 05, 2000 at 09:14:49PM -, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Request For New Pragma: Shell
Pragmas have lower case names by convention, so this should be "use
shell".
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consult
I'm not sure it makes sense, I'd really like to get rid of the last
propogating out of a sub. (or a grep/map).
But if that doesn't fly, we do have Damian's new yield keyword
available to do it.
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> I think we need a general way of s
How about adding a new keyword, hmm, 'yield'. :-)
if ( grep yield $x==$_, (1,2,3) ) ...
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> Oh, the table thing. The switch statement is useful without learning the
>> complete table so I don't think complexity is a big problem. P
guard
protect
Hmm, 'guard' is just as long as 'local'.
> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> More words:
JSD>store() # put away for the duration of the scope
JSD>tuck() # Now I lay me down to sleep
JSD>hide()
Edwin Wiles wrote:
> Without them, the programmer must calculate the required length of the reads
> themselves.
Good point. I now want them, rather than being ambivalent.
> >[ 'bar' => 'i', 'baz' => 'i', 'count' => 'i' ]
>
> It is my understanding that "=>" is an indication of a link in a
This and other RFCs are available on the web at
http://dev.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: 5 Aug 2000
Version: 3
Mailing List: [EMAIL PROT
> Summary of manifesto: Global variables must be expunged.
>
> Replacing the old rotten global variables with new rotten global
> variables is not enough of an improvement.
Hurrah! http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'
I don't want to join the discussion in general, and I'm not on the
language list. So this is a one-shot manifesto.
I agree with the goal of RFC17:
Organization and Rationalization of Perl State Variables
but I think the implementation ideas are making a terrible mistake.
Specifically:
On Sun, 6 Aug 2000, Jeremy Howard wrote:
> > > > * Built-ins: min() and max() functions and acceptors
> > > >
> > > > * Built-ins: reduce() function
> > > >
> > > > * Subroutines: lazy evaluation of argument lists
> > > >
> > > > * Superpositions: vector operations via superpositions
> >
> > Co
Jeremy Howard wrote:
> New programmers should easily understand that:
> - $foo is the variable 'foo'
> - _foo is the placeholder 'foo'
> - $_ is the default variable
> - __ is the default placeholder.
> Then, when they see the same named placeholder appear twice in the same
> higher-order
> > > * Built-ins: min() and max() functions and acceptors
> > >
> > > * Built-ins: reduce() function
> > >
> > > * Subroutines: lazy evaluation of argument lists
> > >
> > > * Superpositions: vector operations via superpositions
>
> Couldn't see those either. Could you refer to the actual RFC #s,
> Oops, a correction. [..] should mean 'the set of all integers'. _Not_ the
> univeral set. So my code snippet should be:
> @i = [..];# @i contains the integers
> $s = sum (grep 0<__<=100 @i);
> print "The sum of the 1st 100 integers is: $s";
>
Oh dear, another correction! I meant, of co
> > Oops, a correction. [..] should mean 'the set of all integers'. _Not_
the
> > univeral set. So my code snippet should be:
> > @i = [..];# @i contains the integers
> > $s = sum (grep 0<__<=100 @i);
> > print "The sum of the 1st 100 integers is: $s";
> >
> > I still think it would be c
> It is proposed that Perl reserve the bareword C<__>
(underscore-underscore)
> as a "placeholder" for generating higher order functions more cleanly.
>
But what if I want to say:
@n = (0.2, 1, 3.5, 4);
@integersInN = grep __=abs(__) @n; # @intsInN is empty!
Instead I would need:
@integersI
Jeremy Howard wrote:
>
> > @u = [..];# @a contains the univeral set
> > works just fine, so I can then say:
> > @i = grep {$_=abs($_)} @u;# @i contains the integers
> > # See higher-order function and multi-way comparison RFCs
> > $s = sum (grep 0<__<=100 @i);
> > print "The sum
Jeremy Howard wrote:
> Make sure you read the interesting RFCs from Damian Conway on related
> issues:
>
> > * Built-ins: min() and max() functions and acceptors
> >
> > * Built-ins: reduce() function
Couldn't see these.
> >
> > * Data structures: Semi-finite (lazy) lists
> >
> > * Subroutines
> @u = [..];# @a contains the univeral set
> works just fine, so I can then say:
> @i = grep {$_=abs($_)} @u;# @i contains the integers
> # See higher-order function and multi-way comparison RFCs
> $s = sum (grep 0<__<=100 @i);
> print "The sum of the 1st 100 integers is: $s";
>
> 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.
>
OK, I've already requested that we allow omitting the left operan
Nathan Wiger <[EMAIL PROTECTED]> writes:
>> I have retained the title of "Lexical variables made default,"
>> because I still feel that that is the primary purpose of this change
>
>First off, I think this is a great idea in principle. However, I don't
>think it goes nearly far enough in the imp
John Porter <[EMAIL PROTECTED]> writes:
>Michael Fowler <[EMAIL PROTECTED]>:
>>
>> use typing; # place your fingers on the home row..
>>
>> my integer $quux = 4;
>
>I believe that would have to be
>
> integer my $quux = 4;
>
>at least in perl5...
Well Larry has been using
my D
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
> On Sun, Aug 06, 2000 at 12:41:50AM +0300, Ariel Scolnicov wrote:
[...]
> > Have you looked at the documentation that SWIG auto-generates?
>
> Nope. Can you give a quick summary?
SWIG is a tool for interfacing C (and C++ and Fortran and ...) cod
Michael Mathews <[EMAIL PROTECTED]> writes:
>Jonathan Scott Duff said
>> Status: tabled # shelved, put away for now
Please avoid 'tabled' - it means near the opposite in the UK.
To table something is to put it "on the table" i.e. open for discussion.
--
Nick Ing-Simmons
please move this thread to the mlc list.
thanx,
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
> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
RA> Instead, what about a temporary freeze when each list is created? Give it
RA> a day or two after it's created before it will accept traffic; have the
RA> traffic be held for that long while people subscribe. Would that help
RA>
On Sun, Aug 06, 2000 at 12:41:50AM +0300, Ariel Scolnicov wrote:
> Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > > Another alternative would be Javadoc / doxygen / ... style comments
> > > (say #@ introduces a comment to be extracted).
> >
> > Yuk. More magic to remember. Me h
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 10:55 AM 8/2/00 +0200, Gisle Aas wrote:
>>All functions that return time values (seconds since epoch) should use
>>floating point numbers to return as much precision as the platform
>>supports. All functions that take time values as arguments should
>>
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
[...]
> > Another alternative would be Javadoc / doxygen / ... style comments
> > (say #@ introduces a comment to be extracted).
>
> Yuk. More magic to remember. Me hate.
What magic? The program that does the documentation isn't going to be
cal
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
|| should propagate result context to both sides.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 45
John Porter <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>> Perl's similarity to English is one of the things that makes it Fun.
>
>OTOH, being fun (which I admit it is) is one of the reasons many
>people don't want to think Perl is a serious language.
English had the same problem for 10
On Sun, Aug 06, 2000 at 12:20:54AM +0300, Ariel Scolnicov wrote:
> Lisp calls this sort of thing a "documentation string". One nice
Yes. The (dormant) LISP programmer in me winces for not mentioning
that as a reference.
> thing about the Lisp syntax is that it works even if the Lisp doesn't
>
Jarkko Hietaniemi said
> What's wrong with stealing from C/C++/Java instead
> of trying to invent our own?
>
> In other words, what's wrong with /* ... */?
For one thing this would break (looking for zero or many slashes, x, y and
zero to many zs):
if (/\/*xyz*/) { ... };
Perl has gotten its
Lisp calls this sort of thing a "documentation string". One nice
thing about the Lisp syntax is that it works even if the Lisp doesn't
support docstrings!
We can also do this. Consider this (upcoming) Perl6 code:
sub foo {
"Snarf the frobnitzers if x > 0.1";
my $x = shift;
# ...
}
It is
On Sun, Aug 06, 2000 at 06:37:12AM +1000, Damian Conway wrote:
>> The solution is simple: return hashes instead of lists.
>
> I still think returning lists *or* hashrefs according to context gives
> the same benefits *plus* backwards compatibility.
I sent v2 before I saw just suggestion...wa
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Shell
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 42
=head1 ABSTRACT
Per
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Bring Documentation Closer To Whatever It Documents
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 44
=
Nathan Wiger <[EMAIL PROTECTED]> writes:
>> Um, what stops open returning undef on failure (and setting $!), so I could do
>>
>> $fh = open $filename or die "open $filename failed: $!\n";
>
>Exactly. You don't lose anything because open() will still return "true"
>(a handle) or "false" (
Russ Allbery wrote:
>
> Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> > I also confess to liking // more for till-end-of-line comment marker
> > than #, the hash looks so messy to my eye...of course, // already has
> > a meaning...
>
> I'm the other way around.
>
> This may depend a lot o
Peter Scott <[EMAIL PROTECTED]> writes:
> Another one for my wish list: deep copying support built in.
I don't like this. Not because it isn't useful -- of course it is.
But it seems to me to add very little to the language, at the cost of
a great deal of linguistic baggage.
Consider this: s
Alan Burlison <[EMAIL PROTECTED]> writes:
>"Randal L. Schwartz" wrote:
>
>> Graham> sub def { my @a = (9,8,7); return @a; }
>>
>> That's not returning the array. That's returning a copy of the contents
>> of @a in a list context, and the number of elements of @a in a scalar
>> context, using the
> The solution is simple: return hashes instead of lists.
I still think returning lists *or* hashrefs according to context gives
the same benefits *plus* backwards compatibility.
Damian
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: 05 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 37
=head1 ABS
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Implicit
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 41
=head1 ABSTR
Johan Vromans writes:
> Currently, when a new sublist is announced, it takes some time to get
> subscribed (usually my first 3 or 4 attempts fail since the list does
> not exist yet) and when I wait a while and the subscription succeeds,
> I already have missed several messages.
I think the best
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
> I also confess to liking // more for till-end-of-line comment marker
> than #, the hash looks so messy to my eye...of course, // already has
> a meaning...
I'm the other way around.
This may depend a lot on whether one comes from a shell scripting
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> What about C ?
> I think C or C has merit - "while I am out contact ...".
> But I still think C is the essence of what it does.
I like either C or C too, but just to throw out the other idea
that occurred to me, what's being done here is in other
Johan Vromans <[EMAIL PROTECTED]> writes:
> I would plea for autosubscribing perl6-language list members to every
> sublist that gets spawned. The reason is continuity.
Currently, I'm trying to deal with the volume of Perl lists by subscribing
to just the "top-level" lists and relying on the pro
Johan Vromans <[EMAIL PROTECTED]> writes:
> I fail to see this point.
> Having a program depend on a preprocessing stage that, if skipped,
> would still result in valid but erroneous source seems dangerous to me.
No, the point is more that normal Perl source is *full* of active m4
characters. W
Another one for my wish list: deep copying support built in. A devil
inside me thinks this should be a new assignment operator. Damian? Sounds
like this is up your alley. I want to do a sanity check before taking up
RFC space.
--
Peter Scott
Pacific Systems Design Technologies
Glenn, et.al.
I'm going to be combining a number of different comments in here.
Glenn Linderman wrote:
> I was surprised by the read/write operations, but have no objection to them.
> New/get/set and the individual data member access functions are the critical
> pieces, as the I/O could be done
@a = @b || @c should 'work'. In P5 it puts @b in scalar context and thus
evaluates as the number of elements in @b if there are any.
This one is so tiny, I feel like it should be grouped with something else
before it's big enough for an RFC... what do people think? Is it part of a
larger iss
[cc to perl6-announce removed]
On Sun, 6 Aug 2000 04:54:03 +1000 (EST), Damian Conway wrote (in part):
Damian> I've proposed that the want() function will be able to
Damian> distinguish a HASHREF context (there the return value is
Damian> used as a hash reference).
Damian> $subname = caller(0)-
Johan Vromans wrote:
> An alternative solution is to automatically sent all messages that have
> been posted to the sublist so far, upon subscription.
If there are less than 100 of them, this is probably an excellant idea.
I still haven't received anything directly from -mlc, although I've
rece
On Sun, Aug 06, 2000 at 04:54:03AM +1000, Damian Conway wrote:
>> =head1 TITLE
>>
>> Positional Return Lists Considered Harmful
>>
>> The solution is simple: return hashes instead of lists. Yes, one
>> still has to know how the fields are named, so the proposed solution
> =head1 TITLE
>
> Positional Return Lists Considered Harmful
>
> 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.
I *fully* support this idea. A suggestion thoug
I also confess to liking // more for till-end-of-line comment marker
than #, the hash looks so messy to my eye...of course, // already has
a meaning...
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
On Sun, Aug 06, 2000 at 04:40:29AM +1000, Damian Conway wrote:
>> Oh, the table thing. The switch statement is useful without learning the
>> complete table so I don't think complexity is a big problem. People can
>> learn what they need and ignore the rest. I agree with you that it mi
Original Message
Subject: Re: Sublist auto*
Date: Sat, 05 Aug 2000 14:39:33 -0400
From: Edwin Wiles <[EMAIL PROTECTED]>
Organization: Totally Disorganized
To: Johan Vromans <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Johan Vromans wrote:
> I would plea for autosubscrib
> Oh, the table thing. The switch statement is useful without learning the
> complete table so I don't think complexity is a big problem. People can
> learn what they need and ignore the rest. I agree with you that it might
> be nice to have an array membership operator (like "in") so
I should read what has been said about the matter earlier...but
lacking the time, I'll just shoot:
What's wrong with stealing from C/C++/Java instead
of trying to invent our own?
In other words, what's wrong with /* ... */?
--
$jhi++; # http://www.iki.fi/jhi/
#
Of all the variations that I've seen so far (I'm way behind on reading
the list), the one I like the best is:
qc{ multi
line
comment
here }
Second best, but still acceptable would be:
#<# variations just don't seem "perlish" to me. Sorry!
That's just a personal feeling.
If you just have to g
At 01:10 PM 8/5/00 -0400, Mark-Jason Dominus wrote:
>Summary of manifesto: Global variables must be expunged.
>
>Replacing the old rotten global variables with new rotten global
>variables is not enough of an improvement.
Works for me. Globals should be for things that truly are global. ($^O, for
At 09:45 AM 8/5/00 -0700, Nathan Wiger wrote:
> > 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
At 09:17 AM 8/5/00 -0700, Larry Wall wrote:
>I'm not enamoured of the study interface, but the algorithm is
>definitely a win on certain classes of data. The basic problem with
>study is that it needs incestuous hooks into how you do string
>searching. So even if we moved study out into an exter
At 06:04 PM 8/5/00 +0200, H.Merijn Brand wrote:
>In the roadmap, there's lot of actions and shamelines as spoken of in the
>camel herders association meeting. What was also talked about there, was an
>early release of perl6 to the active CPAN authors, so they would be able to
>try and implement th
> 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 gl
On Sat, 05 Aug 2000, Nathan Wiger wrote:
> > Here in my pre-caffiene morning trance it occurs to me that a few of
> > the "fringe" features of perl should be removed from the langauge.
> > Here's a few things that I would venture to say that none of the
> > "perl5 is my first perl" people have pr
Glenn Linderman wrote:
> [currying] 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.
I'll try to find something. There's a bit of computer science snobbery
related to functiona
Jonathan Scott Duff writes:
: Here in my pre-caffiene morning trance it occurs to me that a few of
: the "fringe" features of perl should be removed from the langauge.
: Here's a few things that I would venture to say that none of the
: "perl5 is my first perl" people have probably ever actually u
Personally, I don't think I've ever used any of these, but I really
don't want to speak for everyone.
Maybe an RFC "Functions and Variables to Remove in Perl 6" ?
-Nate
Jonathan Scott Duff wrote:
>
> Here in my pre-caffiene morning trance it occurs to me that a few of
> the "fringe" features o
> I would plea for autosubscribing perl6-language list members to every
> sublist that gets spawned. The reason is continuity.
Yes, I strongly agree with this! Especially since I'm subscribed from
two different addresses and now chair two lists. I really like it if the
discussion wouldn't start w
In the roadmap, there's lot of actions and shamelines as spoken of in the
camel herders association meeting. What was also talked about there, was an
early release of perl6 to the active CPAN authors, so they would be able to
try and implement the new language for their modules.
I cannot find thi
Bart Lateur <[EMAIL PROTECTED]> writes:
>>> C
>>
>>If I had my druthers, save() would be it.
>
>I'm against it. Why? Because it suggests that all it does is save the
>value for later retrieval. It does not: the value is cleared as well. It
>masks the previous global value, as if it didn't exist be
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people have probably ever actually used.
reset # How
On Sat, Aug 05, 2000 at 06:33:10PM +0900, Simon Cozens wrote:
>
>> (Remember Larry's slide with the Perl influences on it?
>> Linguistics, Art, Common Sense *and* Computer Science.)
>
>I know. My point was that we shouldn't forget the first three in blind
>pursuit of the forth.
I'm trying to dec
On Sat, Aug 05, 2000 at 10:54:25PM +0900, Simon Cozens wrote:
>On Sat, Aug 05, 2000 at 11:47:47PM +1000, Jeremy Howard wrote:
>> I feel that your RFC misses the inclusive nature of perl.
>
>Then I withdraw it. Perl should not stay Perl, fuck it. Call me when it's
>time to get coding.
This langua
On Sat, Aug 05, 2000 at 12:04:30PM +0200, Bart Lateur wrote:
> On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote:
>
> >> C
> >
> >If I had my druthers, save() would be it.
>
> I'm against it. Why? Because it suggests that all it does is save the
> value for later retrieval. It does no
> I'd thought I try to summarize what has come up so far and see if we can
> find somebody who can write some RFCs.
>
Terrific--thanks!
Make sure you read the interesting RFCs from Damian Conway on related
issues:
> * Built-ins: min() and max() functions and acceptors
>
> * Built-ins: reduce() f
On Sat, Aug 05, 2000 at 11:47:47PM +1000, Jeremy Howard wrote:
> I feel that your RFC misses the inclusive nature of perl.
Then I withdraw it. Perl should not stay Perl, fuck it. Call me when it's
time to get coding.
--
Life would be so much easier if we could just look at the source code.
Simon Cozens wrote:
> Right. You don't seem to be getting it, so I'm going to have to be harsh
here.
>
Are you sure? Is it possible that it's just that this isn't a side of
programming you've had need for or are familiar with yourself? TMTOWTDI, you
know, even if you're way is the best way.
> You
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
DEADLIN
> 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.
>
A quick description is here:
http://www.cs
Damian Conway <[EMAIL PROTECTED]> writes:
> > It definitely is, since formats do things that can't be done in modules.
>
>Such as???
Quite.
Even in perl5 an XS module can do _anything at all_.
--
Nick Ing-Simmons
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 01:17 PM 8/4/00 +0500, Tom Scola wrote:
>> >[I think this belongs on the language list, FWIW, Cc'd there]
>> >
>> >I like this, but I'd like to see this, inter-thread queues, and events
>>all
>> >use the same communication method. Overload filehandles t
On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote:
>> C
>
>If I had my druthers, save() would be it.
I'm against it. Why? Because it suggests that all it does is save the
value for later retrieval. It does not: the value is cleared as well. It
masks the previous global value, as if it
John Porter <[EMAIL PROTECTED]> writes:
> 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.
Icon also allows $x == ( 1 | 2 ), meaning ($x == 1) || ($x == 2).
-- Johan
[The original subject was: Sublist autosubscribe, but that was
rejected by the mailing list manager.]
I would plea for autosubscribing perl6-language list members to every
sublist that gets spawned. The reason is continuity.
Currently, when a new sublist is announced, it takes some time to get
1 - 100 of 111 matches
Mail list logo
