Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!purdue!bouma From: bouma@cs.purdue.EDU (William J. Bouma) Newsgroups: comp.lang.forth Subject: Re: Min vs Kitchen Keywords: No conflict revisited Message-ID: <10775@medusa.cs.purdue.edu> Date: 6 Jun 90 18:25:24 GMT References: <11210@sdcc6.ucsd.edu> Organization: Department of Computer Science, Purdue University Lines: 73 In article <11210@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: > >I think, looking over what is written, the disagreement comes from >confusing the idea that users have the ABILITY to do something with >the idea that the are FORCED to do it. I have the ability to do many >things that I choose to pay others to do for me. I share with Mitch >the idea that enriched features should be available for Forth -- and >I think that there is no objection to having certain popular features >equipped with a commonly agreed upon glossary. > >What needs to be clear, however, is the distinction between "add-on" >and "built-in". If a user needs floating point, it should be possible >to add it on. Surely even the staunchest minimalist can't object to >a package which is loaded if needed. > Is that "add-on" (say, floating point) part of the standard then or not? If so, then what difference does it make if I include it in my forth core? What if I provide the ability to strip it out of an app- lication that doesn't need it? If it is not part of the standard, then I am free to write my own package. If I write a standard program that uses that package, others will have to load my package to use my program. Thus my application carries around this extra baggage. Also, my word set may conflict with that of another application you want to run in tandem with it. My point is that you cannot have a standard without specifying it! I can understand that you don't want to destroy the "free form" nature of forth by specifying it at too high a level. But I do not believe you can have much of standard if you do not. If you provide packages for standard high level operations, it should not be an issue whether they are pre-loaded or not. > >An even better example is memory allocation packages. Most languages >require such things to be built-in -- and you are stuck with the >language designers choice. Examples please? What are these "most languages" and schemes? You would say lisp has only garbage collection available? There is nothing in lisp preventing me from allocating a chunk of memory and doing my own resource management on it. > >I think that we are all after the same thing -- the richness and >power of the language. Forth allows an even richer and more powerful >possibility than most languages: the user can select a storage >management scheme appropriate to the application. It is this richness >that I want to preserve. > Again, how is this different from C with its ability to load library functions? I have packages in C for doing different types of memory management. All I need to know is the interface functions and off I go... > >How can this be lost? By removing from the definition of the language >the tools that are needed for building language features. You can make >the mistake of trying to standardize the language at too high a level. > And you can make the opposite mistake and end up with no standard at all. Personally I feel that stuff like floating point and memory man should be left to the language designers for a particular machine architecture. Applications programmers just don't have the time to mess with that junk. The interfaces to such important and much used things should be specified in a standard. The problem with most languages is that not enough is specified. People waste time re-doing what has already been done or re-writing things to make compatible. -- Bill