Writing a journal article - Forth ideas

forth

    Next

  • 1. Escaped Strings (Version 6.1)
    Peter Knaggs wrote: > Ed raised an interesting point in his comments. In that the reference > implementation uses the PAD. The standard makes a point of stating that > the PAD is for the application programmer, and that no standard word > will use it. Thus I have re-worked the reference implementation to > replace the escaped string in situ. While this is frowned on by the > standard, writing into source, it is allowed. > ... I would be surprised if ANS allowed it. Consider the case with blocks. A screen contains an escaped string: : TEST S" \n\nHello\n\n" TYPE ; I load the block and it compiles correctly. But if I then list, edit, or reload the screen, it will be the converted string that's in the buffer. The situation for text-based forths is less clear than for blocks. There's no guarantee one can even write to the input buffer, let alone know what side-effects such an action might produce.
  • 2. nibz processor
    hi Nibz40f.qar archive released http:/nibz.googlecode.com fixed memory bug, changed to new instruction set, rationalized memory. expected 9MHz 544 LEs, with 40 pin bidirectional IO. Not sure how to upload latest Gforth updates of EC port, but included it in quartus archive. I don't do CVS. Includes first non working version of k ring support codec. cheers jacko
  • 3. Is FICL/kForth REFILL behavior non-standard?
    In FICL and kForth, when receiving input from the keyboard, REFILL appears to immediately return false. refill.f: : refill ." {(<" refill ." >)}" ; : go begin refill while source evaluate repeat ; FICL: localhost ~> ficl refill.f Ficl version 4.0.31 Nov 18 2008 loading refill.f ok> go {(<>)}ok> kForth: localhost ~> kforth kForth v 1.3.1 (Build: 2006-01-23) include refill.f REFILL is redefined ok go {(<>)} ok bye Goodbye. Under gforth or pfe, `go` loops until the end of input or BYE or whatever, which I believe is what the standard requires. From 6.2.2125 REFILL: When the input source is the user input device, attempt to receive input into the terminal input buffer. If successful, make the result the input buffer, set >IN to zero, and return true. Receipt of a line containing no characters is considered successful. And from A.6.2.2125 REFILL: This word is a useful generalization of QUERY. REFILL is designed to behave reasonably for all possible input sources. If the input source is coming from the user, as with QUERY, REFILL could still return a false value if, for instance, a communication channel closes so that the system knows that no more input will be available. Am I interpreting this correctly? I keep trying Forth systems which claim to be standard, but so far every system except gforth seems to have serious deficiencies. --Josh
  • 4. Gforth prim.fs v0.7 * as um*????
    hi : * ( n1 n2 -- n ) um* drop ; surely not, m* drop might preserve the sign. cheers jacko
  • 5. SwiftX debug problem
    Hi to all, i have buy the latest Swiftx version, but i have a problem in debug. i program my microcontroller with CodeWarrior and BDM, and i debug it with a serial port. After the code have to be write, i click the "build" command, and i store with the codewarrior some code on the microcontroller. i click the "debug" command, i wait, when the target is ready i try to execute some function stored in flash and all work fine (all the function are correct executed). If i try to made a simple operation like " 3 4 +", and the communication crash (after i can't made and write anything, i have to break the swiftx). This happen in a board with a clock oscillator of 2MHz, if i try to make the same procedure in the same board (with the same code), but with a 16 MHz oscillator, alla work fine. Someone say if there is some timeout? Perhaps it is a timeout communication that crash all.. I hope someone can help me, thank you

Writing a journal article - Forth ideas

Postby ir230 » Wed, 10 Dec 2003 02:32:56 GMT

ere are some reflections about Forth inspired by the
appearance of my article "Evolution of a Computer
Application" (see www.joma.org) which features the use of
Forth to write mathematics software.

I started using Forth in my research in algebra over 2 years
ago. When I entered this field I became quickly aware of the
impact of language and environment on the ability of a
mathematician to produce software. Forth has a variety of
desirable qualities which not only facilitate a working
mathematician's ability to produce research software, but
which adds desirable qualities (interactive environment,
extensibility, etc.) My article illustrates (using the well known
subject of group theory) an approach to computation that I use
in my research.

What makes programming hard in algebra and related fields is
that conventional programming languages were not designed
for these areas. Algebra is the name for a large number of
fields each having their own objects of interest and body of
concerns. There is a gap between the means of expression
provided by conventional languages and the concepts of the
field. This makes the production of software focus more on the
technicalities of the language than the ideas of mathematics.

The idea developed in the article is that the gap can be
decreased by providing the mathematician more control over
language. To people in the Forth community it may not seem
so radical to suggest the development of small problem-
oriented special purpose languages. The article tries to bring
this idea to mathematicians and illustrate it with an extended
example.

There are several features which recommend Forth for this type
of work. First of all it is a language suited for creating
languages. Second it provides an interactive programming
environment which is valuable both in program development
and an important feature in research software. An extremely
important attribute of Forth is that it is simple and easy to
learn. A working mathematician who is not expert in computer
programming can learn Forth and produce powerful specialized
software systems.

The simplicity of Forth was part of the lore in the early days of
the language. Simplicity was very much part of Charles
Moore's vision. I have used Forth in my classes on Computer
Algebra over the years because I can get the students up to
speed and writing programs in about 2 weeks - leaving the rest
of the time for using software to explore mathematics. I don't
have to turn these courses into courses on computer
programming - Forth lets them be courses in mathematics with
computer assistance.

The refereeing process for my article provided an interesting
test. The referees (judging from their feedback) were expert in
mathematics and in other programming languages (Java and
C++ were mentioned). None had any experience in Forth - and
their only exposure to the language was the section I included
in the article. I was amazed at how quickly they seemed to get
the hang of Forth. During the refereeing process I was getting
fairly detailed comments on the code included in the article.
One telling comment was from a referee who wanted to
understand why the Forth word "WORD" did not produce
(from the command line) what he had expected. I wound up
including an "end note" in the article explaining how WORD
used the end of the dictionary as a buffer - and the inter

Re: Writing a journal article - Forth ideas

Postby nlper » Fri, 12 Dec 2003 19:26:09 GMT

ohn,

Let me preface my comments by saying that I think your
article is a Really Good Thing for the Forth community, and
it is precisely the sort of thing that should happen more
often if Forth is to avoid fading into obscurity.

Well done!

And now, a few responses...

XXXX@XXXXX.COM (john wavrik) wrote in message news:<br2ck8$ XXXX@XXXXX.COM >...

You're keeping one of the variables constant over time. That
is, there's a presupposition in your phrasing that what you
need a language to do will continue indefinitely. Experience
indicates this is not the case.

Today's developers have an unprecedentedly wide variety of
language choices and the question is often not what the
language did for them yesterday, but can it do what they
want it to do today and tomorrow.

My initial posting here mentioned the relative health of
three older languages: APL, Smalltalk, and Forth. The
three communitites have demonstrated different strategies
for outreach to the larger developer community, although
each as a core competency that makes complete extinction
unlikely in the immediate future.



Yes, but we didn't keep the Greek phobia of zero and infinity,
did we? Some tools of thought survive the test of time and
others don't.

Let's put it in terms of calculus. In the very early days,
very few people could understand what Leibnitz and Newton
were going on about. Today, calculus is a rite of passage
for most college students and some high school students.
It is incredibly popular (if I can use that term).

However, Newton's language (Latin) and his implementation
(dot notation, fluxeons, fluents, etc.) have pretty much
vanished from mathematical discussion and research. I would
argue there is a parallel in programming languages: concepts
may endure, but implementations and operating environments
rise and fall quite often.



I first became aware of Forth with the August 1980 Byte
that featured the language. The features that caught my
attention with the interactivity, extensibility, and the
user's ability to completely change the internals of the
language's operation. It seemed a language one could do
*anything" with.

Shortly thereafter, Forth started a long-term decline
in popularity, for a variety of reasons. The interpreted
nature of the language on the slow computers of the day
was a big PR problem. Also, the public disasters of
Valdocs and Zoomracks (Forth projects) were frequently
cited as reasons you should use another language. Already
the I'll-do-it-my-way attitude of Forth programmers was
beginning to assert itself. C programmers, on the other
hand, were often weened on a culture of sharing tools
(Unix) and common libraries. For that and other reasons,
C became more popular as a general purpose programming
language.



Forth has declined most slowly in embedded systems, an area
where it is excellently suited to the limited resources of
the target systems. In environments that aren't resource
constrained, however, Forth has done less well.

You might make a case that extensibility has become more
widespread than it was when Forth first appeared. Lisp,
originally described in a 1960 paper as theory, was also
based on ideas such as a small set of primatives and
the ability to extend the language. The ideas are still
around, although the Lisp community has fragmented.

Interactivity is much more widespread

Similar Threads:

1.Forth article in current Atmel Applications journal

2.Math article / Forth ideas

3.writing a Forth article -- corrections

Last time I posted an article it came out double spaced.
This one I ran through "tr" to eliminate CR characters
(from the Windows created file) -- and only found out
after posting that it also screwed up some other things
(particularly numbers).  I think that the article should
be clear -- but readers should be aware that some numbers
have been messed up.
                                John Wavrik

4.Ada Article in "COTS Journal"

5.COTS Journal article on Ada 2005

6. Ada article in CrossTalk Journal

7. Article about HLA on Linux Journal's website

8. Fortran 2003 article in Dr. Dobb's Journal



Return to forth

 

Who is online

Users browsing this forum: No registered users and 96 guest