Path: utzoo!attcan!uunet!know!cs.utexas.edu!yale!cmcl2!acf5!sabbagh From: sabbagh@acf5.NYU.EDU (sabbagh) Newsgroups: comp.lang.forth Subject: Re: Files VS Blocks, a compromise Message-ID: <1267@acf5.NYU.EDU> Date: 18 Oct 90 13:56:32 GMT References: <3540@mindlink.UUCP> <33553@nigel.ee.udel.edu> <1990Oct16.145349.5770@cbnewse.att.com> Reply-To: sabbagh@acf5.UUCP () Distribution: na Organization: New York University Lines: 85 I had decied to keep quiet on this debate, but I just have to open my big mouth. First, I should say that I have the greatest amount of experience with C, including the ANSI standardization effort. I know many other languages and am now programming intensively in Bradley's C Forth 83 (well worth the $50). I believe firmly in two concepts: 1) drawing from the experience of others, even if they don't like Forth and 2) considering carefully the non-CS issues of a language, e.g., why is a feature present, who is using it, etc. On the subject of Files vs. Blocks, I have concluded: 1. Both files and blocks need to be supported, since many programs use blocks in their implementations. 2. The standard needs to separate blocks from the interpretation process, i.e., INTERPRETATION SHOULD BE INDEPENDENT OF INPUT STREAM. Note that this breaks the >IN, BLK words. Even though there are many programs written that use this, IT IS BAD CODE. It relies too heavily on the underlying DEVELOPMENT ENVIRONMENT. Forth is different from most other languages (closest to Lisp, I think) in its great extensibility. This is characterized by the fact that one can write both development tools and applications in the language, with little difficulty. However, the development tools should be as portable as humanly possible, even if the applications are not. I am surprised at this irony: by standardizing the "right things" in Forth, it can easily be the most portable language in existence. What are some of the "right things"? 1. Standardized data structures. E.g., represent all strings as "addr len" on the stack, regardless of their internal representation (see below). 2. Standard data types, using something like CELL. Note that C has never really specified what a short, int and long are; they are always "the most natural for the underlying machine". Forth should act the same way, with programmers referring to standard machine constants to make their software work. 3. Better factorization. Vocabularies are really sets of (word, definition) pairs. The user should be spared knowing the underlying implementation and should only access the capabilities through deferred words. That way, you can have binary tree or hashed vocabularies in the same system. Finally, two modest proposals: 1. Make allot a deferred word. Whenever a programmer develops a new data structure (e.g. FOO_STRUCT), he should factor the create and allot parts (FOO_STRUCT.ALLOT). Then, if he needs an instance of this data structure to be placed on the heap, ALLOT can be deferred to the MALLOC type call. Note that this need not be standardized; its just a neat Forth trick. 2. Support PRIVATE & PUBLIC words in a vocabulary, i.e., stand- ardize some mechanism whereby users of wordsets implemented in Forth can figure out what parts are interface and what are implementation. This is germane to the "addr len" issue above, because, if you a writing the next great string package, you really can't guarantee that "addr len" will ALWAYS be the string rep on the param stack, but you can guarantee if for INTERFACE WORDS. This will make Forth easier to learn, by allowing the user to ignore data structures used in the implementation of new features and concentrate on those data structures necessary for the feature. Being relatively anonymous in the Forth community, I don't expect this stuff to reach "the powers that be", but it is certainly worth considering. Hadil G. Sabbagh E-mail: sabbagh@cs.nyu.edu Voice: (212) 998-3125 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 "No talking to invisible people." - Sign in Top Dog, Durant Ave., Berkeley Disclaimer: This is not a disclaimer.