Re: FORTH and Hypercard
Jacque, I wonder if Scott would come to the same conclusion today. On modern computers messages can transverse the entire path in nanoseconds. While Rev. definitely feels faster than HC on all the computers where I've used it, HC was tolerable even on an 8 MHZ Mac Plus of the mid 80's - so passing messages through the entire hierarchy is not excessively burdensome. The ability to intercept and redefine handles would be worth a modest speed tradeoff today - and we are scheduled to have 10 GHZ computers by the end of this decade. Of course the debate is academic. The Rev. team has years worth of bug fixes to address before reworking the engine. Paul Looney -Original Message- From: J. Landman Gay [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Sun, 16 Oct 2005 23:38:59 -0500 Subject: Re: FORTH and Hypercard Stephen Barncard wrote: I also liked a feature of Hypercard that was like forth - you could redefine and intercept a lower level handler using the same name. I guess it was a design decision to not allow that in Transcript but why? Speed. Raney wouldn't put it in, and now that I'm used to it, I agree with his decision (though I argued with him about it at first.) In order to override a built-in token with a handler of the same name, all commands would have to pass through the message hierarchy. As it is now, they go directly to the engine which is one of the reasons that Rev is so fast. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
[EMAIL PROTECTED] wrote: Jacque, I wonder if Scott would come to the same conclusion today. On modern computers messages can transverse the entire path in nanoseconds. True, though knowing Scott Raney he wouldn't change it even now. However, the reason I changed my mind about the theoretical problem was that I couldn't think of any good reasons why I needed the behavior. I was used to it in HyperCard, of course, and it came in handy when I was trying to fix other people's stacks. But when I really thought about it, there wasn't any good reason to override command behaviors in my own work. It was just as easy to write a handler with its own name and call that. The only time I really wanted override behavior was to fix a client stack that came to me with a play command on every one of about 500 cards. The stack would play irritating sound effects on every user action and it was driving the client nuts. They wanted me to remove the sounds. In HyperCard I could have overridden the behavior with a single play handler at the stack level, but as it was I needed to go through all the cards and remove the commands from each one. But if I was writing my own stack, I would have just created a single handler at the stack level to begin with, which would be easy to change. So, aside from fixing other people's bad code, I couldn't think of any reason to ask for the behavior. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
Jacque, I'm thinking primarily of menu commands (stored in a setup plugin) which work differently if used in a single-users stack or a multi-user database (things like new card, next card, etc.) In HC you could change the behavior of a script depending on whether a netWorkOn variable was true or not. Of course I can (and do) now send messages with menuPicks that are different in one-card client stacks and multi-card data stacks. Change is good...change is goodchange is Paul Looney -Original Message- From: J. Landman Gay [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Mon, 17 Oct 2005 12:35:14 -0500 Subject: Re: FORTH and Hypercard [EMAIL PROTECTED] wrote: Jacque, I wonder if Scott would come to the same conclusion today. On modern computers messages can transverse the entire path in nanoseconds. True, though knowing Scott Raney he wouldn't change it even now. However, the reason I changed my mind about the theoretical problem was that I couldn't think of any good reasons why I needed the behavior. I was used to it in HyperCard, of course, and it came in handy when I was trying to fix other people's stacks. But when I really thought about it, there wasn't any good reason to override command behaviors in my own work. It was just as easy to write a handler with its own name and call that. The only time I really wanted override behavior was to fix a client stack that came to me with a play command on every one of about 500 cards. The stack would play irritating sound effects on every user action and it was driving the client nuts. They wanted me to remove the sounds. In HyperCard I could have overridden the behavior with a single play handler at the stack level, but as it was I needed to go through all the cards and remove the commands from each one. But if I was writing my own stack, I would have just created a single handler at the stack level to begin with, which would be easy to change. So, aside from fixing other people's bad code, I couldn't think of any reason to ask for the behavior. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
J. Landman Gay wrote: [EMAIL PROTECTED] wrote: Jacque, I wonder if Scott would come to the same conclusion today. On modern computers messages can transverse the entire path in nanoseconds. True, though knowing Scott Raney he wouldn't change it even now. However, the reason I changed my mind about the theoretical problem was that I couldn't think of any good reasons why I needed the behavior. Yeah, I got all up in Scott's face over that once, insisting it was absolutely necessary to support. He asked me for a test case where no alternative was available to accomplish a given goal, and darnit I never did come up with one. :) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
Richard- Monday, October 17, 2005, 2:37:20 PM, you wrote: Yeah, I got all up in Scott's face over that once, insisting it was absolutely necessary to support. He asked me for a test case where no alternative was available to accomplish a given goal, and darnit I never did come up with one. There are cases where I'd really *like* to have the facility, but none that I can think of that I can't work around. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
Jacque- Monday, October 17, 2005, 10:35:14 AM, you wrote: True, though knowing Scott Raney he wouldn't change it even now. There shouldn't really be much of a speed difference - the way this is usually handled is you create a hash table with the overloaded functions. If there's a match in the hash table then you process it locally, otherwise you move right on to the builtins. So the only hit you take is in a quick lookup in the hash table. It's a direct lookup, it's either there or it isn't, and it's compiled and optimized. Should actually take less overhead than a scripted function call. I sense an inherent incompatibility between the folks who want more speed out of the basic engine calls (arrays and such) and the folks who want the flexibility of overloading the builtin functions. I fall more in the latter category, but not enough to want things to change (and possibly break existing behavior). -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
Mark Wieder wrote: Jacque- Monday, October 17, 2005, 10:35:14 AM, you wrote: True, though knowing Scott Raney he wouldn't change it even now. There shouldn't really be much of a speed difference - the way this is usually handled is you create a hash table with the overloaded functions. If there's a match in the hash table then you process it locally, otherwise you move right on to the builtins. So the only hit you take is in a quick lookup in the hash table. It's a direct lookup, it's either there or it isn't, and it's compiled and optimized. Should actually take less overhead than a scripted function call. I sense an inherent incompatibility between the folks who want more speed out of the basic engine calls (arrays and such) and the folks who want the flexibility of overloading the builtin functions. I fall more in the latter category, but not enough to want things to change (and possibly break existing behavior). I can't think of a reason to change it either, but there's no law against putting in a Bugzilla feature request if someone really wants it. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
In 1980 I worked with Kenny Jones (now at Digital Domain) at a place called New World Pictures. We worked on a machine called the Elicon, a camera control robot that was programmed in FORTH, and made movie special effects for Roger Corman and others. It was a beautiful piece of work - dc servo motors driven from a huge interface panel and a PDP-11. I liked FORTH a lot. I had an implementation of FORTH for the Apple ][ that screamed. UI was a command line. I also liked a feature of Hypercard that was like forth - you could redefine and intercept a lower level handler using the same name. I guess it was a design decision to not allow that in Transcript but why? sqb Mark, One of the great things about Forth was the overhead of just a few machine language instructions to execute a high level function call. Transcript seems to require a trip around the world to jump next door. For GUI speed stuff, it would not be a problem, but for my array crunching stuff, I am stuck writing everything in one handler to keep the speed up. The convenience of having an environment like that would be very tempting to use for whatever could stand the overhead --and that might be quit a lot of applications. Dennis -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
Stephen- Sunday, October 16, 2005, 6:47:15 PM, you wrote: I also liked a feature of Hypercard that was like forth - you could redefine and intercept a lower level handler using the same name. I guess it was a design decision to not allow that in Transcript but why? Yes, that's the keyword overloading feature I'm wishing we had... not that I would wish Forth syntax on Transcript, but its extensibility is the stuff dreams are made of. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
On Oct 16, 2005, at 6:47 PM, Stephen Barncard wrote: I also liked a feature of Hypercard that was like forth - you could redefine and intercept a lower level handler using the same name. I guess it was a design decision to not allow that in Transcript but why? I believe it's because of the overhead involved. Calling a user- defined routine takes extra time because of the need to track down which code should be executed -- the one in the object, the one in the group, the one in the card, the one in any of the stacks in use, the frontscripts, etc. Calling a native routine has no such overhead. If native routines could be overridden, they would all have the overhead of user routines, which would slow them down. Bear in mind I've never touched the engine's source code, and this is just a vague memory from a conversation with Scott or Tuviah. gc ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: FORTH and Hypercard
Stephen Barncard wrote: I also liked a feature of Hypercard that was like forth - you could redefine and intercept a lower level handler using the same name. I guess it was a design decision to not allow that in Transcript but why? Speed. Raney wouldn't put it in, and now that I'm used to it, I agree with his decision (though I argued with him about it at first.) In order to override a built-in token with a handler of the same name, all commands would have to pass through the message hierarchy. As it is now, they go directly to the engine which is one of the reasons that Rev is so fast. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
