Perl recommended reading list
On 5 Oct 2000, at 15:06, Dan Sugalski wrote: > I should actually RFC it--we could use a "recommended reading" RFC. Have you had any further thoughts on this? Do you think you'll find the tuits necessary? Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.
Re: Perl recommended reading list
On Mon, Oct 09, 2000 at 04:00:12PM +0200, Philip Newton wrote: > On 5 Oct 2000, at 15:06, Dan Sugalski wrote: > > > I should actually RFC it--we could use a "recommended reading" RFC. > > Have you had any further thoughts on this? Do you think you'll find > the tuits necessary? Well, if you want us to all chip in with ideas, here's what I've been reading recently: Compilers: Principles, Techniques and Tools. Aho, Sethi, Ullman. Unicode: A Primer Tony Graham Modern Compiler Implementation in C Andrew Appel Advanced Programming In The Unix Environment Stevens -- "Dogs believe they are human. Cats believe they are God."
Re: Perl recommended reading list
"Generic Programming and the STL", http://www.amazon.com/exec/obidos/ASIN/0201309564 "Designing Concurrent, Distributed, and Real-Time Applications with UML" http://www.amazon.com/exec/obidos/ASIN/0201657937 "An Introduction to Genetic Algorithms" http://www.amazon.com/exec/obidos/ASIN/0262631857 -- John Porter
Re: Perl recommended reading list
On Mon, Oct 09, 2000 at 03:14:49PM +0100, Simon Cozens wrote: > Well, if you want us to all chip in with ideas, here's what I've been reading > recently: Oh, missed a bunch of web-based things: Report on Interpreted Programming Languages www.cs.colorado.edu/~zorn/cs5535/Fall-1996/projects96/zhangx-interpret.html The design of the Inferno virtual machine www.cs.bell-labs.com/cm/cs/who/rob/hotchips.html The Java Virtual Machine Specification http://java.sun.com/docs/books/vmspec/html/VMSpecTOC.doc.html -- The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Perl recommended reading list
At 04:00 PM 10/9/00 +0200, Philip Newton wrote: >On 5 Oct 2000, at 15:06, Dan Sugalski wrote: > > > I should actually RFC it--we could use a "recommended reading" RFC. > >Have you had any further thoughts on this? Do you think you'll find >the tuits necessary? Well, here's a quick list, sans ISBN numbers, of the books I'm digging (or have recently dug) through that are relevant to perl 6: The Mythical Man-Month Fred Brooks Understanding Comics Scott McCloud Tao Te Ching Lao Tzu (translation by Ursula LeGuin) Alice in Wonderland and Through the Looking Glass Lewis Carroll Programming with POSIX Threads Dave Butenhof Compilers Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman Advanced Compiler Design & Implementation Steven S. Muchnick Building an Optimizing Compiler Robert Morgan Garbage Collection Richard Jones and Rafael Lins Of the ones here, I'd say the first four are probably the most important. (And yes, I *am* serious. Especially about Understanding Comics--chapter seven is arguably the most important single chapter in the lot, though one could certainly argue for some of the chapters in the Tao Te Ching. If I could get cheap reprints of it, I'd likely hand the thing out to anyone who's interested in writing code for the core) MMM and the Tao Te Ching are probably less relevant folks not managing a project, but arguably still relevant. I've also got Algorithms (A functional programming approach) Fethi Rabhi and Guy Lapalme The Limits of Software Robert N. Britcher in the queue to look at, and Introduction to Algorithms Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest Internetworking with TCP/IP vol 1 4th edition Douglas E. Comper TCP/IP Illustrated vol 2 Gary R Wright and W. Richard Stevens on the reference shelf. (Well, OK, K&R 2nd edition is there too, but that almost doesn't count) It's a rather lopsided list (and the urge to add some HP Lovecraft is almost too strong to resist... :) but there you go. Reasonably soon I'm going to throw them together, along with a paragraph or six on each for why they're relevant, into an RFC (probably internals RFC #1), and other folks can tack onto it when they get a chance. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 326 (v1) Symbols, symbols everywhere
At 11:54 PM 10/5/00 -0400, Chaim Frenkel wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >DS> For the internals, though... > >DS> This would be very useful, and it's a feature I'd really like to >implement. >DS> Basically you're asking for pre-computed, indirect, shared hash keys. >This >DS> sounds like a Good Plan to me. > >Why precomputed? Any 'interned' string has a unique value (e.g. address). >Though wouldn't they have to be garbage collected? Short lived hashes >with constantly changing keys, the shared hash keys would keep growing. I'm thinking of a central store for text constants used as hash keys. (How many times do we use AUTOLOAD in perl 5, for example?) Something reasonably automagic, such that we don't have to go recompute hash values every fscking time we access something with a hash value known at program compile time. (Or perl compile time, for that matter) I'm also wondering if attaching a hash value to SVs would be a performance win--probably not, but it's tempting to check and see. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl recommended reading list
Dan Sugalski wrote: > >The Mythical Man-Month >Fred Brooks That reminds me: I highly recommended "Anti-Patterns": www.antipatterns.com/briefing >Understanding Comics >Scott McCloud > >Tao Te Ching >Lao Tzu (translation by Ursula LeGuin) > >Alice in Wonderland and Through the Looking Glass >Lewis Carroll Well, if we're going for balance, I'd suggest "The Runaway Universe", www.amazon.com/exec/obidos/ASIN/0738200689 An excellent overview of modern cosmology for the layman. It's also one of the few recent enough to cover in detail the revolution of the last year or two, in which the expansion of the universe is shown to be accelerating. That is, the infamous cosmological constant -- Einstein's "greatest blunder" -- is NOT, as had long been assumed, zero. >Introduction to Algorithms >Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest This is probably the best algorithms book on the market; it is encyclopedic. More up-to-date than Knuth, and also much easier to comprehend for most people. >Internetworking with TCP/IP vol 1 4th edition >Douglas E. Comper (that's "Comer", btw.) The whole series is good -- Volumns I-II-III, and "The Internet Message: Closing the Book with Electronic Mail", by Marshall T. Rose. I personally can't resist the urge to throw all the CS classics in there, particularly "The Structure and Interpretation of Computer Programs"; also "Design Patterns" (the "Gang of Four" book). -- John Porter By pressing down a special key It plays a little melody
Re: Perl recommended reading list
Before I forget: (I read a *lot*) A Course In General Linguistics, F. de Saussure. tr. Roy Harris (If you don't know what relation this has to Perl, what are you doing here?) The Practice of Programming, Kernighan and Pike. (You mean you haven't read it yet?) Knots, R.D. Laing -- Pokemon seems an evil concept. Kid hunts animals, and takes them from the wild into captivity, where he trains them to fight, and then fights them to the death against other people's pokemon. Doesn't this remind you of say, cock fighting?
Re: Perl recommended reading list
At 12:56 PM 10/9/00 -0400, John Porter wrote: >Dan Sugalski wrote: > > > >The Mythical Man-Month > >Fred Brooks > >That reminds me: I highly recommended "Anti-Patterns": > www.antipatterns.com/briefing Nifty. I think it's another book to add to the pile. (I might finish the pile by the time that perl 6 is released...) > >Understanding Comics > >Scott McCloud > > > >Tao Te Ching > >Lao Tzu (translation by Ursula LeGuin) > > > >Alice in Wonderland and Through the Looking Glass > >Lewis Carroll > >Well, if we're going for balance, I'd suggest "The Runaway Universe", > www.amazon.com/exec/obidos/ASIN/0738200689 >An excellent overview of modern cosmology for the layman. Argh! Recreational reading! Go rub it in, why don't you? :-P FWIW, I didn't add those three in there out of any sense of balance. They really are in there as relevant to perl development. (Or at least I think so...) The big thing that Understanding Comics brings to perl development is chapter 7. It it deals with the six stages of art which, as Scott says, "...because the creation of *any* work in *any* medium will always follow a certain path." And what we're doing is as much art as science or engineering. (The six stages, from outside in, are Surface, Craft, Structure, Idiom, Form, and Idea/Purpose. They're expressed a tad differently for a utilitarian art like programming than they are for something like comics or novels, but they're still there) The Tao Te Ching is grand as a project management book because, well, the one thing you need more than anything else when managing projects is a sense of calm, serenity, and perspective. :) Alice in Wonderland is, of course, the quintessential CS text. It never hurts to keep in mind that everything you know could well be wrong. :) > >Introduction to Algorithms > >Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest > >This is probably the best algorithms book on the market; it is >encyclopedic. More up-to-date than Knuth, and also much easier >to comprehend for most people. And large enough to mug someone, if need be. (Like if you just paid for the silly thing... :) > >Internetworking with TCP/IP vol 1 4th edition > >Douglas E. Comper > >(that's "Comer", btw.) The whole series is good -- Volumns I-II-III, >and "The Internet Message: Closing the Book with Electronic Mail", by >Marshall T. Rose. Gah. Typos. I don't have volumes 2 or 3 handy, though they're also on the list. I'd forgotten about Rose's book--I think I have that in a box somewhere. >I personally can't resist the urge to throw all the CS classics >in there, particularly "The Structure and Interpretation of Computer >Programs"; also "Design Patterns" (the "Gang of Four" book). Works for me. I'll get the first draft of the reading list done as soon as I can manage, and then folks can add to it as they think appropriate. I'd like to keep the list relatively focused on books directly related to perl development, but there's no reason we can't have a section on good CS background texts. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
At 08:50 PM 9/29/00 +0100, Nicholas Clark wrote: >On Fri, Sep 29, 2000 at 12:37:15PM -0400, Dan Sugalski wrote: > > At 04:13 PM 9/29/00 +0100, Nicholas Clark wrote: > > >Are you suggesting that the attributes use the same mapping system as > > >the XS (or son-of-XS (XS++)) typemaps in lib/ExtUtils/typemap? > > >If so, will there be the "terse" column in the typemap file to associate > > >"i" with "T_IV" ? > > > > Hadn't considered it, but my first thought is to not shoot for that as a > > target. The code that takes the parameters from the C-level calling frame > > and builds PMCs out of them will be operating at a very low level, with > > deep carnal knowledge of a platform/processor pair's calling sequence. > It's > > going to have to know the order that things go in registers, which > > registers hold which types of parameters, and how excess parameters > flow on > > to the stack (or wherever they go) This is code that'll be different > > (potentially) for every operating system on every processor perl runs (and > > supports this) and I don't know that we can get this flexible. 'Specially > > since many of the conversion routines will have to be written in C, rather > > than in perl. (If perl gets a pointer to an array of char pointers, what > > exactly could it do with it?) > >Do you need this "deep carnal knowledge" to make it efficient, or just to >make the thing fly at all? Depends on how we implement the thing. If we build up real function code at runtime, we can encapsulate all the state we need in a single function pointer, and don't need to have the caller pass in any state at all. This is good, since it means the caller can do: (*foo)(1, 2, 3) to call the perl sub whose function poiner's stored in foo. (Well, assuming I got the syntax right) The bad thing is we need to know how to generate the function header and whatever bits we need to have to pull arguments off the stack and out of registers and turn 'em into perl PMCs, then call the real perl code. The alternate method is to use something like we've got now with the perl_call_* stuff, where you pass in a pointer to the real perl function to a generic (vararg'd) C function, like: perl_call(perl_cv_ptr, 1, 2, 3); the bad bit about that is it means that calls to perl functions are different than calls to C functions, and I'm trying not to do that--I really do want to be able to get real function pointers that can be used in C code just like any other C function. >If the latter, if only VMS, x86 BSD and x86 Linux (and probably Solaris 9) >have support, what is everyone else going to do if they are attempting >to compile some or other third party app that needs this feature? Well, perl will provide this, so whoever's doing the port for a platform would have to provide this in the platform-specific code. I doubt it's changed for Solaris on SPARC since, the SunOS 4.x days, I know it's not changed for OpenVMS Vax for ages and hasn't changed at all for OpenVMS Alpha. Other platforms are likely similar--this is the sort of thing you really can't mess with, since it breaks backwards compatibility in many profound and nasty ways. That doesn't mean it's going to be *easy*, mind, but certainly doable. Whether it's a reasonable thing is a separate question, of course. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
autogen
http://autogen.sourceforge.net/ Maybe everyone knows about this already but I didn't know about it until just now. Enjoy. -- May the best description of competition prevail. (via, but not speaking for Deutsche Bank)
Re: RFC 326 (v1) Symbols, symbols everywhere
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: >> Why precomputed? Any 'interned' string has a unique value (e.g. address). >> Though wouldn't they have to be garbage collected? Short lived hashes >> with constantly changing keys, the shared hash keys would keep growing. DS> I'm thinking of a central store for text constants used as hash keys. (How DS> many times do we use AUTOLOAD in perl 5, for example?) Something reasonably DS> automagic, such that we don't have to go recompute hash values every DS> fscking time we access something with a hash value known at program compile DS> time. (Or perl compile time, for that matter) DS> I'm also wondering if attaching a hash value to SVs would be a performance DS> win--probably not, but it's tempting to check and see. Well, if having a dual-natured string/number is a win, then the first time a string is used as a hash, the hash value could be saved. But the biggest win would probably be compile time hash values. Hmm, my @values : forKeys = qw( ); -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Perl recommended reading list
Dan Sugalski wrote: > > Alice in Wonderland is, of course, the quintessential CS text. It never > hurts to keep in mind that everything you know could well be wrong. :) Another one I'd like to suggest, which I suspect (hope?) most everyone has already read: The Hitchhiker's Guide to the Galaxy Douglas Adams ISBN: 0345418913 http://www.amazon.com/exec/obidos/ASIN/0345418913 Actually, the first 4 books of the series are all more or less "must reads". I'm thinking between the Somebody Else's Problem Field, the Infinite Improbability Drive, and the Bistromathic, this Perl 6 thing just might work. ;-) -Nate
