a684@mindlink.UUCP (Nick Janow) (10/15/90)
How about if we drop the whole argument and go to a hypertext file system? :-) Click on a word, and a window with that word's words pops up. Click again, and the stack effect pops up. Another window shows a graph of resources used by the word. C'mon FORTHers, this is the 90's: the Information Age. Let's take the leading edge of programming! Now all we need is for someone to write a smart editor to do this, with little effort required from the user. Shareware or Freeware please. :-)
rvn@forth.mlb.semi.harris.com (Rick VanNorman) (10/15/90)
The current controversy over FILES vs BLOCKS has bubbled to the top of the topics list again. Without trying to pound either viewpoint into the ground, here is a modest proposal that I believe represents a compromise between the two positions. The arguments have been made, pro and con, for each of the two approaches to handling Forth mass storage. Each of the arguments has merit. I will not attempt to describe, summarize, or otherwise butcher these arguments. Let me simply assume that I want to use files, but I want as many of the benefits of using blocks that I can get. I propose using a virtual program page model for files -- each page being roughly equivalent to an almost free-format block. The limits on page size are arbitrary, but a size equal to one printed page seems reasonable, say 80 columns by 60 lines (4800 bytes). Writing a page editor such as this is relatively trivial; although not quite as easy as a block editor, it is still within the range of a 4K byte extension in most Forth systems. Text could be imported into the editor from normal Ascii files -- the import procedure would take tabs, crlf, etc., and put them into the fixed size buffer, with all white space occupying a character position just like in blocks. Editing would be simplified by this model, with the only major extension over block editing being the requirement to scroll the visible portion of the page up and down. "But wait!" you shout, "One 80 x 60 page isn't enough!" I further propose that files consist of multiple pages, each delimited by a simple comment character string, or perhaps by the page feed character (0CH) embedded in the file (implementation detail, irrelevant to the current discussion). My own scheme is to use a string such as " \-----" to delimit pages. When you edit a file, the editor will import text from the specified page while noting the start and end offset within the file of the page. When editing is complete, the edited page will be re-inserted into the file. If you need more space in a page, simply insert the page delimiter into the edit image (in effect, splitting the page into two), flush the page, and re-edit. The editor only cares about what the text it reads looks like, not about what it writes. If you want to combine two pages, simply delete the delimiter at the top of the current edit image and flush. The current page will be combined with the previous page. Since this editor can be integrated into a Forth environment, partial loads of a text file are now simple, turn-around in the edit-compile-test loop is very quick, and an external editor may still be used anytime it is needed. This approach will (I believe) give all the versatility of both blocks and files to a self-contained Forth environment. I am still in the process of implementing this scheme in my current environment, and would appreciate any and all feedback.
carroll@cis.udel.edu (Mark Carroll) (10/16/90)
In article <3540@mindlink.UUCP> a684@mindlink.UUCP (Nick Janow) writes: > >Click on a word, and a window with that word's words pops up, Click again, and >the stack effect pops up. Another window shows a graph of resources used by >the word. > >C'mon FORTHers, this is the 90's: the Information Age. Let's take the leading >edge of programming! > >Now all we need is for someone to write a smart editor to do this, with little >effort required from the user. Shareware or Freeware please. :-) Don't laugh - I'm actually thinking about doing something like this. I've had this idea in the back of my mind, for a long time, to create myself a language that would really let me take advantage of my style of hacking. The only thing stopping me from starting it was an uncertainty about exactly what I wanted out of the language. Forth has always interested me, because it's a very simple, flexible model of programming. But (please, don't flame me!!) it's always had a rather clunky, archaic feel to it. You're locked into this dreadful screens model, which I hate, and you have no built in way of handling data structures, which I feel are a necessity. Then, about a week ago, I found Fifth. Fifth is FAR from what I'm looking for, but it gave me the ideas that I needed. I still want more from the language: I want to be able to have a module export more than one word, I want data structures, etc. But the basic model is wonderful. What I'm looking at doing is implementing something like Fifth, with a lot of extensions, but still based on the same Forth model, only with a fancy xwindows browser programming interface. <MC>
rcv@forth.mlb.semi.harris.com (Rick VanNorman's alter ego) (10/16/90)
In <3540@mindlink.UUCP>, a684@mindlink.UUCP (Nick Janow) writes: > How about if we drop the whole argument and go to a hypertext file > system? :-) > > Click on a word, and a window with that word's words pops up. Click > again, and the stack effect pops up. Another window shows a graph > of resources used by the word. I agree, this would be a wonderful toolset for Forth. However, my goals for my own personal Forth environment are different -- I want an environment and language that will let me develop applications, small and large, quickly. Furthermore, I want to be able to understand, to hold in my immediate conscious awareness, the entire system. I also want (intend) to do the entire implementation myself, as this leads to an un-paralleled understanding of it. (For me, having no mysteries in the environment makes programming in the environment easier.) BTW, this is almost what Tom Zimmer's FPC v3.53 does -- using a data base to index the words and their documentation, and allowing the user to point with a mouse to chase down all the components of a definition. But for myself, FPC is _too_ complex to understand all of it and remember all of its interactions at once. I need (well, maybe I simply want) a system that is much simpler than that. Rick VanNorman Staff Engineer, Software Development RTX Marketing Harris Semiconductor Melbourne, Florida, USA All opinions expressed by me, real or otherwise, are my own.
ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman) (10/16/90)
Mark Carroll <cis.udel.edu@LOUIE.UDEL.EDU> writes: >In article <3540@mindlink.UUCP> a684@mindlink.UUCP (Nick Janow) writes: >> >>Click on a word, and a window with that word's words pops up, Click again, and >>the stack effect pops up. Another window shows a graph of resources used by >>the word. >> >>C'mon FORTHers, this is the 90's: the Information Age. Let's take the leading >>edge of programming! >> >>Now all we need is for someone to write a smart editor to do this, with little >>effort required from the user. Shareware or Freeware please. :-) > >Don't laugh - I'm actually thinking about doing something like this. > It's already been done, at least I think it has. A couple of years ago George Hawkins on the East Coast Forth Board was working on a project almost exactly like this using FPC as his base system. I remember that he was uploading versions of the code to ECFB so it may have filtered out into the other bulletin boards on ForthNet. Sorry but I don't remember the name of George's program. George is a really bright guy and a hell of a Forth programmer. He and I used to have a lot of fun shooting messages back and Forth. He implemented the single finest string package I ever saw in Forth, it was very complete and generalized. The package did not rely on the underlying structure of the string, although all strings it operated on had to be of the same type. Basically there was a set of two or three primitives that knew what the strings looked like, and the rest was built from there. Also the package was written to comply with Forth-83 completely -- a task which convinced George that Forth-83 alone is not sufficient to write code that does anything. Anyway, George's Forth system was supposed to work as a graphical tree display and had control-key commands for creating new words by filling in the trees. The system had the documentation built in to the graphical display. I never actually used it myself (for one thing all the source together wouldn't fit on a single *1 Megabyte* floppy, and I didn't want to download it). Like I said, it should be around somewhere, probably in with other files for the FPC Forth system. I wonder what ever happened to old George. He dropped out of the ECFB scene even before I did a year or so back. George? George Hawkins? Are you out there, buddy? -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM Internet: zmleb@scfvm.gsfc.nasa.gov -- "Prayer: the last refuge of a scoundrel." -- Lisa Simpson
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (10/16/90)
In article <3540@mindlink.UUCP>, a684@mindlink.UUCP (Nick Janow) writes: > > How about if we drop the whole argument and go to a hypertext file system? :-) Then it becomes FIFTH, an actual FORTH with a Browser front end! > > Click on a word, and a window with that word's words pops up. Click again, and > the stack effect pops up. Another window shows a graph of resources used by > the word. > > C'mon FORTHers, this is the 90's: the Information Age. Let's take the leading > edge of programming! > > Now all we need is for someone to write a smart editor to do this, with little > effort required from the user. Shareware or Freeware please. :-) Again FIFTH is available as Shareware. I'd like to ( see it ) improve, tho...
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (10/16/90)
In article <33553@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes: > Then, about a week ago, I found Fifth. Fifth is FAR from what I'm looking > for, but it gave me the ideas that I needed. I still want more from the > language: I want to be able to have a module export more than one word, > I want data structures, etc. But the basic model is wonderful. > > What I'm looking at doing is implementing something like Fifth, with > a lot of extensions, but still based on the same Forth model, only with > a fancy xwindows browser programming interface. > > <MC> Hi, I'd help with Design and Implementation If we based it on Display Postscript rather than "brain Dead" X. Really! We could then put X on top of that for sales. FIFTH people have a custom Postscript, and NEWS (SUN) and NEXT all are DPS based. Seriously in Fun, Clyde
sabbagh@acf5.NYU.EDU (sabbagh) (10/18/90)
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.
wmb@MITCH.ENG.SUN.COM (10/19/90)
> Hi, I'd help with Design and Implementation If we based it on Display > Postscript rather than "brain Dead" X. Really! We could then put X > on top of that for sales. FIFTH people have a custom Postscript, > and NEWS (SUN) and NEXT all are DPS based. The intersection of the set of Forth users and the set of PostScript-based window system users is pretty small. This is one of those things that would be a lot of fun to implement, and nobody (to a first approximation) would use it. The intersection of Forth and X is about the same size. By the way, the fact that the Fifth people have implemented PostScript in Fifth is pretty much useless for our purposes; that PostScript clone was developed under contract to a manufacturer of laser printers, whose name the Fifth people are not allowed to disclose. I don't know myself; I asked Paul Snow directly, and he wasn't allowed to answer. Mitch
wmb@MITCH.ENG.SUN.COM (10/19/90)
> 1. Make allot a deferred word. Whenever a programmer develops
You need to defer HERE along with ALLOT .
Unfortunately, Forth's ALLOT is poorly conceived, because you have to
get the address with HERE *before* you tell ALLOT how much data you need.
This pretty much kills the possibility of implementing ALLOT with MALLOC ,
constraining the data space to be contiguous.
In all my recent code, I declare data structures with:
BUFFER: \ name ( size -- ) ( Child: -- adr )
Example:
100 BUFFER: FOO
FOO 100 44 FILL
The simplest implementation is:
: buffer: \ name ( #bytes -- )
create allot
;
A more sophisticated implementations might look like:
: buffer: \ name ( #bytes -- )
create allocate-memory , does> @
;
Another variation, which could be SAVE-FORTH'ed would link all buffers
into a static chain and automatically allocate their memory at startup
time. The variation I use in the Sun firmware automatically allocates
the memory the first time the data structure is accessed.
Which definition of BUFFER: to use depends on the system constraints
(ROM vs. RAM, serially-reusable or not, etc). Applications are insensitive
to the implementation of BUFFER: .
Mitchpeter@ficc.ferranti.com (Peter da Silva) (10/24/90)
In article <9010191336.AA15738@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: > The intersection of the set of Forth users and the set of PostScript-based > window system users is pretty small. Not at all. Since PostScript *IS* Forth, the intersection is equal to the second set. Though one might argue that *that* is pretty small. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com