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) > > > @b = (1,2,3); > @c = (2,4,6); > @d = (-2,-4,-6); > $s

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 FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED]

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 di

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 dispa

Re: RFC 35 (v1) A proposed internal base format for perl

On Tue, Aug 15, 2000 at 09:47:05AM -0400, Chaim Frenkel wrote: > > "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? Perhaps the perl6 web pages should have a list of 'required readings' URLs.

Re: RFC 35 (v1) A proposed internal base format for perl

Chaim Frenkel writes: : > "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? Sorry, just my shorthand for the IL of .NET, which is to say, Microsoft's new intermediate language. Larry

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 vt

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) > > > > > > @

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 Interpret

Re: RFC 35 (v1) A proposed internal base format for perl

Chaim Frenkel <[EMAIL PROTECTED]> writes: >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

Re: Char encoding

At 11:51 AM 8/15/00 +0900, Simon Cozens wrote: >On Mon, Aug 14, 2000 at 10:44:33PM -0400, Dan Sugalski wrote: > > > (I'm not really following Perl 6, but Unicode is obviously something > > > I have a concern about. Please *do* CC me replies, just this once.) > > > > This is why we should: > > >

Re: Threaded In-Line Code (was Re: Typed Intermediate Language)

On Tue, Aug 15, 2000 at 11:17:17AM -0400, Dan Sugalski wrote: > 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

Re: Welcome to Perl Vtbls

Chaim Frenkel <[EMAIL PROTECTED]> writes: >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. That is the one we are t

Re: Welcome to Perl Vtbls

Chaim Frenkel writes: : I can't see how objectA's vtbl can handle a cross-operation to objectB's : vtbl. : : Enlightenment sought. I'm mostly just trying to bust us out of conventional thinking by throwing random words around. I don't know offhand whether multimethod dispatch would make any sen

Re: RFC 35 (v1) A proposed internal base format for perl

Dan Sugalski <[EMAIL PROTECTED]> writes: > >How much of the current base of target ports are you willing to give up in >the first cut for fast? The TIL suggestion, amongst others, has the >potential to speed things up rather a lot, but it has the disadvantage of >requiring intimate knowledge of ea

Re: Char encoding

Dan Sugalski writes: : >I don't see why. I don't think we should be dealing with *multiple* internal : >encodings. That would be Bad and Wrong. : : Why not? We're going to have two already, binary and UTF-something, and if : we provide an option for UTF-8, -16, and -32 we're going to need the co

Re: Char encoding

Dan Sugalski writes: : > iii) Never assume bytes. : : What, never? Not even in vectors and bitmaps? :) : : I agree, though. Character and byte are separate constructs and need to be : dealt with separately. Not sure what you guys mean. A string is a sequence of integers. A sequence of inte

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

Re: Threaded In-Line Code (was Re: Typed Intermediate Language)

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> I was actually thinking that @b * @c would boil down to a single vtable DS> call--we'd just hit the multiply function for variable @b, and pass it a DS> pointer to @c, and let it Do The Right Thing. But that was my question in the _oth

Re: RFC 35 (v1) A proposed internal base format for perl

eAt 04:57 PM 8/15/00 +0100, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > > >How much of the current base of target ports are you willing to give up in > >the first cut for fast? The TIL suggestion, amongst others, has the > >potential to speed things up rather a lot, but i

Re: Char encoding

At 09:05 AM 8/15/00 -0700, Larry Wall wrote: >Dan Sugalski writes: >: >I don't see why. I don't think we should be dealing with *multiple* >internal >: >encodings. That would be Bad and Wrong. >: >: Why not? We're going to have two already, binary and UTF-something, and if >: we provide an option

Re: Char encoding

Dan Sugalski writes: : Is a statement like "All X comparisons treated as the : platform-native X" OK (for X in string, integer, float) in the 'small perl' : model? (Assuming then that there's no core knowledge of BigInts, BigRats, : or Complex numbers in small perl) Depends on what you mean by

Re: Threaded In-Line Code (was Re: Typed Intermediate Language)

> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes: Chaim> Given N different fundemental types, we end up with NxN vtbl entries. Chaim> A long time ago I looked at some smalltalk code that did Chaim> foo add: bar Chaim> It must have been pretty bad, because I can't remember how they di

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 c

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 i

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

Re: Threaded In-Line Code (was Re: Typed Intermediate Language)

> "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes: > "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes: Chaim> Given N different fundemental types, we end up with NxN vtbl entries. Chaim> A long time ago I looked at some smalltalk code that did Chaim> foo add: bar Chaim> It mus

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

>> 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 > rea

Re: RFC 99 (v1) Maintain internal time in Modified Julian (notepoch)

Proposal for 64 bit time. Just can't help but put in a little more A bit of speculative physics and religion here. To keep historians, geologists, cosmologists, theologians, ufologists and aliens happy, Perl needs neutral time base, which has the most far fetched possibility. Imagine a kid

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

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

There is already precedent (-M, et alia) for a "perl epoch" which is time since the start of execution of the script. Negative numbers are used to represent times prior to the start of execution, and positive numbers are used to represent times after the start of execution. The "perl epoch" does

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 co

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".

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 ye

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Larry Wall wrote: > > 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 don't know about this. Sounds cool, but I think we should stick to something t

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote: > [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

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote: > I don't know about this. Sounds cool, but I think we should stick to > something that somebody somewhere uses already. Of course, something > standard like 0 AD isn't bad. Standard for whom? I bet there are *millions* of Jews for wh

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

At 09:25 AM 8/15/00 -0700, Larry Wall wrote: >[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. :-

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

On Tue, 15 Aug 2000, Nathan Wiger wrote: > 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 i

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.0

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes: RA> Is Perl currently using different epochs on different platforms? If so, I RA> can definitely see the wisdom in doing something about *that* and RA> off-loading the system-local time processing into modules (although I can RA> also see th

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

Jonathan wrote: > >On Tue, Aug 15, 2000 at 09:45:55AM -0700, Nathan Wiger wrote: >> I don't know about this. Sounds cool, but I think we should stick to >> something that somebody somewhere uses already. Of course, something >> standard like 0 AD isn't bad. > >Standard for whom? I bet there are

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.

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

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 a

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[EMAIL PROTECTED] writes: > Midnight, Jan 1, 2000, Greenwich time > > seems like a good candidate. have found 2000-03-01 to be a good epoch. It makes -mm-dd decoding and leap year calculations cheaper/simpler as it is the closest start of a new 400 yea

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

Implementing array notation (was Re: Threaded In-Line Code (was Re: Typed Intermediate Language))

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) > > > > > > @b = (1,2,3); > > @c = (2

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/ calendar that predates christianity>/ Good point. Unix epoch it is! :-) -Nate