Jump to content

Talk:Forth (programming language)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 80.100.243.19 (talk) at 13:14, 15 February 2011 (→De facto?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing: CompSci GA‑class Mid‑importance
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
GAThis article has been rated as GA-class on Wikipedia's content assessment scale.
MidThis article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computer science (assessed as Mid-importance).
Things you can help WikiProject Computer science with:
Good articleForth (programming language) has been listed as one of the Engineering and technology good articles under the good article criteria. If you can improve it further, please do so. If it no longer meets these criteria, you can reassess it.
Article milestones
DateProcessResult
June 4, 2006Peer reviewReviewed
June 21, 2006Featured article candidateNot promoted
June 23, 2006Good article nomineeListed
June 25, 2006Featured article candidateNot promoted
November 24, 2006Featured article candidateNot promoted
March 11, 2009Good article reassessmentKept
Current status: Good article

TO DOs

Mostly as a reminder to myself, here is a list of topics that could be covered by the article. However, most of this is probably too specific for an encyclopedia. I think the article already says most of what would be of interest to a casual reader.

  • typical length of Forth words, general layout of Forth code, stack comments, shadow screens, more on blocks?
  • vocabularies, wordlists (MARKER, FORGET)
  • cells and standard data types (doubles etc.)
  • memory allocation and cell alignment (HERE, comma, ALLOT, ALIGN, ALIGNED, PAD, ALLOCATE, FREE)
  • use of the return stack to reduce "stack gymnastics", interaction of looping constructs with the return stack, locals
  • explain naming conventions, explain bracketing convention for pairs of immediate and non-immediate words ('/['], CHAR/[CHAR], IF/[IF])
  • case (in-)sensitivity during parsing; some (older) Forths store word names as the leading (five?) characters plus the name length.
The first Forths stored three. Ideogram 15:59, 20 June 2006 (UTC)[reply]
  • definition words like CREATE/DOES>
This is a pretty important feature of Forth but difficult to explain. Ideogram 15:59, 20 June 2006 (UTC)[reply]
  • object-oriented extensions of Forth (mention object-method vs. method-object debate)
  • [IF], [THEN], [ELSE])
  • code examples

— Tobias Bergemann 15:38, 20 June 2006 (UTC)[reply]

I think this article is already up to FA standards since the primary objection about not enough citations has been addressed. But by all means feel free to improve it further. If you can explain these concepts to a nontechnical reader it can only help. Ideogram 15:59, 20 June 2006 (UTC)[reply]

Untrue Statements

The statement that "C compilers may now generate code with more compactness and performance" is NOT true. Modern Forth systems are executing at 1000x the speed of equivelant C code when they are writen from scratch from the same requirements. This statement should be given a reference or removed. —Preceding unsigned comment added by 97.65.82.66 (talk) 15:29, 13 September 2010 (UTC)[reply]

....? What? You can't just say that an not give an example of a system that went written in Forth is "1000x" faster. —Preceding unsigned comment added by 134.151.33.148 (talk) 17:24, 15 January 2011 (UTC)[reply]

GA

I don't know about the FA but it is GA status as of now. Lincher 04:01, 23 June 2006 (UTC)[reply]

Good job everyone. Now on to Featured Article! Ideogram 04:22, 23 June 2006 (UTC)[reply]

Online interpreters

This section mentions two 'Forths' that break at the slightest typing error (unrecoverable), and in no way represent modern Forth. I say they are curiosities that should be deleted? Mhx 19:32, 12 July 2006 (UTC)[reply]

Sounds good to me. --Ideogram 01:20, 13 July 2006 (UTC)[reply]

Influences: sources

Influenced by B5500 - Chuck's HOPL II draft (The Early Years) Influenced Open Firmware - claimed on page (obvious) Influenced Factor programming language - claimed prominently on the author's web page.

On second look, it appears PostScript was also influenced by the B5500, via InterPress and John Gaffney. See the link at the bottom of the InterPress page. --IanOsgood 01:00, 14 July 2006 (UTC)[reply]

The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was PAGE MOVED per discussion below. Even got the target right on the second try. -GTBacchus(talk) 07:07, 1 December 2006 (UTC)[reply]

Requested move

