If you thought there were too many PEPs...
...yow: the Perl community is really going overboard in proposing enhancements: [from the Perl "daily" news]
[3] Perl 6 RFCs Top 150 Mark; New Perl 6 Lists Added [Links]
The number of [4]Perl 6 RFCs hit 161 today. The 100th RFC was [5]Embed full URI support into Perl by Nathan Wiger, allowing URIs like "file:///local/etc/script.conf" to be passed to builtin file functions and operators. The 150th was [6]Extend regex syntax to provide for return of a hash of matched subpatterns by Kevin Walker, and the latest, 161, is [7]OO Integration/Migration Path by Matt Youell.
New [8]Perl 6 mailing lists include perl6-language- sublists objects, datetime, errors, data, and regex. perl6-bootstrap is being closed, and perl6-meta is taking its place (the subscriber list will not be transferred). [...] 3. http://www.news.perl.org/perl-news.cgi?item=967225716%7C10542 4. http://dev.perl.org/rfc/ 5. http://dev.perl.org/rfc/100.pod 6. http://dev.perl.org/rfc/150.pod 7. http://dev.perl.org/rfc/161.pod 8. http://dev.perl.org/lists.shtml
-- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367
On Fri, 25 Aug 2000, Greg Ward wrote:
The number of [4]Perl 6 RFCs hit 161 today... New [8]Perl 6 mailing lists include perl6-language- sublists objects, datetime, errors, data, and regex. perl6-bootstrap is being closed, and perl6-meta is taking its place (the subscriber list will not be transferred).
I've heard from several different sources that when Guy Steele Jr was hired by Sun to help define the Java language standard, his first proposal was that the length of the standard be fixed --- anyone who wanted to add a new feature had to identify an existing feature that would be removed from the language to make room. Everyone said, "That's so cool --- but of course we can't do it..." Think how much simpler Java would be today if... ;-) Greg
On Fri, Aug 25, 2000 at 02:30:53PM -0400, Greg Wilson wrote:
was that the length of the standard be fixed --- anyone who wanted to add a new feature had to identify an existing feature that would be removed from the language to make room. Everyone said, "That's so cool --- but of
Something similar was done with Modula-3, as GvR is probably well aware; one of the goals was to keep the language spec less than 50 pages. In the end I think it winds up being a bit larger, but it was good discipline anyway. --amk
greg wrote:
I've heard from several different sources that when Guy Steele Jr was hired by Sun to help define the Java language standard, his first proposal was that the length of the standard be fixed.
"C. A. R. Hoare has suggested that as a rule of thumb a language is too complicated if it can't be described precisely and readably in fifty pages. The Modula-3 committee elevated this to a design principle: we gave ourselves a "complexity budget" of fifty pages, and chose the most useful features that we could accommodate within this budget. In the end, we were over budget by six lines plus the syntax equations. This policy is a bit arbitrary, but there are so many good ideas in programming language design that some kind of arbitrary budget seems necessary to keep a language from getting too complicated." from "Modula-3: Language definition" http://research.compaq.com/SRC/m3defn/html/complete.html </F>
[Greg Ward]
...yow: the Perl community is really going overboard in proposing enhancements: ... 4. http://dev.perl.org/rfc/
Following that URL is highly recommended! There's a real burst of creativity blooming there, and everyone weary of repeated Python debates should find it refreshing to discover exactly the same arguments going on over there (lazy lists, curried functions, less syntax, more syntax, less explicit, more explicit, go away this isn't stinking LISP, ya but maybe it oughta be, yadda yadda yadda). Except the *terms* of the debate are inverted in so many ways! For example, this is my favorite Killer Appeal to Principle so far: Perl is really hard for a machine to parse. *Deliberately*. If you think it shouldn't be, you're missing something. Certainly a good antidote to Python inbreeding <wink>. Compared to our PEPs, the Perl RFCs are more a collection of wishlists -- implementation details are often sketchy, or even ignored. But they're in a brainstorming mode, so I believe that's both expected & encouraged now. I was surprised by how often Python gets mentioned, and somtimes by how confusedly. For example, in the Perl Coroutines RFC: Unlike coroutines as defined by Knuth, and implemented in laguages such as Simula or Python, perl does not have an explicit "resume" call for invoking coroutines. Mistake -- or Guido's time machine <wink>? Those who hate Python PEP 214 should check out Perl RFC 39, which proposes to introduce ">" LIST "<" as a synonym for "print" LIST My favorite example: perl -e '><><' # cat(1) while, of course ><; prints the current value of $_. I happen to like Perl enough that I enjoy this stuff. You may wish to take a different lesson from it <wink>. whichever-it's-a-mistake-to-ignore-people-having-fun-ly y'rs - tim
On Sun, Aug 27, 2000 at 05:57:42AM -0400, Tim Peters wrote:
[Greg Ward]
...yow: the Perl community is really going overboard in proposing enhancements: ... 4. http://dev.perl.org/rfc/
Following that URL is highly recommended!
Indeed. Thanx for pointing it out again (and Greg, too), I've had a barrel of laughs (and good impressions, both) already :)
I was surprised by how often Python gets mentioned, and somtimes by how confusedly.
Well, 'python' is mentioned explicitly 12 times, in 7 different RFCs. There'll be some implicit ones, of course, but it's not as much as I would have expected, based on howmany times I hear my perl-hugging colleague comment on how cool a particular Python feature is ;)
For example, in the Perl Coroutines RFC:
Unlike coroutines as defined by Knuth, and implemented in laguages such as Simula or Python, perl does not have an explicit "resume" call for invoking coroutines.
Mistake -- or Guido's time machine <wink>?
Neither. Someone elses time machine, as the URL given in the references section shows: they're not talking about coroutines in the core, but as 'addon'. And not necessarily as stackless, either, there are a couple of implementations. (Other than that I don't like the Perl coroutine proposal: I think single process coroutines make a lot more sense, though I can see why they are arguing for such a 'i/o-based' model.) My personal favorite, up to now, is RFC 28: Perl should stay Perl. Anyone upset by the new print statement should definately read it ;) The other RFCs going "don't change *that*" are good too, showing that not everyone is losing themselves in wishes ;) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
thomas wrote:
My personal favorite, up to now, is RFC 28: Perl should stay Perl.
number 29 is also a good one: don't ever add an alias for "unlink" (written by someone who have never ever read the POSIX or ANSI C standards ;-) ::: btw, Python's remove/unlink implementation is slightly broken -- they both map to unlink, but that's not the right way to do it: from SUSv2: int remove(const char *path); If path does not name a directory, remove(path) is equivalent to unlink(path). If path names a directory, remove(path) is equi- valent to rmdir(path). should I fix this? </F>
btw, Python's remove/unlink implementation is slightly broken -- they both map to unlink, but that's not the right way to do it:
from SUSv2:
int remove(const char *path);
If path does not name a directory, remove(path) is equivalent to unlink(path).
If path names a directory, remove(path) is equi- valent to rmdir(path).
should I fix this?
That's a new one -- didn't exist when I learned Unix. I guess we can fix this in 2.1. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
Hi, effbot:
btw, Python's remove/unlink implementation is slightly broken -- they both map to unlink, but that's not the right way to do it:
from SUSv2:
int remove(const char *path);
If path does not name a directory, remove(path) is equivalent to unlink(path).
If path names a directory, remove(path) is equi- valent to rmdir(path).
should I fix this?
BDFL:
That's a new one -- didn't exist when I learned Unix.
Yes, this 'remove()' has been added relatively late to Unix. It didn't existed for example in SCO XENIX 386 (the first "real" OS available for relatively inexpensive IBM-PC arch boxes long before the advent of Linux). Changing the behaviour of Pythons 'os.remove()' on Unices might break some existing code (although such code is not portable to WinXX anyway): pf@artcom0:ttyp3 ~ 7> mkdir emptydir pf@artcom0:ttyp3 ~ 8> python Python 1.5.2 (#1, Jul 23 1999, 06:38:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
import os try: ... os.remove('emptydir') ... except OSError: ... print 'emptydir is a directory' ... emptydir is a directory
I guess we can fix this in 2.1.
Please don't do this without a heavy duty warning in a section about expected upgrade problems. This change might annoy people, who otherwise don't care about portability and use Python on Unices only. I imagine people using something like this: def cleanup_junkfiles(targetdir) for n in os.listdir(targetdir): try: os.remove(n) except OSError: pass Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
On Sun, 27 Aug 2000, Fredrik Lundh wrote:
btw, Python's remove/unlink implementation is slightly broken -- they both map to unlink, but that's not the right way to do it:
from SUSv2:
int remove(const char *path);
If path does not name a directory, remove(path) is equivalent to unlink(path).
If path names a directory, remove(path) is equi- valent to rmdir(path).
should I fix this?
1. Yes. 2. After the feature freeze. -- Moshe Zadka <moshez@math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez
from SUSv2:
int remove(const char *path);
If path does not name a directory, remove(path) is equivalent to unlink(path).
If path names a directory, remove(path) is equi- valent to rmdir(path).
should I fix this?
1. Yes. 2. After the feature freeze.
Agreed. Note that the correct fix is to use remove() if it exists and emulate it if it doesn't. On Windows, I believe remove() exists but probably not with the above semantics so it should be emulated. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
participants (9)
-
Andrew Kuchling -
Fredrik Lundh -
Greg Ward -
Greg Wilson -
Guido van Rossum -
Moshe Zadka -
pf＠artcom-gmbh.de -
Thomas Wouters -
Tim Peters