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