Re: Threaded In-Line Code (was Re: Typed Intermediate Language)
On Tue, Aug 15, 2000 at 02:03:12PM +1000, Jeremy Howard wrote: The PDL team are now examining how to incorporate these kinds of features into perl 6. I'm also interested in seeing how to implement things like (from RFC 82) quote @b = (1,2,3); @c = (2,4,6); @d = (-2,-4,-6); $sum = reduce ^_+^_, @b * @c + @d; Well if operators were made to return iterators in a list context then I can see that that would work. For example @b * @c would create an iterator which would return the product of the elements in turn. iter + @d would be an iterator that return the sum of the next value from iter and the next from @d. This final iterator is what is passed to reduce. redice calls iter-next to get the next value. IMO, this should be possible. Graham.
Re: RFC 35 (v1) A proposed internal base format for perl
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW On the other hand, targeting JVM and IL.NET might keep us honest enough. What is IL.NET? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 35 (v1) A proposed internal base format for perl
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: A TIL doesn't have to be machine code. A first pass for a port that does the TIL inner loop in C, should be quite portable. DS Okay, now I'm confused. I was under the impression that doing a TIL really DS required getting down 'n dirty with assembly-level jmps and jsrs, the DS alternative being the op-loop we've got now, more or less. DS Or are you thinking of having the op functions just goto the start of the DS next one on the list? I'd think you'd blow your stack reasonably soon that DS way. (Why do I sense my reading list is about to get larger?) Err, no. Think of it this way. A TIL level sub ^TIL header code# ptr to real Function ^funcA # Start of a til function ^funcB # start of a til function ^funcC So all pointers point at a real function. In the lowest level case, it is pure machine code to be executed. If it is a TIL level sub, the pointer is to a routine that pushes the current TIL program counter and reenters the inner loop. This is with an inner loop. The dispatching could be sped up at the cost of space by converting the pointers into real calls, and replacing calls to push functions with real pushes. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Welcome to Perl Vtbls
This discussion of vtbls and how to do cross products has me confused. I thought there were two different _real_ vtbls and an op tree. The low-level core 'objects' have a vtbl that handles operations on the object itself. The higher level perl user objects have a vtbl that handles method dispatch. Again operations on the object itself. Cross operations, addition, concatination, etc. Are handled in the optree. I can't see how objectA's vtbl can handle a cross-operation to objectB's vtbl. Enlightenment sought. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Welcome to Perl Vtbls
At 10:11 AM 8/15/00 -0400, Chaim Frenkel wrote: This discussion of vtbls and how to do cross products has me confused. I thought there were two different _real_ vtbls and an op tree. The low-level core 'objects' have a vtbl that handles operations on the object itself. Right, those are vtables referenced by the base variable structure. The higher level perl user objects have a vtbl that handles method dispatch. Again operations on the object itself. AKA "package methods". These are the normal perl methods, nothing fancy. Cross operations, addition, concatination, etc. Are handled in the optree. Yup. I can't see how objectA's vtbl can handle a cross-operation to objectB's vtbl. It'd have to overload the vtable functions in the underlying perl object. We may set it so the base vtable for objects just calls known functions in the package. (I'd like the base vtable functions to be capable of being written in perl. Even if we don't want to write the floating point division routines ourselves, I'd like to be able to) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Threaded In-Line Code (was Re: Typed Intermediate Language)
At 11:23 AM 8/15/00 +0100, Graham Barr wrote: On Tue, Aug 15, 2000 at 02:03:12PM +1000, Jeremy Howard wrote: The PDL team are now examining how to incorporate these kinds of features into perl 6. I'm also interested in seeing how to implement things like (from RFC 82) quote @b = (1,2,3); @c = (2,4,6); @d = (-2,-4,-6); $sum = reduce ^_+^_, @b * @c + @d; Well if operators were made to return iterators in a list context then I can see that that would work. For example @b * @c would create an iterator which would return the product of the elements in turn. iter + @d would be an iterator that return the sum of the next value from iter and the next from @d. This final iterator is what is passed to reduce. redice calls iter-next to get the next value. I was actually thinking that @b * @c would boil down to a single vtable call--we'd just hit the multiply function for variable @b, and pass it a pointer to @c, and let it 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: Typed Intermediate Language
David L . Nicol [EMAIL PROTECTED] writes: Just in case I'm not the only one here who doesn't know what TIL means: http://www.cs.cornell.edu/home/jgm/tilt.html Well I have been using 'TIL' to mean "Threaded Interpretive Language" There is a Z80 FORTH clone defined in : "Threaded Interpretive Languages" R. G. Loeliger. Byte Books / McGraw-Hil 1981 ISBN 0-07-038360-X -- Nick Ing-Simmons [EMAIL PROTECTED] Via, but not speaking for: Texas Instruments Ltd.
Re: RFC 35 (v1) A proposed internal base format for perl
Dan Sugalski wrote: Okay, now I'm confused. I was under the impression that doing a TIL really required getting down 'n dirty with assembly-level jmps and jsrs, the alternative being the op-loop we've got now, more or less. I think that's true if we're threading Perl functions. TIL assumes native code, right? (Threading a VM seems pointless to me.) Threading op codes seems a lot easier. Or are you thinking of having the op functions just goto the start of the next one on the list? I'd think you'd blow your stack reasonably soon that way. GCC has the scary computed goto: goto (*addr). It can work like this: OP1: do something ... goto (*pc++); OP2: do something else ... goto (*pc++); JUMP: pc = code[*pc++]; goto (*pc++); You build up an array of void * and pc skips around in it. The void * has the addresses of the code labels stored in it. Works really nice and it's unbelievably fast. (Even puts the ++ in the delay slot and pc in a register.) To call a Perl sub all you have to do is push the current pc and code values on a call stack (or not if it's a tail call) and then code = sub[*pc++]-code; pc = code; goto (*pc++); Opcodes can do all the environment intialization. It makes function calls simpler and allows the optimizer to eliminate expensive things like environment re-construction when we're calling a top-level sub. Of course this can't be the only interpreter implementation because it's non-portable. We can approximate the structure with a switch statement and macros. Or if our pre-processor is really smart it should be able to generate whatever structure is fast on a particular arch. - Ken
string types proposal
Larry Wall wrote: By the way, don't take this as a final design of string types either. :-) If string types are a tree of partially full nodes of string data, the representation of each sNode could be independent of the others. The originial idea behind using partially full nodes is, you can do substitutions that affect the length in the middle without needing to rewrite the whole thing. But with variable string data types, each node can have a variable type. Instead of redefining the whole thing from utf8 to utf16 when a chr(3852) arrives (I have no idea how that looks from a data stream perspective, but I am assuming that it is robustly defined) we can just redefine the sNode that the big character lives in. Also, to optimize most calls to eq (as well as all the other basic comparison operators) an immediate data area defined in the SV structure that is used for holding numeric data could hold, for pure string/raw data, the first letter or two.
Re: Threaded In-Line Code (was Re: Typed Intermediate Language)
"Randal" == Randal L Schwartz [EMAIL PROTECTED] writes: Randal Yes, double dispatch. Addressed by "the Damian" in Object Oriented Perl Randal (the Book, and the forthcoming Musical) as it applies to perl at a Perl Randal level. Duh - 30 seconds with google found a nice reference on it in smalltalk: ... http://www.object-arts.com/EducationCentre/Patterns/DoubleDispatch.htm -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Internal Filename Representations (was Re: Summary of I/O related
[EMAIL PROTECTED] (Jarkko Hietaniemi) wrote on 13.08.00 in [EMAIL PROTECTED]: On Sun, Aug 13, 2000 at 02:14:24PM -0400, Chaim Frenkel wrote: Why do all those acts have to be performed to do an open? I must not be explaining myself very well... To do an open() from Perl the user does not have to do *anything* special. *Internal* *representation*. Not external use. It's not that what you're saying is hard to understand, it's that it misses the point. There is no reason at all for the implementation of open to do this type of filename parsing, either. You *only* need filename prsing when you want to manipulate the filename itself. Change the extension, canonicalize it, whatever. use A::B might need this, some change_extension() function might, open doesn't. (Though it seems as if it needs to do URI parsing instead.) MfG Kai
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On 14 Aug 2000, Russ Allbery wrote: Day resolution is insufficient for most purposes in all the Perl scripts I've worked on. I practically never need sub-second precision; I almost always need precision better than one day. MJD allows fractional days (otherwise it would of course be useless). As I write this the MJD is 51771.20833 I recognize that a lot of software packages out there are using MJD, but I don't really feel that fractions of days, hours, or minutes are intuitive. Mankind has had sixty seconds in a minute, sixty minutes in an hour, twelve hours in a day, and so on up, for centuries. Arguably, better systems could be created, and perhaps MJD is such a system, but it is very hard to change the instincts and habits built on older systems. (Just look at how slowly the U.S. is moving to metric.) I would really rather not see this change, or see the number expressed in seconds. (MJD as seconds would really amount to just moving the epoch, and I don't think that would make anyone happy.) I still lean towards thinking that anything involving a date should be pushed out into a module. There could be a date module (or two) included as standard, and people who want MJD or other systems, or fractions of a second, or whatever, could totally ignore the standard module and use a different one. J. David
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Tue, Aug 15, 2000 at 08:44:48AM -0700, Nathan Wiger wrote: There seems to be a groundswell against this idea, which is fine by me (heck, just because it's my idea doesn't me it's a GOOD one!). Here's a different proposal, same vein: "Standardize all Perl platforms on the UNIX epoch". Sound better? Yep. Or more generally "Standardize Perl on all platforms to one common time epoch" and reccommend the Unix epoch since it's so widespread. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
[EMAIL PROTECTED] writes: : Yep. Or more generally "Standardize Perl on all platforms to one : common time epoch" and reccommend the Unix epoch since it's so : widespread. :-) Oh, gee, where's your sense of history? (As in creating our own. :-) Maybe we should invent our own epoch, like the year 2000. Or use a really standard one, like the year 0 AD (aka 1 BC). I have this horror that people will still be using 1970 as the epoch in the year 31,536. Larry
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
Jarkko Hietaniemi wrote: Is Perl currently using different epochs on different platforms? If so, I Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical reason IIRC. This is the real point I'm trying to address. Nothing else. :-) There seems to be a groundswell against this idea, which is fine by me (heck, just because it's my idea doesn't me it's a GOOD one!). Here's a different proposal, same vein: "Standardize all Perl platforms on the UNIX epoch". Sound better? -Nate
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
At 02:23 PM 8/15/00 -0400, [EMAIL PROTECTED] wrote: Modified Julian Day 0 thus started on 17 Nov 1858 (Gregorian) at 00:00:00 UTC. (somebody threw that date out, It appears to be purely arbitrary rather than based on some celestial event) Not arbitrary at all. From: http://www.kgb.com/calend.html This information comes from the original (pre-Motif) DECwindows help file which accompanied VMS version 5.3. by Marios Cleovoulou http://ourworld.compuserve.com/homepages/cleovoulou/ Copyright © 1988, 1989 by Digital Equipment Corporation. The Julian Period Astronomers use the Julian period because it is convenient to express long time intervals in days rather than months, weeks and years. It was devised by Joseph Scaliger, in 1582, who named it after his father Julius, thus creating the confusion between the Julian (Caesar) calendar and the Julian (Scaliger) period. Julian Day 1 began at 12:00 noon, January 1, 4713 BC. This date was thought by some to correspond approximately to the beginning of the universe. Certainly it predated any known astronomical events known in the 16th century without resorting to negative times. Scaliger decided on the actual date on the grounds that it was the most recent coincidence of three major chronological cycles: - The 28-year solar cycle, after which dates in the Julian calendar (for example September 27) return to the same days of the week (for example Tuesday). - The 19-year lunar cycle, after which phases of the moon return to the same dates of the year. - The 15-year indiction cycle, used in ancient Rome for tax regulation. It takes 7980 years to complete the cycle. Noon of January 1, 1988, marks the beginning of Julian Day 2447161. The Julian period is also of interest because of its use as a time base by the VMS operating system. VMS and the Julian Period or: Why VMS regards November 17, 1858, as the beginning of time... The modified Julian date adopted by SAO (Smithsonian Astrophysical Observatory) for satellite tracking is Julian Day 240, which turns out to be November 17, 1858. SAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704 in 1957, when Sputnik went into orbit. The Julian day was 2435839 on January 1, 1957. This is 11225377 octal, which was too big to fit into an 18-bit field. With only 8K of memory, the 14 bits left over by keeping the Julian date in its own 36-bit word would have been wasted. They also needed the fraction of the current day (for which 18 bits gave enough accuracy), so it was decided to keep the number of days in the left 18 bits and the fraction of a day in the right 18 bits of one word. Eighteen bits allows the truncated Julian day (the SAO day) to grow as large as 262143, which from November 17, 1858, allowed for 7 centuries. Possibly, the date could only grow as large as 131071 (using 17 bits), but this still covers 3 centuries and leaves the possibility of representing negative time. The 1858 date preceded the oldest star catalogue in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
In message [EMAIL PROTECTED] Dan Sugalski [EMAIL PROTECTED] wrote: I think I'd snag a date after the last western country went Julian, just to avoid some of the less fun time conversion issues. (How long ago Jan 1, 1690 was depends on what country you're in) I think you mean Gregorian, not Julian. If that's going to be your requirement then you need to pick a date in the 20th century I think as IIRC Russia didn't go Gregorian until then... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...I haven't had sex in so long, I forget who gets tied up!
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 08:40:32PM -0700, Nathan Wiger wrote: No, but currently Perl IS forcing Windows, Mac, and BeOS users to understand what the UNIX epoch is. So you're proposing that rather than give one platform (unix) an advantage, we force all platforms to use some other completely arbitrary date/time format? There's some other advantages to MJD beyond system-independence. Namely, it allows easy date arithmetic, meaning complex objects are not required to modify dates even down to the nanosecond level. Sorry, but date arithmetic is easy now: $then = time(); # time passes $now = time(); $difference = $now - $then; # How long was that? And as to modifying dates "down to the nanosecond", you're proposing that these MJD dates be floating point numbers. Why not ust make time() return a float and *bam* you've got 1 second precision as far as your floats or doubles can carry you. But make the core language easily accessible to everyone. Funny, that's the exact argument I would use *against* mjdate(). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
At 10:56 PM 8/14/00 -0500, Jarkko Hietaniemi wrote: Is Perl currently using different epochs on different platforms? If so, I Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical reason IIRC. It's the Smithsonian Base Date, FWIW. On VMS, though, perl presents all time in Unix epoch seconds. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
Jonathan Scott Duff wrote: standard like 0 AD isn't bad. Standard for whom? I bet there are *millions* of Jews for whom "0 AD" is meaningless. s/Jews/any other group of people who have their own calendar that predates christianity/ Good point. Unix epoch it is! :-) -Nate