Forth → Forth programming language — Additionally move Forth (disambiguation) to Forth. Forth is ambiguous and until 1 April 2006 was a disambiguation page. This merely reverts the earlier move. Angus McLellan (Talk) 15:36, 24 November 2006 (UTC)[reply]

Survey

Add  * '''Support'''  or  * '''Oppose'''  on a new line followed by a brief explanation, then sign your opinion using ~~~~.

Discussion

Add any additional comments:

As Kieran said, it should be Forth (programming language), not Forth programming language. --Piet Delport 22:54, 24 November 2006 (UTC)[reply]

Nothing to stop the administrator who closes this taking note of the preferred move target, just so long as debate concerning that doesn't prevent this being moved to Forth (programming language) or Forth programming language, whichever is preferred. Angus McLellan (Talk) 20:05, 27 November 2006 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Early Forth history

Is there a reason the article doesn't mention early Forth history? I mean the "pre-standard" era when FIG Forth and Forth Inc. were King and Queen? Isn't it curious that the article has many links to the FIG Forth site, but FIG doesn't even merit a direct mention? Also, I have several old Forth books, including Starting Forth, Thinking Forth, and Byte's Threaded Interpretive Languages. Have I just missed something, or is this info not considered important? – 2*6 05:22, 18 January 2007 (UTC)[reply]

As far as I can see, the only reason that the article doesn't talk much about early Forth history is that no editor felt knowledgable enough to add this information. It would certainly be a most valuable and important addition to the article, IMHO. —Tobias Bergemann 07:55, 18 January 2007 (UTC)[reply]
I found an excellent place to start -- The Evolution of Forth at the Forth, Inc. site. The problem is going to be condensing that information as well as having other sources so as not to be simply a synopsis of what they already did. Ack, I just checked; the article already provides a link in its History subsection of External links. Hmm, would a bulleted list of key events would fit well within the article's structure? I'm envisioning a new History section of the article which would include the bulleted list as well as include specific mention (and link) to the Evolution piece. Hesitant to just do it on an article which has received such scrutiny. – 2*6 20:55, 18 January 2007 (UTC)[reply]
Be bold! Don't be afraid to start, even with just one source (it is a very good source, nearly authoritative). Another source would be History of Programming Languages II. --IanOsgood 15:49, 21 January 2007 (UTC)[reply]
I finally took it upon myself to split out a History section. Have at it! Aside from the notable standards like the FIG-Forth model, it might be interesting to note some of the application areas where Forth found a niche, such as robotics, machine control and space probes. --IanOsgood 18:28, 5 July 2007 (UTC)[reply]

