Re: PDL-P: Re: Reduce [was: Re: Random items (old p5p issues)]
Tuomas Lukka [EMAIL PROTECTED] writes:
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 think we're confusing 2 separate issues here. PDL seems to deal
with both, but let's keep them separate:
(1) Decent span objects for generating subarrays (e.g. 1:10:3 (which
should probably be 1..10:3, or whatever the iterator sequence
works out as).
(2) Multidimensional arrays. Today Perl does *not* have these. As
Tuomas points out, the `,' operator is already too overloaded to
separate indices. Note: I say the Perl has no multidimensional
arrays. A list-of-lists is *not* a multidimensional array. A
multidimensional array can be *implemented* as a list-of-lists,
but not efficiently.
Naturally, there are interesting interactions between (1) and (2),
e.g. when slicing a multidimensional array (consider, for instance,
what an operator should look like that returns the diagonal of a
square matrix).
A third issue:
(3) An "rvalue" slice is a *copy* of the elements sliced from the
array; an "lvalue" slice consists of the elements themselves, with
a different indexing scheme. Naturally, Perl should have both...
[...]
Regarding multi-dimensional arrays, the PDL porters are undoubtable
champions; what is required?
Well, the PDL distro is our answer to that ;) ;)
But Shirley Perl could make your job a little less horrible? At the
very least, if `:' were a binary operator, you could overload it to
generate non-string slice indices.
--
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: Filehandle type-defining punctuation
On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote: If we've decided that chomp isn't going to return the clippings, would it not seem prudent to make while (chomp(ARGV)) work like while (ARGV) You mean, like, the -l command line switch? (see perlrun) chomp() on input, append newlines on print (though $\). -- Bart.
Re: RFC 28 (v1) Perl should stay Perl.
On Fri, Aug 04, 2000 at 02:50:39PM -0400, Chaim Frenkel wrote: 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. Right. You don't seem to be getting it, so I'm going to have to be harsh here. You see, there's a way we can canonically verify whether these suggestions have any merit whatsoever, or whether they should be shot down in flames and burnt. Perl, being the practical language that it is, and since we can easily implement reduce and friends in Perl, we can very easily tell if there's a real need for these features by looking at whether anyone has attempted to implement them. So, if you can point me at a CPAN module that does this, I'll concede that *one* person actually cares enough about these things to do something about it. Of course, one person caring doesn't mean that the need is strong enough for something to go in Perl. There are all sorts of wacky modules out there, not all of which should go in core. If you'd suggested adding support for URI encoding and decoding, I would have laughed a lot less, since that's a feature that a lot of people need, want and use. But what is being proposed is completely and utterly unwanted by the vast majority of Perl users out there. It's pie-in-the-sky ludicrosity from some ivory tower. It may be your hobby-horse, but there *is* no CPAN module to attempt to implement these things, there are no users, nobody wants it, nobody needs it and nobody cares. End of story. So can we please leave these ridiculous delusions behind and get on with some real work? -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
Re: RFC 28 (v1) Perl should stay Perl.
On Fri, Aug 04, 2000 at 11:31:30PM -0400, Ken Fox 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. Don't be stupid. I said we're *primarily* doing it for the good of Perl. Well, *I*'m doing it for the good of Perl. 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. New ideas are good. Bad ideas are bad. I'm trying to encourage people to draw a distinction, but it doesn't seem to be working. I really don't want to have to be forced to withdraw this RFC, but that's the way it's headed. (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. -- There are two kinds of egotists: 1) Those who admit it 2) The rest of us
Re: New Group proposed: subs (was Re: named parameters)
"Kyle R . Burton" [EMAIL PROTECTED] writes: use self = 'self'; use self = 'this'; Of course, if you _really_ want to avoid religious wars, you would need a non-selfish pragma name in the first place. -- Johan
Preprocessing (Was: Re: Recording what we decided *not* to do, and why)
Russ Allbery [EMAIL PROTECTED] writes: 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. 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. 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. I wouldn't classify the cpp language (#ifdef #define #include) friendly to C either. It looks as if they happily co-exist since invoking the C compiler automatically invokes the preprocessor. But let's not put energy in a cpp versus m4 discussion. External macro processors exist and can be applied by suffienciently skillful people anyway. I think the question we must ask ourselves is: what kind of preprocessing would we like perl to provide automatically. Also, I think that preprocessing only plays a relevant role if we have byte compiling. There a few advantages of a preprocessor if preprocessing/compilation/execution are _always_ done together. -- Johan
Re: RFC 17 (v1) Organization and Rationalization of Perl
On Fri, 04 Aug 2000 00:47:06 -0500, J. David Blackstone wrote: As another example, at work we are in love with the $/ variable, since we often deal in multi-line records delimited with control-Y's. However, changing this variable affects _everything_, meaning modules you want to use might not work unless you only modify $/ with local() within a subroutine. The solution is for the concept of $/ to become a per-filehandle value, as in, encapsulation and object-orientation. I have only one problem with this solution, and that is with the magic file handle. Would it's private $/ stick across files? Well, er, yes... That reminds me of another small problem: cross-platform newlines. The solution often proposed is turning $/ processing into a regex thing. It is just as often rejected, mainly for speed reasons, I believe, because it would slowing reading every single line down quite considerably. Actually, in paragraph mode ($/=''), it already IS processed as a regex, so basically it is feasable. I think an actual regex is too general. ALl you need to be able to handle, are the common cases of bare LF, bare CR, and CR+LF combination. However, there is no more possible magic value left to assign to $/ that I can think of... Also, I'd like to be able to output a text file with the same typical end-of-line sequence as the input file, in particular when using the -i command line switch. That also implies a per-file-in @ARGV change of, say, $\, to match what is generally in the input. Heh. It looks like I'm trying to make Perl more complex, instead of simpler... Can we make a simpler implementaion idea that nevertheless would DWIM? -- Bart.
Sublist auto*
[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 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. Autosubscribing would solve this, especially since it is trivial to unsubscribe when one is not interested in a particular thread. An alternative solution is to automatically sent all messages that have been posted to the sublist so far, upon subscription. -- Johan
Re: RFC 25 (v1) Multiway comparisons
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
Re: RFC: Rename local() operator
On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote: Csave 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 before. save $/ = "\n"; That doesn't quite say it, does it? In PostScript, for example, there's a gsave and grestore, the "g" standing for graphics state. It allows you to save the current state of the graphics output device, on a stack, but it doesn't modify it. You can continue from there. It's a different concept. The name "local" is wrong, because it suggests a private value scoped in space. It is not, that's lexical values. It is scoped in time. I think it's name should refelect that. "temporary"? temporary $/ = "\n"; It's a mouthful. But it's going where I'd want it to go. -- Bart.
Re: RFC 22 (v1) Builtin switch statement
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.nott.ac.uk/~gmh//faq.html#currying Since it's named after Haskell Curry, you might like to learn about Haskell: http://www.haskell.org/bookshelf/ Currying really is DWIM, and I find it very perlish. But it requires some unlearning of what's not possible in common procedural languages. This does all bring up an important issue. If we go with '__' or something similar (and I sure hope we do) we're likely to want to hang a whole lot of other stuff off of it (in this case it enables/simplifies important functionality of switch/case). But although __ is perlish, it's very new to perl old-hands. So is this OK? Should we expect perl 5 gurus to have to learn new stuff to get the most out of perl 6? Hmmm... When I say it that way it seems obvious that the answer is 'yes'...
Re: RFC 28 (v1) Perl should stay Perl.
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 see, there's a way we can canonically verify whether these suggestions have any merit whatsoever, or whether they should be shot down in flames and burnt. Perl, being the practical language that it is, and since we can easily implement reduce and friends in Perl, we can very easily tell if there's a real need for these features by looking at whether anyone has attempted to implement them. So, if you can point me at a CPAN module that does this, I'll concede that *one* person actually cares enough about these things to do something about it. Please concede then: - PDL (see pdl.perl.org). This implements reductions with great care, defining new data types that can be effectively used with array semantics - List::Util (http://search.cpan.org/doc/GBARR/Scalar-List-Utils-1.02/lib/List/Util.pm) is the pure perl version. It includes: first sum min max minstr maxstr reduce Of course, one person caring doesn't mean that the need is strong enough for something to go in Perl. There are all sorts of wacky modules out there, not all of which should go in core. If you'd suggested adding support for URI encoding and decoding, I would have laughed a lot less, since that's a feature that a lot of people need, want and use. But what is being proposed is completely and utterly unwanted by the vast majority of Perl users out there. It's pie-in-the-sky ludicrosity from some ivory tower. It may be your hobby-horse, but there *is* no CPAN module to attempt to implement these things, there are no users, nobody wants it, nobody needs it and nobody cares. End of story. Well you're short by at least 1. I use reduce, I want reduce, I need reduce, and I care about reduce. I also communicate regularly with a large numerical programming community who does the same. Almost none of them use perl, because at this stage it's just not good enough in this area. PDL is getting there, but if it doesn't supply the function you need, you have to write it in C and jump through all kinds of hoops do implement the optimisations that perl could do if it knew about this stuff, but doesn't. So can we please leave these ridiculous delusions behind and get on with some real work? I guess my work is different to your work. But that's the point, isn't it? We have different needs. I feel that your RFC misses the inclusive nature of perl. I want to be able to write: $a = sum(@b*@c+@d) and have it DWIM. Even if @b,@c, and @d are columns of sparse tensors. If you don't want this, fine. But don't stop me from having it. Anyway, it so happens I started writing a counter-RFC on the plane on the way home tonight. This discussion certainly makes me want to make sure I finish it. It's called 'Perl should be Perl, only better'.
Re: RFC 28 (v1) Perl should stay Perl.
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. -- Dave Olson
Re: PDL and perl6
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() function * Data structures: Semi-finite (lazy) lists * Subroutines: higher order functions * Subroutines: lazy evaluation of argument lists * Superpositions: vector operations via superpositions He's also promised general purpose iterators in a separate message. These haven't all been written yet. The excellent news is that Dan Sugalski (who's heading up the internals team) has promised that he'd make sure that the optimisations we need would be seen to. In particular, we talked about making sure that the following creates only one loop and no array copies: $a = sum(@b*@c+@d) ...and I did point out that @b et al might actually be columns of a sparse matrix accessed through an iterator. Larry Wall will decide the changes to make for perl6 based on our suggestions. To make life easy for him, we should put some effort into our suggestions. RFCs are intended to be focus discussion on something that will be useful to Larry when he makes his decisions. This reads to me like the code of this religious cult whose aim it is to worship the great LW. From perldoc perlhack: You might sometimes see reference to Rule 1 and Rule 2. Larry's power as Supreme Court is expressed in The Rules: 1 Larry is always by definition right about how Perl should behave. This means he has final veto power on the core functionality. 2 Larry is allowed to change his mind about any matter at a later date, regardless of whether he previously invoked Rule 1. Got that? Larry is always right, even when he was wrong. It's rare to see either Rule exercised, but they are often alluded to. Under this premise Larry is well placed to make a final ruling ;-) In reality he respects the opinions of people like Damian Conway, Dan Sugalski a great deal and is unlikely to just through out stuff they suggest. But the nice thing about having one person responsible for oversight is that he can pull disparate threads together into a unifying construct. Larry has shown in the past that he is very good at this. I am not sure if this impression is intended but I notice a lack of clarification how the syntax issues about perl6 are decided. Is it really all down to one individual (however bright and charismatic this particular person may be)? A more clearly stated process where possibly a small group of developers (with write access to the repository) decides things and where a project leader (LW?) has the possibility of a veto or such seems at least transparent to me. It would probably also be welcomed by industry if a clear process is outlined. There was a lot of discussion on the bootstrap list about how this should all work. I don't think there's much chance of getting a rethink at this stage. Maybe I am the only one seeing a possible problem here but as a scientist I am deeply suspicious about a decision process that is down to one individual only (not even taking the workload into account). Larry's workload will be greatly dimished by the working group chairs, who pull together the RFCs for him. In turn the RFC chairs pull together the RFC threads for the WG chair. So far this process is looking like working pretty well. As Plato pointed out, a benevolent dictator is the most efficient form of government... Anyway, all I can say is, give it a go! Start cross-posting your thoughts to perl6-language, and pop over to dev.perl.org to see what RFCs are around. I'm sure you want to keep up the discussion with PDL-P, but if it's about perl 6, why not have it on perl6-language where everyone can follow it?
Re: RFC: Rename local() operator
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: Csave 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 before. save $/ = "\n"; That doesn't quite say it, does it? You're right of course, but I don't know of any one word that concisely and succintly means "save the current value of this variable, clear it, and restore on exit of the current scope" More words: store() # put away for the duration of the scope tuck() # Now I lay me down to sleep hide() # I kinda like this one :-) shelve()# probably too loaded stow() # Just sit right back and you'll hear a tale ... bury() # Oh my god! They've killed Kenny! I've changed my mind; my personal favorite is now "hide" -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 28 (v1) Perl should stay Perl.
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 language is not appropriate for this mailing list. Anyone who feels the need to continue this discussion should take it to private email. I do *not* want to see any more obscenity of name calling here. It does nothing to advance the purposes of this working group, and discourages people from contributing. 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: Things to remove
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 of perl should be removed from the langauge. Here's a few things that I would venture to say that none of the "perl5 is my first perl" people have probably ever actually used. reset # How often do you clear variables wholesale? dump study # never been a win for me. ?pattern? # one-time match split ?pat? # implicit split to @_ What's everyone's feeling on removing these from perl6? How often are they used? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Things to remove
Jonathan Scott Duff writes: : Here in my pre-caffiene morning trance it occurs to me that a few of : the "fringe" features of perl should be removed from the langauge. : Here's a few things that I would venture to say that none of the : "perl5 is my first perl" people have probably ever actually used. : : reset # How often do you clear variables wholesale? : dump : ?pattern? # one-time match : split ?pat? # implicit split to @_ : study # never been a win for me. : : What's everyone's feeling on removing these from perl6? How often are : they used? Those are all good candidates for removal, or at least "promotion" to an external module. The only one I'd think twice about is study. For much of Perl 5's existence, it didn't get a fair shake, since it was buggy, and nobody noticed. Of course, that might be an argument for removal. :-) I'm not enamoured of the study interface, but the algorithm is definitely a win on certain classes of data. The basic problem with study is that it needs incestuous hooks into how you do string searching. So even if we moved study out into an external module, we'd still have to find some way to treat searching for constant strings as polymorphic within the regex engine. Larry
Re: Things to remove
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 probably ever actually used. reset # How often do you clear variables wholesale? dump study # never been a win for me. Perl5 is my first Perl. I use study on occasion. ?pattern? # one-time match split ?pat? # implicit split to @_ Which is currently labeled as deprecated, I believe. Most things labeled (or treated, such as pre-pod embedded docstrings) as deprecated should/could be removed. What's everyone's feeling on removing these from perl6? How often are they used? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
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 external module, we'd still have to find some way to treat searching for constant strings as polymorphic within the regex engine. It should be possible to write external modules that both have hooks deep into perl and are automagically loaded. We could, for a first cut, define the hooks and yank study off into one of these modules, with a "do nothing" function in there. Then, when Clever People have had a chance to go think about it, we could drop in a replacement and get the win. This, of course, presumes that defining the hooks (which will also require Clever People) can be done correctly without actually writing the code that uses it... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: multiline comments
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:
#END
multi
line
comment
END
The reason it's second best, is because qc{ canbeusedinline } as well as
multi-line. It's just an extension of the existing quoting mechanism.
The # comment # variations just don't seem "perlish" to me. Sorry!
That's just a personal feeling.
If you just have to go with the # set for a block comment, I rather
like the idea of making them # and # to end, starting in the first
column.
Again, for the stated purpose, #ifdef seems to be the more reasonable
way to go, rather than putting in a truly cryptic usage of the comment
pound sign.
E.W.
John Porter wrote:
Michael Mathews wrote:
So this should work in Perl 6
code here;
#
# this is a single line comment
$foo = $a + $b # here's an in-line comment # + $c * $d;
#
more code here;
If starting in column 1 is going to be magic, you may as well
make the magic char #, so:
#
# this is a single line comment
$foo = $a + $b # here's an in-line comment # + $c * $d;
#
And then, you may as well make it =, and use some meaningful
verbiage instead of "" and "". So:
=begin comment
# this is a single line comment
$foo = $a + $b # here's an in-line comment # + $c * $d;
=end comment
The pod solution is more or less obvious. Inlinable nestable
comments are something else, and it should look like perl.
qc() -- compiled to nothingness.
--
John Porter
Re: RFC: multiline comments
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/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 22 (v1) Builtin switch statement
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 that you can write: if ($x in [ 1, 2, 3 ]) ... if ( grep $x==$_, (1,2,3) ) ... Be nice if it would short-circuit in a boolean context though! Damian
[Fwd: Re: Sublist auto*]
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 autosubscribing perl6-language list members to every sublist that gets spawned. The reason is continuity. OY! Please do NOT do this! Or rig it as a member configuration choice, so that those who want autosubscription can opt-in! An alternative solution is to automatically sent all messages that have been posted to the sublist so far, upon subscription. That would be just ducky by me! Though you might wish to consider limiting it to the last N hundred messages. If someone subscribes late in the sub-list life, their SA is _not_ going to be happy if their system gets killed by what would effectively be a mail-bombing, albeit unintentional. As yet another alternative, if you subscribe late, go look at the archives! E.W.
Re: RFC 22 (v1) Builtin switch statement
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 might be nice to have an array membership operator (like "in") so that you can write: if ($x in [ 1, 2, 3 ]) ... if ( grep $x==$_, (1,2,3) ) ... Be nice if it would short-circuit in a boolean context though! I think we need a general way of short-circuiting out of a grep (and other list iterating funcs, if it makes sense...) We may need both success and failure short-circuits? It's a pity 'last' already has semantics there, not to mention return... Damian -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC: multiline comments
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
Re: RFC 37 (v1) Positional Return Lists Considered Harmf
[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)-{subname}; # hashref context
Don't forget Larry's propsed syntax (which is related to the possibility
of getting rid of typeglobs):
\%myhash = \%yourhash;
which would seem to lead to
\%hashname = call();# hashref context
--
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
@a = @b || @c
@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 issue I haven't seen? -- Peter Scott Pacific Systems Design Technologies
Re: DRAFT RFC: Enhanced Pack/Unpack
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 to normal variables, but it would take more steps that way, so read/write are nice enhancements. I felt that the read/write enhancements were necessary. Without them, the programmer must calculate the required length of the reads themselves. While they may know the length of fixed elements, they will not know the length of variable elements. At least not without pre-reading the fixed elements that provide that length. Requiring them to do so would defeat one of the goals, easier use. [ 'bar' = 'i', 'baz' = 'i', 'count' = 'i' ] It is my understanding that "=" is an indication of a link in a hash array between its name and its value. Given the necessity of maintaining the order of elements, this nomenclature would appear to be inappropriate. Still, I like the idea of making the relationship more explicit, we could do it this way: [ ['bar','int32'], ['baz','int32'], ['count','int32'] ] As you can see, I agree with longer data type names. However, in response to a number of other postings to the language group, I'm going to suggest that we adopt a different format. PLEA FOR INFO! Can anyone point me at a better/more detailed explanation of the existing 'pack/unpack' format characters? The one in 'perlfunc' leaves me wondering what a number of the markers are for, or exactly how they work. Consider 'p' and 'P'. They're supposedly refering to a pointer to either a string or structure, but they don't say whether the pointer is relative to the first byte of the pointer, the first byte after the pointer, or the first byte of the overall structure. Basic Object Type: 'short' - whatever your computer understands is a short. 'long' - ditto. 'int' - ditto. 'double' - ditto. 'float' - ditto. 'char' - ditto, with the understanding that Unicode makes these characters larger than you would expect. 'byte' - whatever your computer understands is a byte. (Yes, there are some systems that don't use 8 bits to a byte. Not many, but they are there.) 'octet' - specifically 8 bits, regardless of the byte size of your system. To which we may append a number of different modifiers: Endianness: /d - default, whatever your system uses normally /n - network /b - big /l - little /v - vax (??vax is sufficiently different to require it's own?? Or is this to do with bit order?) Signedness: /u - unsigned /s - signed We may also allow these modifiers in the definition of the structure, so that the entire structure can be affected, without having to explicitly modify each variable. Non-Standard sizes: /[0-9]+ - The basic object is this many bits long. I strongly suggest that we settle on bits as the standard of length, since if we start mixing bits versus bytes on the basic elements, we're going to confuse the living daylights out of people. Definition of arrays: [length] - The number of basic objects, as modified. So, an array of 20 10-bit unsigned network order integers would be: [ ['myarray','int/10/u/n[20]'] ] Alternatively: [ ['myarray','int/un10[20]'] ] I know that looks complex, but I believe that the vast majority of cases would likely be handled by the simplest forms, such as: [ ['myfixedstring', 'char[30]'] ] Which is an array of 30 unicode characters. (Of course, if the decision is made that we do not use unicode, or any other multi-lingual support, then the specialness of 'char' versus 'byte' goes away.) (As you might guess, I'm torn between human readable, easily parsed, and easy to type. I may have gone too far twoards 'easily parsed'.) 4) allow hooks to support non-standard types. sub Structure::define ( type name, frombinarysub, tobinarysub ) sub from_funny ( type_params, binary_var, bit_offset ) # returns ( next_bit_offset, funny_var ) sub to_funny ( type_params, binary_var, bit_offset, funny_var ) # returns ( next_bit_offset ) This combination presumes that the data has already been loaded into an internal variable. Given variable length data, this is not a valid assumption. I considered adding a 'length' subroutine to the spec, which the main pack code could call to determine if it needed to read any more data, but realized that the 'length' subroutine itself might need to read more data before it could determine the total length needed for 'from_funny' to succeed. Thus, 'from_funny' must either return a special code indicating that it needs more data to work, with some indication of how much more to read; or it must perform it's own reading, and therefore accept a file handle to read from. I'm leaning towards the first case, because we may have received our data via a string, not a file handle. In that event, there is no
Re: Preprocessing (Was: Re: Recording what we decided *not* to do, and why)
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. Without quoting, all your paired quotes would disappear, comments would be stripped even when they're not actually comments but are really regexes, m4 wouldn't understand things like Perl strings and regexes and do substitutions where it shouldn't, etc. The problem is not that you can skip the preprocessing stage, but rather that as soon as you want to use m4 on a Perl program, you'd have to do a *huge* amount of work on all the parts of the program you *don't* need to preprocess just to be able to do things with the part that you do want to preprocess. cpp, on the other hand, has very few active constructs or characters, just identifiers, function calls, and # at the beginning of a line. It still causes a few problems where it recognizes something it shouldn't, but it's trivial to deal with compared to m4. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Sublist auto*
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 promised summaries from the sublists. That so far seems to be working pretty well; I feel like I have a good overview of what's going on, without getting deluged. I'd really rather not automatically be put on the sublists, as I don't think I want to receive them unless I care a lot about that particular topic. Instead, what about a temporary freeze when each list is created? Give it a day or two after it's created before it will accept traffic; have the traffic be held for that long while people subscribe. Would that help this problem? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC: Rename local() operator
Nick Ing-Simmons [EMAIL PROTECTED] writes: What about Chide ? I think Cproxy or Cdeputy has merit - "while I am out contact ...". But I still think Csave is the essence of what it does. I like either Chide or Csave too, but just to throw out the other idea that occurred to me, what's being done here is in other languages often called shadowing. What about Cshadow? shadow $/ = "\n"; seems to have the right implications to me. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC: multiline comments
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 background or from a C++ background. I strongly dislike C++ and other than Perl primarily use C and shell, so # is the most natural to me and // looks really odd. Of course, like you said, we really can't use // anyway, as it's valid Perl code and actually semi-frequently used. I do agree that there's a lot to be said for using /* ... */ for multiline comments, but then I'm a C programmer. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Sublist auto*
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 way to solve this is to not announce mailing lists until they're created. That means sending Ask the create request via private not public email. There's a trivial get mechanism to request the last n messages if you do miss a few. Just send mail to: [EMAIL PROTECTED] or whatever range of messages you want. Nat
Re: perl 6 requirements
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 "@a" operator. You still haven't "returned the array".
So then in fact it is impossible to return an array - yes? You can
either return a single scalar or a list. The closest you can come to
returning an array as an entity is to return a reference to it - \@a.
Have I got that straight?
At the perl level yes. The core C can push an AV * on the stack
but perl does not know what it means. (Tk did this for a while
internally before I decided to comply with the perl semantics.)
--
Nick Ing-Simmons
Re: Deep copy
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: shallow copying is rightfully (I hope we agree) the default. Writing a `copy' function is easy (perhaps a `copy' builtin would even satisfy you). This would be bearable, maybe. But PLEASE don't add a new assignment operator for this! For a start, making a deep copy makes sense even when no assignment is involved (hence the `copy' suggestion above). However, no less useful than deep copy is k-level copy, especially when k==1. Before long, we'll have `=', `:=', `-' and maybe `===' operators in the language, for the different levels of copying. This is needless bloat. [...] -- 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: multiline comments
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 on whether one comes from a shell scripting background or from a C++ background. I strongly dislike C++ and other than Perl primarily use C and shell, so # is the most natural to me and // looks really odd. Of course, like you said, we really can't use // anyway, as it's valid Perl code and actually semi-frequently used. I do agree that there's a lot to be said for using /* ... */ for multiline comments, but then I'm a C programmer. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ I agree. The '#' has become a staple of Good Formatting in Perl. For multiline comments in Perl, how about something like #$ .. $# or #* .. *#? There is something to be said for the cliche ## comment blocks at the top of Perl programs, but maybe a neater alternative should be considered... -- Mike Pastore [EMAIL PROTECTED]
Re: RFC 37 (v2) Positional Return Lists Considered Harmf
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...wait for v3. Damian -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 44 (v1) Bring Documentation Closer To Whatever I
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 perfectly legal Perl5; there is a useless use of a value in void
context, but that's all.
Another alternative would be Javadoc / doxygen / ... style comments
(say #@ introduces a comment to be extracted).
Since the Perl interpreter doesn't need to know about documentation,
I'm for anything that doesn't require it to do anything.
Typing is also nice for this sort of thing; if we say
##@ Update DiLithium levels
sub foo(int $x) {
my DiLithium $ret;
# ... all returns are via $ret ...
$ret;
}
then Perldoc6 should be able to know that foo has type int -
DiLithium.
--
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: lexical variables made default
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 100s of years - all the serious stuff was done in latin (or even french). -- Nick Ing-Simmons
Re: RFC 44 (v1) Bring Documentation Closer To Whatever I
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 called `perl' (`perl' is the name of the program that exhibits the bugs in what you wrote). We already have 3 ways of getting Perl to ignore things (comments, =BLAH, and void context; do we really need another 3? I say bring the documentation so close to the thing it documents that they can see each others' nose hair. Have you looked at the documentation that SWIG auto-generates? -- 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 44 (v1) Bring Documentation Closer To Whatever I
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 hate. What magic? The program that does the documentation isn't going to be The '#@ introduces a comment to be extracted' magic. called `perl' (`perl' is the name of the program that exhibits the bugs in what you wrote). We already have 3 ways of getting Perl to ignore things (comments, =BLAH, and void context; do we really need another 3? "Ignore" is a weird word to be used for documentation :-) I say bring the documentation so close to the thing it documents that they can see each others' nose hair. Have you looked at the documentation that SWIG auto-generates? Nope. Can you give a quick summary? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC: multiline comments
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 Search Engine on the Net -- http://www.northernlight.com
Re: Recording what we decided *not* to do, and why
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
Re: RFC 44 (v1) Bring Documentation Closer To Whatever I
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 ...) code to Python / Perl / TCL / ...; it uses code that looks vaguely like C header files to tell it what to do. Assuming you have all the typemaps needed and exactly the right functions in your library, all you need to do is give the header: %module Mod Foo *MakeFoo(Bar *b); /* Frobnitz Bar canonically */ double square(double a);/* square (a circle) */ When run through SWIG, it generates this DOC file (in addition to a C file you compile to generate the extension): MakeFoo b [ returns Foo * ] Frobnitz Bar canonically square a [ returns double ] square (a circle) Options exist to tweak the generate documentation somewhat, but even this level is very useful. -- 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 15 (v1) Stronger typing through tie.
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 Dog $spot; for a while. But I just realized if $ is one of something, @ sereral etc. then do we need a magic char to designate 'type' (class or whatever). I suppose: my ¢Dog $spot; # That is "cent" i.e. c with line. might do ;-) -- Nick Ing-Simmons
Re: RFC: lexical variables made default (revised)
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 implementation. I'd like to
propose something radical.
Consider code like this, which is not uncommon:
use strict;
my $var1 = 'some val';
my $var2 = 'some other val';
sub mysub {
my($arg1, $arg2) = @_;
(my $result = $arg1) =~ s/some/every/g;
return ($result, $arg2);
}
my @stuff = mysub($var1, $var2);
You get the idea. Dang there's a lot of my()'s in there! The only thing
I see this RFC changing is the need for the "use strict" statement.
However, the code is still littered with what I would argue are
"useless" my()'s that serve as workarounds for a fundamental flaw in the
langauge: all variables are global by default.
Go look at some Tcl/Tk code for what happens if you make everything
innermost lexical by default.
You get liberal sprinkling of
upvar 2 foo
global fred harry
etc.
The problem is you quite often whant variables to cross {} boundaries,
if any mention of thing on left declares it in current scope you
end up with "upvar" and "global" to say "no I don't mean that".
--
Nick Ing-Simmons
Re: RFC 24 (v1) Semi-finite (lazy) lists
@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";
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 cool to be able to specify other infinite sets
somehow (with rationals, with complex, etc) but [..] isn't the right way.
Sorry about that.
Re: PDL-P: Re: PDL and perl6
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: higher order functions Found those (RFC2324) * Subroutines: lazy evaluation of argument lists * Superpositions: vector operations via superpositions Couldn't see those either. Could you refer to the actual RFC #s, please? The excellent news is that Dan Sugalski (who's heading up the internals team) has promised that he'd make sure that the optimisations we need would be seen to. In particular, we talked about making sure that the following creates only one loop and no array copies: $a = sum(@b*@c+@d) ...and I did point out that @b et al might actually be columns of a sparse matrix accessed through an iterator. Sounds interesting. From our point of view one question is: assuming that there still is a need for compact numerical objects (PDLs) as opposed to conventional perl arrays (for reasons of efficiency and memory consumption) will those compile time optimizations also be accessible to PDL objects? Anyway, all I can say is, give it a go! Start cross-posting your thoughts to perl6-language, and pop over to dev.perl.org to see what RFCs are around. I'm sure you want to keep up the discussion with PDL-P, but if it's about perl 6, why not have it on perl6-language where everyone can follow it? Sure. One problem we AFAIK have on pdl-porters is that all developers I know of use PDL and perl for real work in their day jobs and are hard pressed to deal with all the mailing list traffic, upcoming problems and RFC writing just in the time frame that seems available. Christian
Re: RFC 24 (v1) Semi-finite (lazy) lists
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 of the 1st 100 integers is: $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";
I still think it would be cool to be able to specify other infinite sets
somehow (with rationals, with complex, etc) but [..] isn't the right way.
Sorry about that.
If we're going to do THAT, why not predeclare functions (or static
lists) of different mathematical terms, like the set of all real
numbers, the set of all natural numbers, the set of integers, etc.? No
sense in mangling the .. operator (not to mention the anonymous array
reference) to suit a specific purpose like that.
--
Mike Pastore
[EMAIL PROTECTED]
Re: RFC 23 (v1) Higher order functions
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:
@integersInN = grep {$_=abs($_)} @n; # @intsInN is (1,4)
Why force me to write a boring old anonymous sub here when we've got
oh-so-cool higher-order functions? What I _really_ want to write is:
@integersInN = grep _test=abs(_test) @n; # @intsInN is (1,4)--hooray!
So I'd like to see the following in the RFC:
It is proposed that Perl introduce a new prefix '_', which indicates a
placeholder. This can be used either as '_identifier', which creates a named
placeholder, or '__', which creates an anonymous placeholder.
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 function, they know that each is referring to the same thing.
Re: RFC 24 (v1) Semi-finite (lazy) lists
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 cool to be able to specify other infinite sets somehow (with rationals, with complex, etc) but [..] isn't the right way. Sorry about that. If we're going to do THAT, why not predeclare functions (or static lists) of different mathematical terms, like the set of all real numbers, the set of all natural numbers, the set of integers, etc.? No sense in mangling the .. operator (not to mention the anonymous array reference) to suit a specific purpose like that. Sure. But when I see: @positiveInts = (1..); @negativeInts = (..-1); isn't it rather perlish to expect that I can then write: @allTheInts = (..); BTW, I didn't really mean to use array _references_. When I said [..], I meant (..) I'll issue another correction.
Re: RFC 24 (v1) Semi-finite (lazy) lists
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 course: @i = (..); not @i = [..]; It just goes to prove that Sunday morning is a poor time to sit in front of a computer... Time to go outside!
Re: PDL-P: Re: PDL and perl6
* 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, please? As I mentioned, not all Damian's RFCs exist yet. These are the ones that he's promised are coming (along with generalised iterators). ... From our point of view one question is: assuming that there still is a need for compact numerical objects (PDLs) as opposed to conventional perl arrays (for reasons of efficiency and memory consumption) will those compile time optimizations also be accessible to PDL objects? 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 how numeric types are stored. I think we should look to remove the distinction between 'stuff that works in PDL' and 'stuff that works in perl'. To do this I guess we need an RFC proposing compact array storage for numeric data. Most of the rest of PDL core is already proposed in one form or another. Stuff like SLATEC support still belongs in external modules, of course. Anyway, all I can say is, give it a go! Start cross-posting your thoughts to perl6-language, and pop over to dev.perl.org to see what RFCs are around. I'm sure you want to keep up the discussion with PDL-P, but if it's about perl 6, why not have it on perl6-language where everyone can follow it? Sure. One problem we AFAIK have on pdl-porters is that all developers I know of use PDL and perl for real work in their day jobs and are hard pressed to deal with all the mailing list traffic, upcoming problems and RFC writing just in the time frame that seems available. I know what you mean--I've got a full-time job too (hence writing this on a sunny Sunday morning!)... Still, this is the time to get your $0.02 in.
Re: PDL-P: Re: PDL and perl6
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 Couldn't see those either. Could you refer to the actual RFC #s, please? As I mentioned, not all Damian's RFCs exist yet. These are the ones that he's promised are coming (along with generalised iterators). ... From our point of view one question is: assuming that there still is a need for compact numerical objects (PDLs) as opposed to conventional perl arrays (for reasons of efficiency and memory consumption) will those compile time optimizations also be accessible to PDL objects? 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 how numeric types are stored. I think we should look to remove the distinction between 'stuff that works in PDL' and 'stuff that works in perl'. To do this I guess we need an RFC proposing compact array storage for numeric data. Most of the rest of PDL core is already proposed in one form or another. Stuff like SLATEC support still belongs in external modules, of course. Again, sorry that I can only offer support from the sidelines and not take up the task of writing an RFC. One VERY important thing to remember about the compact data types that PDL deals with is that of smart pointers: e.g. a slice or a diagonal of a matrix is not a copy: it's a smart reference to the originals, and changing the values there will change the originals. This functionality is crucial to have for a good numerical language. So if compact arrays go in, please make sure that implementing such smart pointer arrays is possible, efficient and easy. PDL currently supports affine transformations but other kinds of transforms would be interesting. But to compile to C there need to be few types, unless a JIT compiler is included in the plans for perl 6. Tuomas
RFC17
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:
=head1 IMPLEMENTATION
=head3 Well-Named Global Hashes And Keys
I think if there's one thing we have learned (or should have leanred)
from Perl 5, it's that this sort of global state variable is a
terrible idea regardless of what its name is.
Why is $* deprecated? Because it's dangerous.
Why is $* dangerous?
Because some function eleven calls down in some module you never heard
of that was loaded by some other module might do this:
$* = 1;
which suddenly changes the semantics of *every* regex match in your
*entire* program.
Conclusion: The real problem with $* isn't the name (although the
name is nasty.) The real problem is that it's a global variable with
a global effect, and it changes the meaning of code that is far away.
RFC17 fixes the little problem and leaves the big problem gaping and
festering.
But OK, $* is deprecated, so we can assume that it won't be in Perl 6.
Maybe the real problem has gone away? No. RFC17 specifically
mentions $^W, which has exactly the same problem. Some function
eleven calls down in some module that was loaded by some other module
might do
$^W = 1;
(or $PERL::CORE{warnings} = 1 if you prefer) and suddenly change the
warning behavior of *every* part of your *entire* program. If $* were
not a global, it would be at worst an odd wart, and possibly even a
convenience. Because it is a global, it is a dangerous hazard. $^W
is similar.
$/ is a necessary evil that must be carefully used because it is a
global. If you set $/ and forget to localize the change, the rest of
the program blows up in a bizarre way because *every* filehandle read
operation in (every* part of the program changes behavior. If $/ were
per-filehandle, or if it were lexically scoped, it would be an
unmitigated advantage.
Similarly for each of $\ $, $" $; $# $* $= $^L $^A $@ $^I $^P $^R $^W
and especially the putrid $[.
$| $^ $~ are less problematic because they are per-filehandle.
$. $% $` $ $' $- $+ @+ @- $? $! $^E $$ $[ $^O $^R $^T $^V are less
problematic because they are read-only. Some, like $., are still
problematic, because, for example:
$line = FH;
subr();
print "Line $. is $line";
might work, or it might not.
$0 $ $ $( $) $^C $^D $^F $^H $^M @ARGV are not problems because they
really are global. Each process has one real UID, and only one, so a
global variable for $ is perfectly OK.
$_ is in a class by itself.
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.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC17
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! clap clap clap stomp stomp stomp hats state="flying (Same goes for package variables: $File::Find::name, anyone? Expunge, expunge, expunge.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: DRAFT RFC: Enhanced Pack/Unpack
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 hash array between its name and its value. Given the necessity of maintaining the order of elements, this nomenclature would appear to be inappropriate. From perldata man page: It is often more readable to use the = operator between key/value pairs (the = operator is actually nothing more than a more visually distinctive synonym for a comma): I've seen it used in function parameter lists and other lists, as well as the list of initial values for a hash (which is the example that follows the above statement in the man page). Still, I like the idea of making the relationship more explicit, we could do it this way: [ ['bar','int32'], ['baz','int32'], ['count','int32'] ] We could, indeed. Or, we could use = just as visual sugar to specify the relationship... it does preserve the order! I think I'd prefer that to rectangularly Lispifying things too much. Basic Object Type: 'short' - whatever your computer understands is a short. 'long' - ditto. 'int' - ditto. 'double' - ditto. 'float' - ditto. 'char' - ditto, with the understanding that Unicode makes these characters larger than you would expect. 'byte' - whatever your computer understands is a byte. (Yes, there are some systems that don't use 8 bits to a byte. Not many, but they are there.) 'octet' - specifically 8 bits, regardless of the byte size of your system. I don't have any problem with having names like these. However, the data that is being read may or may not have originated on the computer trying to read it. While you seem to recognize that in "byte" vs "octet", you've eliminated the ability to do that for specifically sized integers (and floats, but cross machine floats are a bigger problem, and probably require a user extension). Likewise, we probably need specifically sized char in addition to "normal" char for the machine: both one byte and two byte (for Unicode, and this one has endianness issues). Theory: The people that want natural sizes "based on the machine" don't deal with moving data from one machine to another, just moving programs from one machine to another. The people that want fixed sizes deal with moving data from one machine to another, and have faced the problems that entails. Having both is OK (but redundant) to the second camp; but leaving out fixed size specifications is not... because then as you move the program from machine to machine you have to adjust the structure definitions to correspond to the actual sizes of the "natural" sizes that this machine supports. Coding the actual sizes in the first place saves that effort. The whole point of this feature is to communicate with data in rigid binary formats; for API calls, "natural" may be better, if it matches the definitions in other languages, for on-disk data structure interpretation, fixed size is better. Either can be used to emulate the other, but the emulation causes problems. Supporting both "natural" and "fixed" sizes seems to be necessary to make everyone happy. And remember, however the structure is specified, when unpacked, it becomes normal, easy and quick to manipulate, ordinary Perl variables. To which we may append a number of different modifiers: Endianness: /d - default, whatever your system uses normally /n - network /b - big /l - little /v - vax (??vax is sufficiently different to require it's own?? Or is this to do with bit order?) I don't speak VAX, but it is my understanding that VAX is different than little endian in some manner. So we need "little" for 80x86/Pentium and others; we need "big" for Motorola 68K and others; we may need VAX is there is something truly different there; "network" is redundant with "big", at the present time. Signedness: /u - unsigned /s - signed We may also allow these modifiers in the definition of the structure, so that the entire structure can be affected, without having to explicitly modify each variable. Both places, that works for me. Non-Standard sizes: /[0-9]+ - The basic object is this many bits long. I strongly suggest that we settle on bits as the standard of length, since if we start mixing bits versus bytes on the basic elements, we're going to confuse the living daylights out of people. Totally agree here. Right now I'm a little concerned how you are suggesting to do arrays of structures with this or similar syntax. The previous technique handled that fine, by nesting arrays of arrays. 4) allow hooks to support non-standard types. sub Structure::define ( type name, frombinarysub, tobinarysub ) sub from_funny ( type_params, binary_var, bit_offset ) # returns ( next_bit_offset,
Re: RFC: Rename local() operator
guard protect Hmm, 'guard' is just as long as 'local'. chaim "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: JSD More words: JSDstore() # put away for the duration of the scope JSDtuck() # Now I lay me down to sleep JSDhide() # I kinda like this one :-) JSDshelve()# probably too loaded JSDstow() # Just sit right back and you'll hear a tale ... JSDbury() # Oh my god! They've killed Kenny! JSD I've changed my mind; my personal favorite is now "hide" -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 37 (v1) Positional Return Lists Considered Harmf
=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 though:
return hash (references) *as well as* lists.
I've proposed that the want() function will be able to distinguish
a HASHREF context (there the return value is used as a hash reference).
Retain the list return (which is convenient why one does know what
(caller(0))[4] does), and have the named return values returned via
a hash reference when such a context is active.
E.g.:
$package = caller; # scalar context
($package, $file, $line, $subname) = caller(0); # list context
$subname = caller(0)-{subname};# hashref context
Damian
Re: RFC 22 (v1) Builtin switch statement
How about adding a new keyword, hmm, 'yield'. :-) if ( grep yield $x==$_, (1,2,3) ) ... chaim "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. 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 that you can write: if ($x in [ 1, 2, 3 ]) ... DCif ( grep $x==$_, (1,2,3) ) ... DC Be nice if it would short-circuit in a boolean context though! DC Damian -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 22 (v1) Builtin switch statement
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. chaim "JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: JH I think we need a general way of short-circuiting out of a grep JH (and other list iterating funcs, if it makes sense...) We may JH need both success and failure short-circuits? It's a pity 'last' JH already has semantics there, not to mention return... -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 42 (v1) Request For New Pragma: Shell
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, 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 28 (v1) Perl should stay Perl.
"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 you missed the point of our arguments. We do need a reminder.
But what is the filter, the model we should look toward.
Perhaps, only Larry can do this. So far most of the requests appear to
be modest extensions of the parser.
The matrix operations. I remember an old basic on some pdp8 that I used
that had it. I needed it at one time or an other, and would have loved
to have it in perl. (Making things easier. The language of Mathematicians)
I've played with APL a long time ago. There were some amazing APL type
JAPHs that I were given in the examples. And they had useful purposes
also. So tell me how different are these operator from
@foo{@list} = @other_list
grep { strange_function } @list
map { even_stranger mapping } @list
Or even the schwartzian transform.
Basicall, they are at least in my eyes, minor extensions to what perl
is.
In my eyes, turning on strict by default, or some of the other fundemental
operational changes are against the feel of perl. Not these additional
operations.
Anyway, keep in your hand.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 25 (v1) Multiway comparisons
"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, etc., etc. I vaguely recall that Larry was against this. (I can't recall if it was ICON itself or the failure model, but then I may very well mis-recall it.) What would the failure model give us. (I read the ICON book a long time ago.) Wouldn't it be a major departure from PERL as PERL. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 34 (v1) Angle brackets should not be used for fi
"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 when this behaviour is used." I think the point is to remove all deprecations. So adding a few seems to be counter-productive. I think what is in the language on day 1 should be there for the long haul. No excess baggage when leave on our journey. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 27 (v1) Coroutines for Perl
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. chaim "s" == skud [EMAIL PROTECTED] writes: s 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. s uri, I fear you may be suffering from a bit of confusion wrt the current s state of sublists. 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. s I admit this isn't really very different in practical terms, but at s least it means that sublists have some consistentcy in their charters s and timelines, and that they all report back to the same place s (-language). -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC17
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 be made available to effect (should that be infect) the value in outer scopes. chaim "MD" == Mark-Jason Dominus [EMAIL PROTECTED] writes: MD I don't want to join the discussion in general, and I'm not on the MD language list. So this is a one-shot manifesto. MD I agree with the goal of RFC17: MD Organization and Rationalization of Perl State Variables MD but I think the implementation ideas are making a terrible mistake. MD Specifically: =head1 IMPLEMENTATION =head3 Well-Named Global Hashes And Keys MD I think if there's one thing we have learned (or should have leanred) MD from Perl 5, it's that this sort of global state variable is a MD terrible idea regardless of what its name is. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC17
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 of these things is a bad idea. It is kinda convenient to be able to mess with things (like $^W) and have them stay messed-with. Tossing that makes some sense from a stricture/no-action-at-a-distance standpoint, but having a quick dirty way to just *do* something is kinda perlish. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Deep copy
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 how this looks, it has some pretty significant ramifications for the internals. What, for example, should happen if you deep-copy a DBI object attached to an Oracle database? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
new lists: perl6-language-flow, perl6-language-io and perl6-language-unlink
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. 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. 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. -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
RFC 10 (v3) Filehandles should use C* as a type pr
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 PROTECTED]
Status: Retracted
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."
Versions 2 and 3 withdraw 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 (Clocal *FH)
or put them in a scalar (Cmy $fh = new FileHandle or the 5.6 Copen $fh,
...), 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 Creadlines 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
Lperlopentut
RFC 41 (v2) Request For New Pragma: Implicit
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 ABSTRACT Perl 6 should add a new pragma called Cimplicit. =head1 DESCRIPTION I am lazy. I am spoiled by the implicit $_. I like the implicit $_. Implicit $_ good. Ugh. (Conversely, some people abhor the implicit $_ while in a strict programming environment, as it tends to add confusion.) I came to the sysadm / programming world in a long, circuitous route. I never programmed with toggle switches. I've never seen a punch card. My first programming was in Commodore 64 Basic. C64 Basic. No safe-signals there, either. ;) It did have one good thing, though. One very useful thing, for lazy people like me. Cprint could be written like C?. It just rolled off the fingers. C10 ?"Port Perl for the 64!". Of course, those days have gone. I've seen the light. I'm a *nix head and JAPH. But how I still hate typing out print. Particularly because I do it so much. Oh, sure, I could play games with HERE docs and the ilk, but I'm too lazy. (Like I posted in a response, I wrangled an input filter to allow me to write C? "Print me.!". But I digress. There should be an Cimplicit pragma that gives new life and meaning to void context constructs. In my case, I want it to print to the default filehandle, (which is also implicit, I might add.) Scoping needs to be tightly controlled, of course. Don't want someone else's void context to show up on your display, now do you? And, of course, it would be defaulted to off. It could continue to ignore constant 0s and 1s. (But those pre-pod embedded comment strings just Bhave to go.) Ideally, I'd like to use it for printing, but I suppose some other lazy person may want to use it for something else. Like, from reading the traffic, to prevent laziness. One of the suggestions was to disallow implicit $_ for functions. That could fit right in with this pragma. It would be on be default, but you could turn it off. =head1 MOTIVATORS Laziness, pure and simple. =head1 IMPLEMENTATION The front-end would have to detect void usage and either arrange to have the results passed to a callback, (in which case, would you know what wantarray() wants to know?) or inject the appropriate term in the optree. In the case of Cno implicit arg, the front-end would have to not assume the implicit $_ as an argument. =head2 SUMMARY OF IMPLEMENTATION I've no real concrete ideas on this, sorry. =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of Cuse implicit and the sematics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What about subs? Backticks? Things that return meaningless printable information, like system()? Cno implicit would put it on the user. After all, he doesn't have to use it. =item * Would C; print the contents of $_ to the default filehandle? ;-) =back =head1 REFERENCES Upcoming RFC on module scoping.
RFC 37 (v2) Positional Return Lists Considered Harmf
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 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 or which is the 4th return value of localtime()? The perlfunc gmtime/localtime 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. =head2 THE AFFECTED FUNCTIONS caller [1] getgrent getgrnam getgrgid gethostbyaddr gethostbyname gethostent getnetbyaddr getnetbyname getnetent getprotobyname getprotobynumber getprotoent getpwent getpwnam getpwuid getservbyname getservbyport getservent gmtime localtime stat [1] I guess the whole semantics and functionality of caller() is severely up for grabs for Perl6. For the get*() mafia, it is also debatable whether aping the C interface is a good thing and worth preserving as such at all. The preferred interface might be tied hashes. This interface might also more naturally support non-POSIX operating systems with their own native semantics, or POSIX operating systems with extended semantics like higher security user databases. =head1 REFERENCES perlfunc File::stat User::grent User::pwent
Re: RFC 37 (v2) Positional Return Lists Considered Harmf
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
RFC 44 (v1) Bring Documentation Closer To Whatever I
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
=head1 ABSTRACT
The current pod has one serious problem: it is very weakly tied to the
whatever it is documenting. A human can make a good guess based on
proximity and content but for more automatic document extraction the
situation is hopeless.
This RFC proposes some syntactical possibilities of binding the
documentation to the things they try to document.
=head1 DESCRIPTION
Both ways of binding the documentation to its main thing and
retrieving the documentation are needed. Below I propose some
possible syntaxes. The proposals are by no means definitive or final,
but the key issue is that the documentation really must be visually
close to its documentee. Any other way is terminally doomed to
failure because then the document and the documentee Bwill drift out
of sync.
=head2 DOCUMENTING A FUNCTION
sub foo "Snarfle the bogogoozer. The first argument is ..." { ... }
=head2 DOCUMENTING THE ARGUMENTS OF A FUNCTION
This example assumes a certain not-yet-existing-or-agreed upon syntax
for "true" named parameters. Pay no attention to details.
sub foo (my $bogogoozer "The victim.", my %options "How to snarfle.")
{ ... }
=head2 DOCUMENTING A LEXICAL VARIABLE
my $literal "How seriously to take the proposal.";
=head2 DOCUMENTING A PACKAGE VARIABLE
$debug_level = 0 "The initial debug level is no debugging, or zero.";
=head2 RETRIEVING THE DOCUMENTATION OF A FUNCTION
print "This is how to snarfle a bogogoozer: ", documentation(\foo), "\n";
This would retrieve and output the string "Snarfle the bogogoozer.
The first argument is ...".
=head2 RETRIEVING THE DOCUMENTATION OF A VARIABLE
print "This is how literally to take this proposal: ",
documentation(\$literal), "\n";
=head1 IMPLEMENTATION
During parsing the documentation needs to be attached to the thing it
belongs to.
=head2 FURTHER IDEAS
If somebody wants to write documentation in several different
languages (and encodings?) a way to tag a piece of documentation with
attributes would be desirable.
Attributes on the documentation could also be used to differentiate
the documentation to several different classes/types/levels.
=head1 REFERENCES
RFC 42 (v1) Request For New Pragma: Shell
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 Perl 6 should add a new pragma called Cshell. =head1 DESCRIPTION The shell that Perl uses for shell interpretation is defined at compile time. Furthermore, it is optimized away when no metacharacters are found within the command string. There are times when one may need (or desire) to change the shell used for interpretation, as well as force shell interpretation, regardless of optimization, for consitency's sake. Perl runs on many platforms. Many of these platforms, either by default, desire, or need, may have multiple command interpreters that Perl may want to interface with by default. (ie, through the use of backticks or system().) Perl is not just a glue language, but a SuperGlue language. I ab^H^Huse Perl to interact with a lot of home-grown command interpreters as either a driver, a hardware controller, or Expect-type engine. It's a lot more DWIMmer when I can operate in that environment, vice the standard OS one. Furthermore, there are times when speed be damned! I need every `` to go through the command interpreter in order to get back consistent results, and I don't want to have to mangle the output string in order to force a metacharacter. It is important, however, that this be lexically scoped. One can't really afford to have some unknown module expect /bin/sh and accidentally send the command to turn on a robot's "Kill Human" mode. =head1 MOTIVATORS Laziness, and perhaps a bit of Hubris. =head1 IMPLEMENTATION This was an easy hack in Perl 5, except for the scoping issue. Ideally, there'd be a -force flag to check, and a method to change the location of the shell, the shell arguments, and perhaps what is defined as a shell metacharacter. =head2 SUMMARY OF IMPLEMENTATION See above. I hacked this for Perl 5 in about two minutes, minus the scoping, which I never could figure out. :-( =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of Cuse shell and the semantics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What if the interfaced modules returns things that `` and system() don't expect? =back =head1 REFERENCES Upcoming RFC on module scoping.
RFC 45 (v1) || should propagate result context to bo
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 =head1 ABSTRACT Currently the expression lvalue = expr_A || expr_B evaluates Cexpr_A in scalar context, regardless of the type of Clvalue, only propagating list or scalar context to Cexpr_B. This proposal is that the context of Clvalue should be propagated to Cexpr_A as well. =head1 DESCRIPTION It would be nice to be able to say @a = @b || @c instead of having to resort to @a = @b ? @b : @c The reason that it is not currently possible is that C@b (or the list expression in its place) has to be evaluated in scalar context to determine whether to evaluate C@c, and that propagating context to C@b would require reevaluating it, which might have undesirable side effects (instead of C@b, it might be Cdecrement_balance()). =head1 IMPLEMENTATION It seems that it ought to be possible to evaluate something in a list context and test whether there are any entries in the resulting list without having to reevaluate the expression in a scalar context. The work-around with the trinary operator also evaluates C@b twice. There is obviously no need to modify the behavior of the C operator. =head1 REFERENCES Lperlop/"C-style Logical Or"
Re: Perl6 Prject Plan / Roadmap
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 this in the timeline's -- H.Merijn Brand using perl5.005.03 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.020 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/ Member of Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing throughtie.)
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.
I hate suggesting bad ideas (but I think this may be one), but has any
thought been given to a "pre-compiler" ala Java?
I know alot of thought is being given to a true compiler, but I'm not
convinced this is feasible. Maybe a pre-compiler that could do some
optimization and then dump the thing off as a ".bpl" (binary perl?)
program. This would still have to be run through the interpreter, but
would be much faster because of pre-optimization. The main difference
between us and Java is that we wouldn't *have* to pre-compile, but only
if speed was crucial (key CGI apps, for example). We already sort of
have hooks for this ability with dump/undump.
Granted, this is probably a really bad idea. Feel free to shoot it down
(my feelings *won't* be hurt). :-)
-Nate
Re: Language RFC Summary 4th August 2000
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 already tossed out. That's where the current format format (so to speak) runs you into trouble. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Prject Plan / Roadmap
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 the new language for their modules. I cannot find this in the timeline's You'll get it at the same time as everyone else, since it'll be out as soon as possible in general. (Assuming you don't mind working with alpha code...) The plan is for an alpha by next TPC. How alpha is, as always, an open question, given that's almost a year off. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 27 (v1) Coroutines for Perl
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 to pass events around instead, so: I'm proposing that events and threads be dropped in lieu of coroutines. Not gonna happen. Tk and signals, at the very least, will see to that. As far as I am aware any multi-processing problem can be reduced to message passing and these "co routines as IO" are just one stab at that. For example occurance of a signal could just "print" down the handler "pipe", Likewise mouse click could just "print" down the Tk-ish ButtonPress-1 pipe. It is the "return path" that bothers me - and of course the thread behind the co routine still has locking issues if it updates "global" state. -- Nick Ing-Simmons
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing throughtie.)
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 scalar @vars;
}
doesn't change its args or any globals, so can be safely optimized around
to some extent.
I hate suggesting bad ideas (but I think this may be one), but has any
thought been given to a "pre-compiler" ala Java?
I know alot of thought is being given to a true compiler, but I'm not
convinced this is feasible. Maybe a pre-compiler that could do some
optimization and then dump the thing off as a ".bpl" (binary perl?)
program. This would still have to be run through the interpreter, but
would be much faster because of pre-optimization. The main difference
between us and Java is that we wouldn't *have* to pre-compile, but only
if speed was crucial (key CGI apps, for example). We already sort of
have hooks for this ability with dump/undump.
Granted, this is probably a really bad idea. Feel free to shoot it down
(my feelings *won't* be hurt). :-)
This is a really good idea, honestly. One of The Plans is to be able to
freeze the final bytecode that would be handed to the interpreter off to
disk instead. Should (if we do our jobs right) allow for faster startup,
and it should also let us do more aggressive optimizations than we do now.
Not because this method lends itself to better optimizations (freezing
parts of programs, like modules, actually hurts optimization some), but
because we have more *time* to optimize.
I don't, for example, want to pay an extra 30 seconds on each program
invocation to run the code through the optimizer. I would be perfectly
happy to do so, though, if the resulting code is frozen to disk so I didn't
pay it the next time.
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
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 function, they know that each is referring to the same thing. Yes, even I understand that! Maybe this is the correct use for the prefix "*" that gets freed up by removing typeglobs ??? "_" would be OK, I suppose, but could conflict with some programming styles I've seen, with leading "_" in variable names. I was waiting to learn more about currying before I raised the issue of repeated use of placeholders, but that seemed to be missing in this RFC. Truly a candidate for being called a "whatzitz whatzitz"! -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
