Re: inline mania
Sam Tregar [EMAIL PROTECTED] wrote: On Tue, 1 Aug 2000, John Tobey wrote: The people here are rightly skeptical about the effectiveness of using the 5.6 code base as a starting point for v6, but I have a pretty clear vision of how to do it, and I am committed to giving it a try, even if no one else will. In fact, I'll give you all a tentative schedule: Wait, you're going to develop Perl 6 ALONE? Wasn't this going to be "the community's rewrite of Perl"? Shouldn't you be trying to rally support for your vision before issuing schedules? Not really. I'm going to START developing MY IDEA of how Perl 6 might work. Very likely, I'll stop or merge with someone else's ideas along the way. The schedule is just to get something down, to start fleshing out my idea and maybe provoke other people into starting on their own visions, as Simon Cozens has (though he seems to deny it) done with GLib and Sapphire. I'm not trying to knock you - I'm not at all against hearing you plans and possibly helping out. This just seems like a pretty strange way to approach a community effort. 15 August 2000 - detailed draft spec to perl6-internals. 31 August 2000 - revised spec after discussion. What? You're expecting all the various perl6-* lists to come up with final RFCs be the end of the month? And you're expecting to have Larry's final plans by then? Well, I'll read RFC's as they appear and adjust to them as they are approved, but the stuff I want to do now does not need to wait. This sounds hopeful, but mostly unfounded. Without starting with threading and Unicode as primary features you're going to be fighting an uphill battle ala Perl 5. This I hope to address in my first architecture document. Thanks for the comments. -John
Re: RFC: Implementation of Threads in Perl (v1)
Bryan C. Warnock writes: The librarian bounced, so sending this internals way. Sorry about that bounce. It's set up now. I'm still setting up the repository (should have done that *before* publishing the RFC format, I guess :-). Optimistic ETA: tomorrow. If it's not up by then, I'll fall back to a simple web site. Nat
Re: inline mania
On Tue, Aug 01, 2000 at 06:10:53PM -0400, John Tobey wrote: Nick Ing-Simmons [EMAIL PROTECTED] wrote: By all means have a go at Topaz-II But it won't be 'Perl 6' unless it implements what perl-language decides that _is_. Agreed. It won't even remotely resemble 'Perl 6' (as opposed to Perl 5) until it's in a position to start changing the lexer, at least several months from now. So please, follow Chips wise lead, don't call your work Perl 6. Tim.
Re: inline mania
Tim Bunce [EMAIL PROTECTED] wrote: So please, follow Chips wise lead, don't call your work Perl 6. It's called Pickle. "Andy Wardley" [EMAIL PROTECTED] wrote: Indeed. XS is hard, fast, dirty and ugly (in a sickly, beautiful kinda way), but there's nothing to stop you from wrapping it all up into a less efficent, but prettier API (with the possible exception of reference counting). There is no reason for it to be any less efficient (other than compilers' botching of `inline'). I favor leaving efficiency as a user option. In return for efficiency, we offer binary independence of interpreters. Pickle provides (or will provide) three modes of compiling: Default - perl.h is not included - total bincompat Refcount Cheat - the only bit structure knowledge is sv_refcount Gung Ho - all Default API functions are inline to the level of Perl 5's API You can select any of them with a single conditional. I believe Perl 6 (and v5.8) should support three interfaces along these lines, whether or not any Pickle code is involved. -John
Feature request: Relocatable perl
I don't think it is worth generating a RFE for this, but I'd like to see the ability to relocate or install perl in some place other than the initial install location without everything breaking. This will require cleverness in the manipulation of the search paths for both perl modules and shared objects/DLLs. Alan Burlison
Re: RFC: Implementation of Threads in Perl (v1)
At 10:59 AM 8/2/00 -0400, Chaim Frenkel wrote: I wont comment on the rest. But Larry has already assigned/blessed 'our' for this usage. (vs. my for pure thread local lexical.) I don't think Larry's weighed in on this one way or another lately. My bet is thread-shared data will get a shared attribute: my $foo : shared; possibly with some sort of dynamic sharing allowed. (i.e. you stuff a ref to an unshared scalar into a shared array so the unshared scalar becomes shared) "BCW" == Bryan C Warnock [EMAIL PROTECTED] writes: BCW =item * BCW The Thread module should add a Cglobal keyword or function that explicitly BCW access a variable in the program-global stash. BCW Cglobal $main::foo = $foo; # Let another thread know what my $foo is. BCW Cglobal $main::foo = \$foo; # Share my local foo. Dangerous! BCW C$foo = global $main::foo; # Localize this instance of $main::foo. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Feature request: Relocatable perl
On Wed, Aug 02, 2000 at 02:58:37PM +0100, Graham Barr wrote: On Wed, Aug 02, 2000 at 02:56:54PM +0100, Alan Burlison wrote: I don't think it is worth generating a RFE for this, but I'd like to see the ability to relocate or install perl in some place other than the initial install location without everything breaking. This will require cleverness in the manipulation of the search paths for both perl modules and shared objects/DLLs. Well I think it is worth an RFC (not that I have time to write one just now) I agree (and likewise). Volunteers? Tim.
Re: inline mania
On Wed, Aug 02, 2000 at 05:39:19PM +0100, Tim Bunce wrote: On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote: Reference counting is going to be a fun one, that's for sure. I'd like the interface to be something like: stat = perl_get_value(sv *, int what, destination) And what type is perl_get_value declared as returning? Well if what is stating I want a string, it could be a length. Or it could just be a flag if the value was undef, or ... I can't imagine actually using it. Let's forget that one till we know more about how Svs will be implemented. I agree. Graham.
Re: Feature request: Relocatable perl
On Wed, 2 Aug 2000, Ken Fox wrote: Tim Bunce wrote: Alan Burlison wrote: the ability to relocate or install perl in some place other than the initial install location without everything breaking. Volunteers? XEmacs does this very well. Can an RFC just say "do what xemacs does" or does it have to be standalone? You've always been able to do this just fine with perl5 too. I've yet to see an example where editing the binaries didn't work. And I'd be very surprised to see anything more portable. After all, if you're using a shared libperl.so (or its perl6 equivalent), the system's loader ld will have encoded the original location of libperl.so somehow into the perl binary and you've got to change it on installation. It's hard for me to see how anything about the perl6 internals could possibly alleviate the need to call ld(1) somewhere in the build process, so I think this matter is off-topic for -internals. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Summary...tell me where I'm worng...
Graham Barr writes:
Why would the fuzzy regex not be done this way ?
I have some small objections:
I think one regexp syntax with potentially wildly variable
interpretations is a dangerous thing. If we want fuzzy
regexp matching, either put it into the core's re engine
or make it a module that doesn't use =~ and qr//.
I also think that lexically scoped RE engines are useless.
You want the engine scoped to the pattern, so you can mix
and match fuzzy with traditional (e.g., search engine has
box for pattern and buttons for regular RE or fuzzy, and
all you need to do is say:)
$pattern = param("pattern");
if (param("fuzzy")) {
$re = qr/$pattern/f;
} else {
$re = qr/$pattern/;
}
# ...
while (FILE) {
print if /$re/;
}
My big objection to a dynamically loadable core is my
experience (admittedly limited) with GNOME and Mozilla.
They're big Big BIG ... fat Fat FAT ... pigs Pigs PIGS.
I see the plethora of componentized libraries as part of
the problem. I fear Perl becoming a big fat pig too.
Nat
Re: Stuff in core (was Re: date interface, on language (wasRe: perl6 requirements, on bootstrap))
Dan Sugalski wrote: I wanted to do this not so much to reduce the size of the core (They're not *that* much code) as to reduce the number of opcodes being used. I really, *really* want to trim down the opcode list. If we reduce the number of opcodes, we need to consider the performance impact -- perl ops run a *lot* of machine instructions and reducing the number of them might mean more ops have to run in order to accomplish the same thing as before. There is a nice paper "The Structure and Performance of Interpreters" by Romer, Lee, et al. that compares Java, Perl and Tcl. They ran them on a hardware simulator so they could measure things like pipeline stalls, cache misses and a whole bunch of interesting things. One of the reasons Perl performed well is that it spent a lot of time in what they called native code, i.e. not decoding and dispatching ops. I wouldn't mind reducing the number of ops if (whatever replaces XS) can be called as fast as an op. Right now the performance difference between an op and an XSUB is horrible. - Ken
RE: inline mania
Brent Fulgham [EMAIL PROTECTED] writes: Having thought about it a bunch more (because of this) I'm proposing we let the compiler decide. The caller doesn't know enough to make that decision. Read carefully. I said we *let* the caller decide, not *make* the caller decide. What, specifically, disturbs you about my proposal? The 'inline' keyword is just a hint to the compiler. If optimization is turned off, no inlining is done. If optimization is on, the compiler may or may not decide to inline. Performance on different compilers will vary. To repeat: Even if I say "inline" on everything, the compiler is free to disregard that if its optimization routines decide not to. (Also, if I fail to say "inline" on something, the compiler may decide to inline if optimization is active). So aren't we all saying the same thing? I don't think so - it is a question which way we code the source: A. Use 'inline' every where and trust compiler not to do what we told it if it knows better. B. No inline hints in the source and trust the compiler to be able to do the right thing when prodded with -O9 or whatever. C. Make "informed" guesses at to which calls should be inlined. My view is that (B) is the way to go, aiming for (C) eventually, because (A) gives worst-case cache purging. -Brent -- Nick Ing-Simmons
Re: Feature request: Relocatable perl
[EMAIL PROTECTED] wrote:
Graham Barr wrote:
Well I think it is worth an RFC (not that I have time to write one just now)
If only to suggest some sample implementations. Do other languages do it ?
If so how ?
Ok, Ok, I'll do a RFC then... :-)
Actually the only thing affected by LD_LIBRARY_PATH is libperl.so, as
modules are loaded in by dlopen() or equivalent, so the full path in
that case is specified in the call to dlopen().
Solaris 7 onwards has a nice linker feature called $ORIGIN. This allows
the location of run-time linker dependencies to be specified relative to
the location of the executable.
Both Windows and Linux can swing this, too. I believe linux (GNU
Libc, to be precise) uses $ORIGIN in a Solaris-compatible way.
I don't mean to imply, however, the binediting perl has no place.
-John
This is probably best illustrated with
a simple example:
$ pwd
/tmp/app
$ cat bin/main.c
extern void hi();
int main() { hi(); }
$ cat lib/hi.c
#include stdio.h
void hi() { printf("hi!\n"); }
$ cc -G -K pic -o lib/libhi.so lib/hi.c
$ cc -Llib -R '$ORIGIN/../lib' bin/main.c -o bin/main -lhi
$ ldd bin/main
libhi.so = /tmp/app/lib/libhi.so
libc.so.1 = /usr/lib/libc.so.1
libdl.so.1 =/usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
$ bin/main
hi!
$ cd ..
$ mv app somewhere_else
$ ldd somewhere_else/bin/main
libhi.so = /tmp/somewhere_else/lib/libhi.so
libc.so.1 = /usr/lib/libc.so.1
libdl.so.1 =/usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
$ somewhere_else/bin/main
hi!
Another option for ELF based platforms that lack $ORIGIN (i.e.
everything other than Solaris AFAIK) would be to use the (standard?)
libelf library to write a little application that tweaked the RPATH in
the executable appropriately when perl is installed somewhere else other
than the default location. I think this would be far preferable to the
currently used horrible hacks involving either LD_LIBRARY_PATH or
greping and patching the executable.
--
Alan Burlison
Re: Feature request: Relocatable perl
Graham Barr wrote: It is not just libraries, but also the perl @INC that needs to be dynamic Yes, but that seems a bit more tractable - surely we could fiddle with @INC based on the location of the perl interpreter? -- Alan Burlison Solaris Kernel Development, Sun Microsystems
Re: Feature request: Relocatable perl
Insofar as you can pretend to make a good guess at that--perhaps. On Linux: /proc/self/exe What good does that do you? You can't go ../foo with that. It doesn't tell you the real name, just the dev,ino. And it's a nonportable answer that cannot be reproduced everywhere that Perl runs. --tom
Where to get RFCs?
It appears Dan posted some internals RFCs, and due to some trouble with my subscription request, I didn't see them. I realize that I can get them out of the archives if I dig, but is there a WWW site yet where all RFCs are being kept? I looked around http://www.perl.org/perl6, but didn't see them. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: C# (.NET) has no interpreters
Joshua N Pritikin wrote: Of course perl6 can retain both execution models (op-tree native code), but perhaps the emphasis should be on optimized native code. The Kaffe java VM uses a native code JIT and they've had trouble getting decent performance. From their own web page (www.kaffe.org): | Kaffe's current performance, despite the fact that Kaffe features a JIT | compiler, is rather weak. While we do not have hard data, we would | estimate that Kaffe performs about as good or only slightly better than | the JDK 1.1.7 interpreter on a platform such as Linux. | Kaffe's Just-in-time compiler does not perform any | optimizations. This leads to a large number of emitted machine | code instructions per bytecode instruction, many of them | unnecessary and expensive loads and stores. perl5 is interpreter-centric with native code generation bolted on well into the development lifecycle. I'd prefer us to tackle native code generation using C as the intermediate language instead of a JIT. It's more portable, simpler and takes advantage of all the C compiler optimizations. I'm not looking for Perl 6 to be a Java/Applet replacement. Is that really where we want to go? On the other hand, compile-time variable typing seems eminently relevant. There are several threads trying to tackle this problem right now. I'm starting to think that mailing lists are poor substitutes for face-to-face brain storming. - Ken
Re: C# (.NET) has no interpreters
On Wed, 2 Aug 2000, Kevin Scott wrote: While C might be fine and dandy for getting o.k. native code w/o too much implementation effort, I think that it might be worth the effort to implement a JIT compiler for the perl interpreter's intermediate language. Given the number of OSes and chip architecture perl runs on, this is a daunting task, and I don't think it should be a target for the core development. Alternate backend, sure, but not a primary target. We might want to leave that to the various OS vendors for now. Most of 'em handle the high-performance JITs for their systems, and perl's as important in some ways as Java. Besides, I can guarantee that the folks in Dec engineering know the Alpha far better than anyone else we have handy does, and the same can probably be said for the other chips. (Well, we've got Jeff from HP and Alan from Sun, but they count as vendor folks...) Dan
Re: Where to get RFCs?
On Wed, 2 Aug 2000, Bradley M. Kuhn wrote: It appears Dan posted some internals RFCs, and due to some trouble with my subscription request, I didn't see them. I realize that I can get them out of the archives if I dig, but is there a WWW site yet where all RFCs are being kept? http://tmtowtdi.perl.org/rfc/ (will soon be http://dev.perl.org/rfc/) - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
Synopsis: C# article
From: Larry Wall [mailto:[EMAIL PROTECTED]] Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. http://windows.oreilly.com/news/hejlsberg_0800.html Here are my notes from the article on what C# offers: C# - multilingual - deep object-orientation - object-simplification - stays close to C++ in design: operators, keywords, statements, enums, operator overloading, type conversions, structure for name spaces - component oriented o first class language constructs: properties, methods, events, attributes (typed extensible metadata), documentation (XML) o everything as an object o boxing/unboxing: value - object conversion o only one kind of class (always GC'd) - code as embeddable self-describing self-contained unit: no headers, IDL's, GUID's, or complex interfaces - notion of safe/unsafe code o safe code runs in managed 'boxes' requires establishment of "trusts" to allow unsafe code exec o unsafe code uses: C inline code, pointers, casts, protect memory from GC runs in managed spaced, i.e., method calls can determine if object is live without crossing marshalling boundary - strong support for HTTPD, HTML, XML, COM (other MS glue), importing from existing shared libraries - modern mark and sweep GC: o closer relationship with code o code needs to be more descriptive: where and how memory utilized - The platform, language, and runtime o platform = .Net can implement multiple programming languages maintain common shared api's unification of programming models allows compilation of scripting languages JVM != .Net IL (Intermediate Language) x can generate native or IL from source x can generate native from IL at install x can do just-in-time at runtime x no interpreters, one-pass conversion to machine code x IL is type neutral, type is inferred from arguments pushed on the stack o language = C# - Why C#? o C++ is too complicated o Java's missing features - No built-in regex (it in the base class libraries) - Namespace o separation between physical packaging and logical naming - Generic Programming possibly in future release o generics understood by underlying runtime o instantiation at runtime o no 'baking' types into instruction stream in the IL - C# submitted to ECMA for standardization - uses SOAP and XML for buidling distributed applications in a loosely connected stateless fashion. I.e., to overcome state dependencies in CORBA and RMI. - attributes o can add declaritive information to types and members public/private transactable serializable as XML web service o can be added to classes and fields within classes
RFC 5 (v1) Multiline Comments for Perl.
=head1 TITLE Multiline Comments for Perl. =head1 VERSION Maintainer: Michael J. Mathews [EMAIL PROTECTED] Date: 01 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 5 =head1 ABSTRACT Unlike many programming languages Perl does not currently implement true multiline comments. This can be confusing/tedious to programmers. This could be solved by adding a syntax to Perl 6 that would allow for true multiline comments. =head1 DESCRIPTION Comments are important to programmers as a way of documenting their code and for debugging purposes. While it is true to add formatted documentation to perl using POD tags, this can be overkill if a programmer simply wishes to add lines of information here and there that are not intended to be public. In fact crafty programmers can even simulate multiline comments using POD tags, but this seems like a misuse of a feature intended for another purpose, and can interfere with real PODs in a script. =head1 IMPLEMENTATION Perl currently allows for sigle-line comments using the pound-symbol "#". Any implementation of a Perl multline comment should feel similar to this. However (ideally) the multline syntax would be unique enough so that it would not conflict with older scripts using the literal "\#" (in a regex for example) or in any single-line comment of arbitrary text. =head2 Nesting Since multiline comments will have a beginning and an ending it will be possible to nest and overlap commented sections of perl. Nesting and overlapping should be allowed and supported. In the case of nesting, the outermost comment is enforced, in the case of overlapping the comments should be treated as if they were joined. In the case of a single-line comment overlapping a multiline comment, the multiline would end the sigle-line comment and would in all other ways take precedence. =head2 Proposal Using a two-character syntax to start and end a multiline comment seems to be a good way to satisfy both the desired similarity to "#" and the desired uniqueness to avoid collision with real single-line quotes. I would suggest a (# many lines of comment #) syntax: this is not ignored; neither is this; (# this is a multiline comment so it IS ignored #) but this is not ignored; It would be very rare to find the "(#" or "#)" character combination in a perl script being used as part of a single-line comment, and yet it is an intuative extension of "#" idea. =head1 REFERENCES
RFC 1 (v1) Implementation of Threads in Perl
=head1 TITLE Implementation of Threads in Perl =head1 VERSION Maintainer: Bryan C. Warnock [EMAIL PROTECTED] Date: 01 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 1 =head1 ABSTRACT Perl 6 should be built around threads from the beginning. =head1 DESCRIPTION Perl 5 attempted (with relatively good success) to implement threads atop the current architecture. It did, unfortunately, leave several gaps, traps, and "features" in heavy concurrency uses. These weaknesses could be fixed if Perl was built with threading from the start. All Perl programs are threaded. Most just only have one. =head1 MOTIVATORS Impatience, Hubris, and Laziness, in that order. =head1 IMPLEMENTATION Attempt to build-in thread constructs for the internals, while allowing a Thread module to safely and robustly add user thread constructs, while not making things bad for the single thread folks. =head2 SUMMARY OF IMPLEMENTATION =over 4 =item * Create an additional pseudo-global stash, one per thread created, that is local to that thread. This stash would be the default space for non- lexical variables. C$main::foo == C$foo within one thread, while C$main::foo != C$main::foo in different threads. There need be no way to specify the particular thread-space, as it would be visible only to the owning thread. =item * The Thread module should add a Cglobal keyword or function that explicitly access a variable in the program-global stash. Cglobal $main::foo = $foo; # Let another thread know what my $foo is. Cglobal $main::foo = \$foo; # Share my local foo. Dangerous! C$foo = global $main::foo; # Localize this instance of $main::foo. =item * The Thread module should, on inclusion, also set the optree flag that triggers mutex locking on variables within the perl core itself. (As differentiated by a user-created and controlled mutex.) This is to guarantee that the above constructs will actually work - user created race conditions aside. =item * Populate the thread-space stash with the built-ins, vice the program global stash. Very few of the built-ins are meaningless in this threaded construct, most are truly independent, and those that aren't, like $^O, should probably be read-only anyway. =back =head2 IMPACT =over 4 =item * Impact on Perl on a non-thread-supporting architecture. None. (The mutex locking code would be no-opped out, the Thread module would fail on inclusion, preventing any of the global semantics from being invoked. The thread space would appear to the program to be a standard global stash.) =item * Impact on Perl built for non-threaded use. None. Same as above. =item * Impact on a single-threaded program under a multi-threaded Perl. None, for the above reasons. (There would be an additional flag check, vice, I believe, automatic mutex locking under the current scheme.) =item * Impact on multi-threaded scripts under a multi-threaded Perl. Some. Mutex locking would occur much as it does today. Current Perl scripts, without the knowledge of global versus thread space would find data-sharing broken. Threads have been declared experimental, and I believe the benefits of simplifying threads in general outweigh the heartache of those (who would benefit) that would have to change their programs. =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of Cuse Thread and the sematics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * Mutex locking of a hash or array, and the scalars they contain, and vice versa? =item * Mutex locking of a reference and the referree. =item * Limitations or assumptions on threading schemes other than those in pthreads, due to the author's lack of experience with anything but. =back =head1 REFERENCES None, currently.
Re: RFC: On-the-fly tainting via $^T
On Wed, Aug 02, 2000 at 11:29:40AM -0400, Dan Sugalski wrote: I was figuring the taint/notaint pragma would control taint checking, while -T would control taint setting. Probably not the best way--might be worth unconditionally setting the taint status so a use/no taint would do the right thing. Sounds reasonable. Graham.
Re: RFC Archive
On Wed, Aug 02, 2000 at 10:09:04PM -0600, Nathan Torkington wrote: I'm about to push the button that will send my private set of RFCs off to the archive and mail them to perl6-announce. Fingers crossed. Hooray!! If I've forgotten your RFC, please send it to [EMAIL PROTECTED] In the future, if you want to submit an RFC mail it to [EMAIL PROTECTED] only. http://tmtowtdi.perl.org/rfc/meta/ says that you should send your RFCs to [EMAIL PROTECTED] rather than [EMAIL PROTECTED] Thanks for getting the RFC repository up an running Nat. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: what will be in Perl6 ?
Tim Bunce said: On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: ... That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. http://windows.oreilly.com/news/hejlsberg_0800.html Impressive. Quite deeply impressive. Yes, Hejlsberg is well worth listening to. For those who are unfamiliar with his background, he was the architect behind Borland Delphi, which is well worth looking at to see good implementations of a few things he talks about in the article (eg. there is only one type of class; properties and events are fundamental). Microsoft poached him a few years back and have made him into something of a celebrity. I did particularly notice one quote of his: "I just think that we're a generation ahead when it comes to the thinking in this space" ...which sounds awfully like a challenge to me ;-)
DOCS
hi, As the news that the Perl will be rewriten comes... me and I think many others non core coders decided that they can help with something but most of the people like me doesn't have the knowledge of the current PERL5.6, why we may need this ?! 'cause Perl6 is 2 years from "here" and we will not have alpha version sooner - then what to do to help ?! HmmmLet see how it works now and experiment with the current Perl my ideas but there is a lack of information/docs about it... so I'm in circle give us more than perlguts and perlapi, they are not enought . One good Idea was PERLHACKTUT posted on the perl5portes list meanwhile is there new version of it?... I can make a list of wishes for the docs if you want :") Another benefit will be that we will have something to compare with... Perl 5.(7/8) will be our field test for Perl 6.0 Thanx for your time = iVAN [EMAIL PROTECTED] =
Re: what will be in Perl6 ?
raptor writes: : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. http://windows.oreilly.com/news/hejlsberg_0800.html Larry
Re: what will be in Perl6 ?
On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: raptor writes: : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. http://windows.oreilly.com/news/hejlsberg_0800.html In reading this I noticed that documentation was listed as a first class language construct and that got me thinking about python's docstrings. It would be neat to have something similar in perl. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
development relationship of Perl 5 and Perl 6
Johan Vromans writes: : Nick Ing-Simmons [EMAIL PROTECTED] writes: : :perl.exe + perl.dll or .../bin/perl + libperl.so : : RFC: Should the perl program be called differently (e.g., perl6) to : allow sites to run 5 and 6 in parallel until their migration is : completed (if ever)? We will certainly have to distinguish the executables. I will go farther than that, and say that we will fail if we do not build Perl 6 in the same distribution tree as Perl 5. Yes, we're redesigning Perl 6 from scratch, but I think that for a long time yet, we will need to keep the scaffolding of Perl 5 around Perl 6. Keeping them co-located has a number of advantages: * We know which version of Perl 5 we're using to build Perl 6. * We can make calls back into Perl 5 to emulate things not yet implemented in Perl 6. * We make it obvious that Perl 5 is still very important to us. * We keep Perl 6 in front of everyone's nose even if they aren't interested in using it yet. * We can evolve the Perl-5-to-Perl-6 translator as we go. I basically used the emulation approach to write Perl 5, so I know it works. There were some intermediate forms of Perl where some of the opcodes ran Perl 5 C code, and some of them ran Perl 4 C code. My basic underlying point is that you can be revolutionary in design, yet evolutionary in implementation of that design. And that taking such an evolutionary approach has the advantage of not letting the old guard think they've been totally abandoned. (Witness the problems of perceived abandonment with the Mozilla rewrite.) We may, of course, decide to do something so different that there's no way to write the glue to call back into Perl 5 for unimplemented opcodes. If that's the case, it might be a danger signal that we're overreaching, and we'll have difficulty dragging Perl 5 code into the Perl 6 world. I could be wrong about that. Whether or not we use Perl 5 to emulate unimplemented opcodes, we still to keep Perl 6 near Perl 5 for all the other reasons. Larry
Re: type-checking [Was: What is Perl?]
On Tue, Aug 01, 2000 at 09:25:33PM +, Nick Ing-Simmons wrote:
Alan Burlison [EMAIL PROTECTED] writes:
No, I disagree. Perl gains a lot of its expressive power from being lax
about typing. I suspect it will also impose an unacceptable overhed for
the vast majority who don't want it - at the very least every variable
access will have to check an 'are you typed' flag.
Cross posted to internals ('cos it is...)
We should consider using "vtables" to avoid the cost of the conditional
branches (and running out of flag bits).
Thus this function would call variables "type check" "method" -
which for normal case would be pointer to blue-white-hot "NoOp" function
which is near always in-cache, for a typed var it could be a slow
as you wanted...
I agree with all this.
Tim.
Re: type-checking [Was: What is Perl?]
On Tue, Aug 01, 2000 at 10:47:24PM +0100, Alan Burlison wrote: I suspect reorganising the data structures to be cache friendly would gain more benefit than avoiding a few inline bit twiddles. We should do both. Tim.
better subjects (was Re: what will be in Perl6 ?)
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW If this article is going to inspire multiple threads, let's try to LW give them unique subject names. Thanks. and in general, we need better message subjects. already i have seen threads fall into the one-subject-fits-all abyss of alt.sysadmin.recovery. if you reply is not on topic with the subject, please rename the subject. and please don't use generic subjects like 'what will be in perl6'. 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
what will be in Perl6 ?
http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html
Re: RFC: On-the-fly tainting via $^T
At 12:51 PM 8/2/00 +0100, Graham Barr wrote: On Tue, Aug 01, 2000 at 11:56:48AM -0400, Dan Sugalski wrote: What I was thinking of was something along the lines of a lexically scoped pragma--"use taint"/"no taint". (We could do this by sticking in an opcode to set/unset the tainting status, as well as the warning status, and so on) Taint checking is disabled in a no taint block. Whether we still set the taint status on a scalar could depend on the -T switch, so data would still be tainted in a no taint block. I agree with a pragma. But I think there should be some distinction between taint setting and taint checking. I was figuring the taint/notaint pragma would control taint checking, while -T would control taint setting. Probably not the best way--might be worth unconditionally setting the taint status so a use/no taint would do the right thing. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
Dan Sugalski [EMAIL PROTECTED] writes: From a language perspective, I have a scheme to allow us to yank all the cruft (sockets, shm, messages, localtime...) out into separate libraries, yet pull them in on demand without needing a use. a la dbmopen in perl5? -- Piers
Re: what will be in Perl6 ?
On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: raptor writes: : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. http://windows.oreilly.com/news/hejlsberg_0800.html Impressive. Quite deeply impressive. Tim.
