Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!dino!ux1.cso.uiuc.edu!iuvax!purdue!bouma From: bouma@cs.purdue.EDU (William J. Bouma) Newsgroups: comp.lang.forth Subject: Re: interactive control structures Summary: line input Message-ID: <9167@medusa.cs.purdue.edu> Date: 5 Jan 90 18:26:50 GMT References: <9001050440.AA25729@jade.berkeley.edu> Organization: Department of Computer Science, Purdue University Lines: 44 In article <9001050440.AA25729@jade.berkeley.edu> Forth Interest Group International List writes: >But, back to the discussion of the temporal aspects of interpretation >and compilation: I see three possibilites: > >1) The traditional Forth model: A line of input is collected, then > the words on that line are executed one-at-a-time > >2) The "compile-a-line-model": A line of input is collected, compiled > as a unit, and then executed. (As in Antero Taivalsaari's system) > >3) The LaForth model: The system reads a word from the input device, > executes it, reads the next word, executes it, etc. > >Analysis: > >(3) appeals to me from an intellectual standpoint; the basic execution >unit of Forth is a word, so why should the unit of input be a line? > The reason I like (1) is because I like command line history/editing. Although the unit of execution is one word, often a unit of meaning is a group of words. I prefer to type in a line of junk I want done, decide that that is indeed what I want, then signal the computer to do that by hitting . It appeals to me to have this happen: ok, 1 . 2 . 3 . 1 2 3 ok, Rather than this: ok, 1 . 1 2 . 2 3 . 3 ok, The difference between (1) and (2) is very slight. I don't see a big deal here. If you want to compile the input when it contains a control structure, go ahead. All it does is saves the user a few keystrokes of defining a word and executing it. -- Bill || ...!purdue!bouma