God I used to love this language. Learned it as a teenager, and became obsessed with it. Even made my own compiler in about 4 or 5 pages of Turbo pascal. There was a really fantastic book on it, thats apparently a classic, on learning Forth. Real old book, but has a chatty and informative style that just nailed down how it works. Anyone remember what that was? ('scuse the talk page hijack here :) ) Duck Monster (talk) 00:52, 21 November 2007 (UTC)[reply]

Starting Forth. Forth, Inc. just made a web version; check the article refs. Thinking Forth by the same author is also now in e-book form. --IanOsgood (talk) 17:17, 21 November 2007 (UTC)[reply]

Merge from FCode

Stub article which is directly pertinent to Forth's use in Open Firmware. A merge would be a great way of bringing implementation details into this article as opposed to it being a how-to. Chris Cunningham 09:29, 4 July 2007 (UTC)[reply]

Shouldn't this comment be on Talk: Forth (programming language) rather than Talk:Forth? — Tobias Bergemann 10:23, 4 July 2007 (UTC)[reply]
D'oh! Moving. Chris Cunningham 10:40, 4 July 2007 (UTC)[reply]
Agreed. Although the last edit to remove threaded code I believe a mistake; it's definitely a good See Also candidate, much better than (for instance) the reference to MUF (which is in error; it should really be to MUF_(programming_language)). Alex 16:09, 4 July 2007 (UTC) (see below for a change of heart Alex 22:34, 4 July 2007 (UTC))[reply]
This article is wikilinked from within the programming section so doesn't need a seealso. Chris Cunningham 08:37, 5 July 2007 (UTC)[reply]
Disagree. FCode is an implementation detail of Open Firmware. If you must merge it, merge it into Open Firmware. --IanOsgood 19:52, 4 July 2007 (UTC)[reply]
Good point; I'm going to change my vote. Disagree. Alex 22:34, 4 July 2007 (UTC)[reply]
We need more information on actual use of Forth in this article as opposed to it being a guide to syntax. I don't mind if the merge is either way, but more implementation information needs to be added to this article at some point. Chris Cunningham 08:37, 5 July 2007 (UTC)[reply]
What do you have in mind for implementation information? The major implementations are already mentioned in the info box. To be complete is impossible (if you have n Forth programmers in a room, they are likely to be using n+1 different Forth implementations, since a basic Forth is so easy to implement).
Actually, what does this article need? Is there a style guide for what topics should be covered in a programming language article? Personally, I think this article should be more of a general overview (summary, concepts, culture, history, short example) and less about syntax and implementation details. For example, the detail sections such as Forth (programming language)#Dictionary entry which use "Starting Forth" as a reference are totally obsolete. There is the WikiBook b:Forth and the many online tutorials for getting into the nitty-gritty details. --IanOsgood 16:51, 5 July 2007 (UTC)[reply]
I haven't seen an actual guide, but you're absolutely right about how it should be laid out and that's what I normally aim for. Right now we're very syntax-heavy.
For implementations I meant giving a little more time to the most common real-world implementations of Forth. At the moment most are basically just rattled though. Open Firmware is the biggie for me I suppose. Chris Cunningham 17:06, 5 July 2007 (UTC)[reply]
Found the style guide from the CS project page, and copied it into Wikipedia:WikiProject Programming languages. This article is giving way to much detail. In fact, I think everything from "Programmer's Perspective" down to "See also" should be moved to the b:Forth. The condensed concepts would fit in just a few paragraphs.
An Implementations section is suggested. The challenge for Forth is drawing the line at what constitutes major, since there as so dang many implementations out there supporting zillions of desktop and embedded platforms, compared to more centrally managed languages like Python and Ruby. I'll start it off with my shortlist. --IanOsgood 17:32, 5 July 2007 (UTC)[reply]

Removal of the "Structure of the language" section

I reverted the removal of the "Structure of the language" section. While I agree that the article can do with some major restructuring I do not agree that the section contains "hopelessly outdated and overspecific details of Forth internals", to quote IanOsgood's reasoning for the removal. At least the notion of immediate words needs to be explained as they provide the central mechanism for extension of Forth. — Tobias Bergemann 07:48, 6 July 2007 (UTC)[reply]

Very little of that section is of note to people who aren't looking to write an implementation of the language. I don't see that even the immediate words section need be saved; surely this is still an implementation detail? I agree with the removal. Chris Cunningham 08:03, 6 July 2007 (UTC)[reply]
How can immediate words be an implementation detail when they are the central mechanism of language extension for the users of the language? — Tobias Bergemann 08:16, 6 July 2007 (UTC)[reply]
Ah, right, sorry. The section is so opaque that I didn't get that. Chris Cunningham 08:33, 6 July 2007 (UTC)[reply]
Yes, drastic. But the article is much too long and documenting things which are both obsolete and that a casual reader does not care about. There is a reason that the ANS Forth standard does not specify implementation details, only behavior. If you were to split out a FORTH-83 article, then some of these implementation details like its dictionary structure would fit there.
I felt it safe to delete the IMMEDIATE stuff in that section because it is also covered more clearly in the final code example. --IanOsgood 14:56, 6 July 2007 (UTC)[reply]
I am still not convinced that complete removal of the "Structure of the language" section is a way to improve the article. However, I won't revert if you or anybody else removes that section again. — Tobias Bergemann 15:28, 6 July 2007 (UTC)[reply]
Here is my more detailed critique:
  • Programmers perspective: delete or move to the RPN article (the PostScript article also does this). Move the IF-THEN stuff to the Example section
  • Facilities: poor title (Interpreter? Basic syntax?)
  • OS, Files, Multitasking: retain only the lead sentence of each paragraph
  • Cross compilation: lead sentences only
  • Structure of the language: delete. This is describing a model which differs from Forth to Forth, so should not be described here in detail. The dictionary is also not the "basic data structure".
  • Dictionary entry: delete, likewise.
  • Structure of the compiler: delete or condense. If you must mention that control structure words are IMMEDIATE, do it in only one place.
  • Compilation state: delete, way too nitpicky for an encyclopedia article
  • Immedate: delete, already covered above, FORTH-83 obsolete standard
  • Execution tokens: keep a few sentences and C comparison
  • Parsing words: condense and move to discussion of compiler.
  • Structure of code: move threading stuff to the History section.
  • Data objects: ok. Maybe discuss Forth memory-model here.
  • Programming: good.
  • Code examples: good, but not Hello World. There is a whole page about hello world that already has Forth examples. Move the other snippets here.
  • Mixing state: ok. This is one of the big stumbling blocks of a new Forth programmer.
--IanOsgood 15:36, 6 July 2007 (UTC)[reply]
I still believe your proposed changes would remove too much valuable information. I agree that much of the content of the article as it currently stands is not relevant to modern Forth. However, I do think that what you call implementation details were (at least historically) defining characteristics of Forth in the sense that Forth traditionally meant threaded implementation and mixing state, and therefore I think these details relevent for an encyclopedic article. So, instead of completely removing this content, I would prefer to keep it but condense and integrate it into a "History" section.
Anyway, this is only my opinion. You are of course free to improve the article in any way you see fit. — Tobias Bergemann 09:05, 7 July 2007 (UTC)[reply]

"typeless" discipline?

Is it right to call Forth typeless? ANS defines several types. I think a more accurate description would be "static, no checking." Potatoswatter (talk) 11:16, 26 May 2008 (UTC)[reply]

Forth Humor

I wouldn't dare try to put this in the article but I have to at least mention the cartoon from a few decades back, with Yoda saying: "Forth programmer I am!"

I tinkered a bit with Forth back in the 1980s -- surprised to see it alive and well, I thought it was dead. I'll have to get back to it again. MrG 4.225.210.106 (talk) 14:34, 11 June 2008 (UTC)[reply]

Definition example

It seems to me that a better example of a definition could be found. The current one is : X DUP 1+ . . ; . It's a little confusing, as it's not quite clear what the function is supposed to do. I think we might want to show off a more obvious function, for example : DOUBLE DUP + . ; . That way, the reader can intuit the purpose of the code, and not have to spend time figuring out the intent of the function. Quentin mcalmott (talk) 07:34, 9 July 2008 (UTC)[reply]

NASA Usage

Wouldn't it be worth to link to http://forth.gsfc.nasa.gov/ ? 82.229.128.243 (talk) 12:49, 9 July 2008 (UTC)[reply]

Wow, nice link! Don't be afraid to be wp:bold with such contributions. Potatoswatter (talk) 01:00, 10 July 2008 (UTC)[reply]
 Done. Great link. It's now the reference for the sentence "Forth has a niche both in astronomical and space applications." --68.0.124.33 (talk) 16:34, 29 January 2009 (UTC)[reply]
Sadly, that link was removed by IanOsgood 18:51, 2 March 2009. I shure liked that link back. It clearly shows a niche where Forth is used much. That page is a bit old though. Johan G (talk) 20:14, 2 March 2009 (UTC)[reply]
Not at all! It was promoted to a full reference, in the opening section no less! (Every external link dreams of growing up to be a full reference.) --IanOsgood (talk) 01:45, 3 March 2009 (UTC)[reply]

did not influence PostScript

Page vii, PostScript Language Reference Manual: "Design System language and its successors (PostScript) bear a superficial resemblance to the FORTH programming language, their conception and development wer entirely independant of FORTH." Jeffz1 (talk) 02:57, 21 July 2008 (UTC)[reply]

Looking at the only version of the Language Reference I could find, the only mention of Forth is on page 23, where the entire paragraph is as follows:

Like all programming languages, the PostScript language builds on elements and ideas from several of the great programming languages. The syntax most closely resembles that of the programming language FORTH. It incorporates a postfix notation in which operators are preceded by their operands. The number of special characters is small and there are no reserved words.

I can't find the quote you have anywhere. In fact, in the index, it lists FORTH with the note "as PostScript influence". It seems to be the opposite of what you've suggested. Do you have an earlier version of the Language Reference? The one I found is the third. Quentin mcalmott (talk) 21:39, 23 July 2008 (UTC)[reply]

Yes, it's in the original publication of the PostScript Language Reference Manual, so far as I'm aware this is not online, only in print. The quote in the third edition says that it only "resembles" it does not actually say it was influenced by. In contrast, the quote from the first edition specifically says that the resemblance is only superficial and their conception, development were entirely independant of FORTH.

I've found this through google books: http://books.google.com/books?ei=nyF8SMm3MKXmtgOSu6CmDQ&id=6x4nzbwzxtEC&dq=0201101742&q=forth&pgis=1#search Jeffz1 (talk) 01:56, 24 July 2008 (UTC)[reply]

In the index of the third edition, it lists forth "as PostScript influence".
Obviously Postscript isn't Forth, but I wish we could get a better quote on it from someone that designed it. Quentin mcalmott (talk) 20:38, 24 July 2008 (UTC)[reply]

Postscript isn't Forth. Postscript was designed by many people, many of whom had probably used Forth. It was also designed by people who had used Lisp. Considering we have no standards for what an "influence" is or isn't, the statement that one language influenced the other is pretty much meaningless, even if an original PS developer made it. To someone unfamiliar enough with Forth to think that its defining quality is postfix notation, they might seem similar. Truly, both can be parsed using a negligible amount of memory. But Forth is distinguished by having two stacks, no "native" local variables, and explicitly interactive compilation, none of which PS has. Moreover, any infix or prefix language such as C or Lisp can trivially be translated to postfix. I personally learned that in my first month of compiler class, which possibly didn't even mention Forth. Therefore, let's not grasp at nebulous statements. We do know the two languages are semantically unrelated, and it's bad journalistic/historical practice to scour the record for a particular statement, in order to report it as truth. Potatoswatter (talk) 20:57, 24 July 2008 (UTC)[reply]

Potatoswatter's reasoning is fine with me, but its consequence is that the 'Influences' and 'Influenced' tags in the article header are in fact inappropriate. I would be in favor of replacing them with a 'Similar' field, limited to say five items.Mhx (talk) 07:45, 25 July 2008 (UTC)[reply]


Forth20x0 standard

The iForth FAQ page, <http://home.iae.nl/users/mhx/i4faq.html>, hints at a "Forth20x0 standard". Perhaps this proposed or completed standard, if it exists, should be described?

2008-08-12T22:56:00Z, Mortense (talk) 22:50, 12 August 2008 (UTC)[reply]

<http://www.forth200x.org/forth200x.html> is where the new standard is being developed, I think it would be good to have that link somewhere Donio (talk) 03:12, 27 November 2008 (UTC)[reply]

That is a tongue-in-cheek remark, designed to put some pepper in the committee members' pants. Unfortunately, they're all wearing flame-proof underpants and hair shirts. Mhx (talk) 17:46, 13 August 2008 (UTC)[reply]

Stacks and subroutines

For what it's worth, rewriting the code to use continuation passing style isn't the only alternative to the conventional call stack when implementing subroutines. On many old computers subroutines were implemented by saving the return address in a register or into a location before the subroutine. These implementations didn't generally support recursive subroutines, but they did support subroutines and they didn't use a call stack.

Systems based on expression rewriting are also able to support subroutines without a call stack. At each stage of evaluation, subroutine calls in the expression being evaluated are replaced by the body of the subroutine. They aren't popular, and most of the ones that I have seen were primarily meant for educational purposes, but they do exist. Kleg (talk) 19:20, 27 January 2009 (UTC)[reply]

A stack (data structure) is any LIFO data structure. Subroutines execution necessitates "pushing" and "popping" activation records. Any flow control which qualifies as subroutines with activation records manages a data structure which may be interpreted as a stack. The stack may be a linked list or limited to one or two entries, but it's still a stack.
Continuation-passing style is not only a programming style, but also the continuation is a formalism encompassing all flow control including subroutines. Interpreted in this manner, subroutine flow control still necessitates a stack structure being around. Potatoswatter (talk) 19:32, 27 January 2009 (UTC)[reply]

I still disagree that "All" computer languages use a stack for subroutine flow control, given the additional counter-example of lazily-evaluated languages such as Haskell and Kleg's call-through-rewriting example (which is one way of implementing lazy evaluation).

Given that computer languages exist that at least conceptually invoke functions without the use of a stack, the objection to the word "Most" seems puzzling. Hdan (talk) 21:03, 27 January 2009 (UTC)[reply]

I have to agree that "many" or "most" is more accurate wording than "every". Note that even Subroutine#Call_stack is worded that way:
"Most modern implementations use a call stack, a special case of the stack data structure, to implement subroutine calls and returns."
I say this as a staunch Forth advocate. --IanOsgood (talk) 21:14, 27 January 2009 (UTC)[reply]
Note the exact wording (not that that article is necessarily perfectly worded): … use a call stack, a special case of the stack data structure … . A call stack is a different beast and cannot be a linked list.
Lazy evaluation is a totally different paradigm from subroutines. You guys are throwing around lots of arguments about supposed "special cases" but missing the definition of a subroutine. A subroutine is when you jump to a point in code, (maybe) activate local variables and do something, and jump back. Simply because some languages have other capabilities or optionally bypass or hack the stack structure, doesn't mean they don't have a stack. Re-read the definition of a subroutine and consider whether activation records can be linked in any way other than a stack, under conditions of subroutine execution. I don't think this argument has much to do with Forth. Potatoswatter (talk) 23:32, 27 January 2009 (UTC)[reply]
The paragraph in question also says "call stack." Kleg (talk) 23:35, 27 January 2009 (UTC)[reply]
Sorry, missed that — fixed. All good now? Potatoswatter (talk) 00:27, 28 January 2009 (UTC)[reply]
Many early machine architectures didn't have a hardware stack. When programming for such a machine, subroutines would be implemented by A writing to a variable "B's return address" [or, equivalently, directly modifying B's returning jump instruction] and then jumping to B. (This doesn't allow recursion, but these are still typically considered subroutines.) One might argue that this arrangement is still conceptually a stack insofar as it allows LIFO call flow (so long as no recursion is involved), but it is usually considered distinct from a stack precisely because a true stack would support recursion. (Incidentally, it also supports un-stack-like operations such as accessing X's return address regardless of where X is in the "call stack" or even if X has already returned.)
Not only is the statement that "subroutines require a stack" questionable, it is also unnecessary in this context, and I have thus removed it and reworded the remainder. —Preceding unsigned comment added by Pjrm (talk • contribs) 02:21, 22 October 2009 (UTC)[reply]
Potatoswatter, the general definition of a subroutine is a section of code which performs a function which the programmer considers to be useful. There are two types. One is a closed subroutine which is the type you describe. Processing jumps to the subroutine and returns where it came from afterwards, as you describe. The other is an open subroutine where the section of code is embedded in something else, i.e. the subroutine is written out in full where it's needed. Most programmers use closed subroutines for moderate to substantial functions, and use open subroutines for trivial functions. 20:58, 5 February 2011 (UTC) 188.220.70.97 (talk) 21:02, 5 February 2011 (UTC)[reply]
"Open subroutine" does not appear on that page. If a programmer copy-pastes lines of code which are commonly useful, that is not a subroutine. Likewise I think most programmers would disagree that code generated by a macro (computer science) is a subroutine. On the other hand, I think most would classify an inline function as such. I don't think it's meaningful to say what "most programmers" do. It is best to liberally use whatever abstractions your language provides, and avoid copy-paste, whatever your coworkers do. Anyway, do you have a point at all, and does it relate to Forth? Potatoswatter (talk) 04:24, 6 February 2011 (UTC)[reply]
  • A stack is any LIFO structure. LIFO control flow implies a LIFO structure in memory somewhere, even if it's in the form of a linked list between fixed addresses with one node per function.
  • Sometimes Forth has local variables. Potatoswatter (talk) 01:22, 23 October 2009 (UTC)[reply]

Better code examples

I suppose this may raise the ire of staunch Forth devotees, but several times in the past I have thought about dabbling in Forth -- just for curiosity's sake -- and been put off by the code examples. It seems that Forth code examples tend to jump directly from the completely trivial (e.g. EMIT-Q, HELLO) to stuff sufficiently abstruse as to put off anyone not already determined to learn Forth.

And this article's examples have shaped up the same way. In comparison most other languages publish plenty of intermediate pedagogical examples. Compare, for example, the following programming language examples here on Wikipedia:

  • Java includes repeatedly fetching a number from a user (through a GUI), and informing the user if the number is even or odd
  • Python gives many examples, including a function to generate lists of prime numbers
  • Our Perl articles are actually a bit weak in this regard too, but do include a factorial function
  • JavaScript implements the Euclidean algorithm to find lowest common multiples

So when people look at the Forth article and see EMIT-Q, I suspect they are thinking (as I often have) "not only is this language only suited to writing device drivers, but even for that it must be like squeezing blood from a stone."

Sounds good to me. If you feel strongly about this, how about proposing some standard examples that could be used across all programming language articles? Wikipedia:WikiProject Programming Languages has a style guide where the standard examples could be documented. --IanOsgood (talk) 15:46, 1 October 2009 (UTC)[reply]

As I am not a Forth programmer, I am not able to provide an alternative, but I would suggest that if none of the above examples are suitable, then it seems to me that the RC4 cipher might be particularly amenable to a simple Forth implementation. -- 203.20.101.203 (talk) 07:36, 24 September 2009 (UTC)[reply]

Like this? 

0 VALUE tmp
0 VALUE ii
0 VALUE jj
CREATE S[] #256 CHARS ALLOT

: ARCFOUR  ( c -- x )
	ii 1+ DUP TO ii #255 AND		( -- i )
	S[] +  DUP C@			( -- 'S[i] S[i] )
	DUP jj +  #255 AND DUP TO jj	( -- 'S[i] S[i] j )
	S[] +  DUP C@ TO tmp		( -- 'S[i] S[i] 'S[j] )
	OVER SWAP C!      		( -- 'S[i] S[i] )
	tmp ROT C!			( -- S[i] )
	tmp +				( -- S[i]+S[j] )
	#255 AND S[] + C@			( -- c x )
	XOR ;

: ARCFOUR-INIT	( key len -- )
	#256 UMIN LOCALS| len key |
	#256 0 DO  I  S[] I + C!  LOOP
	0 TO jj 
	#256 0 DO			( key len -- )
		  key I len MOD + C@  
		  S[] I  + C@  + jj + #255 AND TO jj
		  S[] I  + DUP C@  SWAP ( c1 addr1 )
		  S[] jj + DUP C@  ( c1 addr1 addr2 c2 ) ROT C! C!
	     LOOP
	0 TO ii  0 TO jj ;

Mhx (talk) 20:15, 25 September 2009 (UTC)[reply]

Thanks, excellent work! Do please put it in! -- 203.20.101.203 (talk) 04:11, 1 October 2009 (UTC)[reply]
If it were me, I'd replace the global value "tmp" with an anonymous local on the return stack:
: ARCFOUR  ( c -- x )
	...
	S[] +  DUP C@ >R		( -- 'S[i] S[i] 'S[j] )
	OVER SWAP C!      		( -- 'S[i] S[i] )
	R@ ROT C!			( -- S[i] )
	R> +				( -- S[i]+S[j] )
	...
Also, I don't think the prefixed decimal literals (#256) or UMIN are standard. Just 256 and MIN should work fine. --IanOsgood (talk) 15:37, 1 October 2009 (UTC)[reply]

Resident?

"Forth was the first resident software on the new Intel 8086 chip in 1978 and MacFORTH was the first resident development system for the first Apple Macintosh in 1984."

What is resident software and what is a resident development system? --Abdull (talk) 13:46, 28 January 2010 (UTC)[reply]

"Resident" means the Forth system ran entirely on the target platform itself. In most cases, bringing up experimental hardware requires some sort of cross-compiler or umbilical system where the bulk of the target development is done on a different computer. For example, most of the original Macintosh development was done on its predecessor, the Apple Lisa. --IanOsgood (talk) 16:51, 28 January 2010 (UTC)[reply]

F79 de facto standard

It is more precise to call figForth a de facto standard and F79 a failed standardisation attempt. Can you call F79 and f83 a "de facto" standard, if they are formal standardisation attempts? That doesn't seem right from a language point of view. 80.100.243.19 (talk)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Forth_(programming_language)&oldid=414057761"