Post #124,641
11/7/03 2:12:12 PM
|
LL3 Webcast
[link|http://ll3.ai.mit.edu/|Lightweight Languages 2003 (LL3)] will be webcast tomorrow (Nov. 8th) for those who are interested in programming language design and implementation. The one that interests me the most is the last one (@4:30) by Dan Sugalski. He's part of the Parrot team so this is probably of interest to Perl and Python programmers alike.
|
Post #124,705
11/8/03 1:41:01 AM
|
Thanks, looks interesting
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #124,734
11/8/03 10:44:06 AM
11/8/03 10:45:02 AM
|
Parrot
I'm actually interested in that topic. I'd like to implement something like that for OS/2 (perhaps as part of an honours thesis or something like that). Not quite a straight port; there are features in the current rexx integration that I'd like to get going that can't possibly be part of parrot... more a matter of taking the current rexx integration features and generalising them to other scripting languages, with an eventual goal of being able to add a scripting language to the system by adding a DLL, and then allowing that support to be automagically extended to apps that use the generic scripting API that I'd create for it.
Edit: unfortunately, I'm going to be at work then, so there's no way I'm going to be able to catch it.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
Edited by jake123
Nov. 8, 2003, 10:45:02 AM EST
|
Post #124,740
11/8/03 11:39:53 AM
|
Why can't they be part of parrot?
If you have concrete technical reasons why not, the Parrot folks would be interested in hearing about it. Parrot is meant to be readily extensible and highly customizable to specialized purposes. (You can even create new bytecodes dynamically!) If there is a need they can't fill that can be demonstrated by pointing to an existing scripting language, now would be the time to try to fix it.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #124,744
11/8/03 12:53:34 PM
|
Re: Why can't they be part of parrot?
Because they are quite specific to the OS/2 platform. EG- access to the SOM class hierarchy and the object hierarchy for the desktop. Putting that into parrot seems like bloat for what parrot is supposed to be. Putting it as an 'enhancement' to parrot that is specific to an OS/2 implementation makes a lot more sense, imho.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #124,755
11/8/03 4:26:31 PM
|
That doesn't seem like a valid objection to me
So you write an interface between Parrot and the native object system. There is no reason that you cannot build that on top of Parrot, and once you have done so, that interface would be available to any code running on that interpreter that wanted access. (Even code running in other scripting languages.)
Remember, Perl was the language that invented the concept of [link|http://inline.perl.org/inline/home.html|Inline.pm], and Parrot would like to make that easier.
(Another reason that non-Perl programmers should like Parrot. It will try to make CPAN no longer a reason to choose Perl over, say, Python.)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #124,767
11/8/03 9:22:45 PM
|
No no no no...
I'm basically saying that the stuff for that shouldn't be part of the core of parrot, as it's very platform specific.
Or, as you said, "There is no reason that you cannot build that on top of Parrot, and once you have done so, that interface would be available to any code running on that interpreter that wanted access." which is exactly what I'm talking about... I want to extend some of those facilities to any scripting language that is able to address them. There are other APIs that are used to load rexx into compiled programs (rexxstart, rxsubcom*, etc) that I'd also like to generalise, esp. because with the introduction of object rexx some of those APIs become broken in certain ways that can be catastrophic to the system. It's not like it's unfixable; it's that IBM won't actually do it without someone throwing a ton of dough at them to do it. With that in mind, I'd like to be able to create function-alike APIs that would add some functionality, and 'hook' the current calls to work on a subset of the new calls, so that daemons using user hooks written in rexx would get un-fscked when the system uses the object rexx interpreter.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #124,911
11/10/03 10:33:06 AM
|
Right, but you DON'T need to fork Parrot to do it
Just build an extension on top of Parrot for OS/2. Then you get stuff that goes into the regular Parrot, and you don't have to maintain a port.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #124,924
11/10/03 11:15:27 AM
|
If you fork the parrot....
It'll be pinning for the fjord!
Better staple the feet on the perch.
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
|
Post #124,996
11/10/03 7:46:44 PM
|
Re: If you fork the parrot....
I'm phoning PETA and the RSPB.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Blog]
|
Post #124,756
11/8/03 5:30:11 PM
|
It was pretty non-specific
Well, he did open up by saying that everyone has to give a philosophical talk once in their lives, and this was his. But it was still fun.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #124,769
11/8/03 10:52:17 PM
|
Was hoping he'd delve into Parrot a bit more
Thought it'd be more along the lines of how to get Python, Perl, and Ruby programs to play together well. Still the talk was interesting and kind of gave a glimpse of the philosophy be the designer, if not the Parrot itself.
One thing that did surprise was in the Q&A in the end, that he was talking about how poorly forth performed on Parrot. I'm assuming that the Forth stack really is a bit more dynamic, allowing you to jump willy nilly around based on calling routines that reside and get shuffled on the stack. Still, since Parrot is a stack VM, I would have thought it wouldn't be as poor performing as described.
|
Post #124,774
11/9/03 12:44:25 AM
|
Parrot is NOT a stack VM
It is register based. With lots and lots of registers. (The idea being that any architecture which benefits really does. And that doesn't doesn't.) Also everything (as he described) has to have indirection everywhere.
OTOH I'm looking forward to Perl running 3-5 times as fast as at present. With bigger wins still if you are using a register-rich environment (like Opteron in 64-bit mode). ;-)
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #124,917
11/10/03 10:52:58 AM
|
Did catch the Lua VM presentation
Where the new Lua VM is registered based. Lua is restricted to 256 registers. Does Parrot have a similar limit? And doesn't Parrot still have a stack (even with all the registers)?
|
Post #124,923
11/10/03 11:08:22 AM
|
Yes, Parrot has a similar limit
I think that it is 64 registers each of 4 different types.
And yes, there was a stack as well, but each item contains a whole set of registers so you only want to do that when you really, really want to. When I saw "was", I'm admitting that I saw the design before they added pervasive continuations to it. I don't know how continuations have changed things, but I know that it isn't a small change.
So the obvious implementation of Forth is pretty much a worst case.
Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
