Xref: utzoo comp.lang.forth:582 comp.lang.smalltalk:696 Path: utzoo!attcan!uunet!husc6!bbn!uwmcsd1!nic.MR.NET!umn-d-ub!gandreas From: gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) Newsgroups: comp.lang.forth,comp.lang.smalltalk Subject: Dynamic Bindings (was Re: Forth Preprocessor) Summary: Dynamic Binding Good Message-ID: <498@umn-d-ub.D.UMN.EDU> Date: 23 Sep 88 20:43:15 GMT References: <13613@mimsy.UUCP> <3492@phri.UUCP> <23378@wlbr.EATON.COM> <1642@crete.cs.glasgow.ac.uk> Reply-To: gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) Organization: University of Minnesota, Duluth Lines: 46 In article <1642@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes: [ stuff deleted ] > A classic example of this is types. Some systems mark the elements > on the stack with their type (e.g. PostScript), thus requiring > run time type checking. This is expensive and since it gives > dynamic binding, not good. Hubert Matthews suggested that these ^^^^^^^^^^^^^^^^^^^^^^^^^ > wonder forth chips should be extended to have an extra stack for > this purpose (the do it in hardware approach), this certainly > doesn't deal with the dynamic binding issue though and seems to > be rather a waste of memory and chip space (yes I suppose forth > has plenty of both to waste...) [ more deleted ] >Regards, > >===Fraser WAIT WAIT WAIT WAIT. Just one minute Fraser. While you have had some valid ideas before, this time I think you've made a mistake. Why is dynamic binding bad? You seem to say that besides the issue of run time performance, tagging data elements (for run time checking) gives you the bad feature of dynamic binding. Well tell that to all the users of Smalltalk (which is why I've cross posted this there). No, wait, I just did. ;-) Dynamic binding is GOOD. This is what enables Smalltalk to do some of the things it does - dynamic binding. While it is true that a majority of the "calls" in Smalltalk could use static (compile time) binding, without dynamic binding, we might as well use Ada. In order to truly be an object oriented language, you need dynamic binding - static binding just does not do. Adding object-oriented features to Forth would make it more powerful and easier to use, two of the goals that you have in mind behind your Forth preprocessor. (Note that this will not make Forth and object oriented language in the same sense that Smalltalk is, rather it would simply be a language with object oriented feature, but it could be a start - and Forth and Smalltalk both have a lot in common in many of their design philosophies) BTW: I am currently playing with a modification to a Forth-like language that has a clean implementation of object-oriented message passing, written entirely in C for Unix machines. Maybe I'll even finish it some day. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Now that isn't | Glenn Andreas = = enough" - Alex P. Keaton | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=