ir230@sdcc6.ucsd.edu (john wavrik) (06/05/90)
Mitch Bradley writes, >> John Wavrik writes ... >> If Forth retains is main asset, the ability of users to add major >> features to the language, the dispute between "minimalists" and >> "kitchen sinkists" disappears. > I disagree. As a "kitchen sinkist", I believe that many people > choose not to use Forth because it is lacking so much. Certainly it > is *possible* to "roll your own" major features, but who has the > time, either to write the feature packages or even to dig around on > bulletin boards in hopes of finding quality public domain > implementations of the needed packages? Then let me try again, because this is really something Mitch Bradley should agree with. 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. 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. Now the fact of the matter is that there is no best memory allocation scheme. Some applications may require a scheme for allocation and recovery of random size blocks (garbage collection), some can use a much simpler scheme for fixed size blocks, some can do quite well with static allocation. The Forth literature has examples of all types of storage management mechansisms that can be added to Forth systems. 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. Some languages provide features. Forth provides the ability to build features. As long as this is retained I see the possibility of both groups being happy. 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. So, as I see it, the minimalists would like to preserve the fundamental language building tools -- allowing users to build and modify language features (certainly making for more richness than a fixed set of built-in features). Mitch Bradley would like the glossaries of certain popular add-ons specified. There really is no conflict. Minimalists don't have to load a floating point module if they don't want to -- but if they do, it would be nice that code written for it will run on other people's floating point package too. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
bouma@cs.purdue.EDU (William J. Bouma) (06/07/90)
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 <bouma@cs.purdue.edu>
dwp@willett.UUCP (Doug Philips) (06/10/90)
In <10775@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes: > 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. I think this is an interesting question. I suspect that the answer lies along the line of difference between 'conforming' programs and 'conforming' implementations. > 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... And now that we have a (proposal for a) set of memory allocation words you can write your own (stack/heap/GC'ing) collector on top of them. What's there (in BASIS12) is definitely a step in the right direction. (I don't know whether or not it should be the last step, though.) > The interfaces to such important and much used things should be > specified in a standard. Yes, that is pretty much what the standard seems to say. The dictionary is quite a different matter. Perhaps Mitch or someone else can enlighten us as to how the dictionary structure issues were resolved? -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]