Forth flexibility 
Author Message
 Forth flexibility

Quote:


> > One thing that I see on Forth's side that is hard to pin down is
> >that Forth allows more experimentation then other languages. Once
>  I think this is a common mistake that the above is a LANGUAGE issue.
> This is more an OS/user interface issue and Forth supports interactivity
> by being all of them.
> Andras

I agree!

I feel that the OS capabilities of forth are often damned with faint
praise, ie. "and forth can also run stand alone since it has its own OS"
or words to that effect, as if you would only use the forth OS if a *real*
OS wasn't available. Forth is a remarkable combination of flexibility,
integration, and simplicity. I find myself rather surprised that there
don't seem to be any Forth file-systems that could be used to replace, for
example, MSDOS (evil grin, followed by maniacal laughter and megalomanic
posturing). Seriously though, a replacement file-system written in forth would
add another level of integration to the user interface. While I don't think
this would ever be a market buster it *might* find some niche markets that
are currently going begging, and I believe there more of these than many
people suspect. Forth has survived so far because there were a wide
variety of people who found it useful, not an especially large number, but
a variety.

Just my opinion

Brett K. Heath          \ Reply here or email, or not.



Wed, 18 Mar 1998 03:00:00 GMT  
 Forth flexibility

Quote:
(Brett K. Heath) writes:


>>  I think this is a common mistake that the above is a LANGUAGE issue.
>> This is more an OS/user interface issue and Forth supports interactivity
>> by being all of them.

>> Andras

>I agree!

>I feel that the OS capabilities of forth are often damned with faint
>praise, ie. "and forth can also run stand alone since it has its own OS"
>or words to that effect, as if you would only use the forth OS if a *real*
>OS wasn't available. Forth is a remarkable combination of flexibility,

I for one *would* only use the Forth OS *as an OS* if a real one were not
available. Someday standard Forth might have all the coverage of a reasonable
OS, but I think I'll wait a long time for that!
Forth may be good, but its not that good!

Quote:
>integration, and simplicity. I find myself rather surprised that there
>don't seem to be any Forth file-systems that could be used to replace, for
>example, MSDOS (evil grin, followed by maniacal laughter and megalomanic
>posturing). Seriously though, a replacement file-system written in forth would
>add another level of integration to the user interface. While I don't think

So instead of using a{*filter*}poor but popular filesystem (that most PC's have
installed) you want to invent a new one only users of Forth could use.
Yet again Forth turns its back on the rest of the world, a world that won't
notice.
By all means Forths should support file systems, should include some sort of
OS, but in ways compatible with the native installed OS on the machine.

--
Paul Shirley: too lazy to change this sig.



Wed, 18 Mar 1998 03:00:00 GMT  
 Forth flexibility

says...
Quote:

>(Brett K. Heath) writes:


>>>  I think this is a common mistake that the above is a LANGUAGE
issue.
>>> This is more an OS/user interface issue and Forth supports
interactivity
>>> by being all of them.

>>> Andras

>>I agree!

>>I feel that the OS capabilities of forth are often damned with faint
>>praise, ie. "and forth can also run stand alone since it has its own
OS"
>>or words to that effect, as if you would only use the forth OS if a
*real*
>>OS wasn't available. Forth is a remarkable combination of flexibility,

>I for one *would* only use the Forth OS *as an OS* if a real one were
not
>available. Someday standard Forth might have all the coverage of a
reasonable
>OS, but I think I'll wait a long time for that!
>Forth may be good, but its not that good!

>>integration, and simplicity. I find myself rather surprised that there
>>don't seem to be any Forth file-systems that could be used to replace,
for
>>example, MSDOS (evil grin, followed by maniacal laughter and
megalomanic
>>posturing). Seriously though, a replacement file-system written in
forth would
>>add another level of integration to the user interface. While I don't
think

>So instead of using a{*filter*}poor but popular filesystem (that most PC's
have
>installed) you want to invent a new one only users of Forth could use.
>Yet again Forth turns its back on the rest of the world, a world that
won't
>notice.
>By all means Forths should support file systems, should include some
sort of
>OS, but in ways compatible with the native installed OS on the machine.

>--
>Paul Shirley: too lazy to change this sig.

A forth-type O/S would be fine if the whole system were to be used only
for forth development. As an O/S for general purpose end-users it sounds
like only a little more fun than trying to maintain someone else's APL
code.


Thu, 19 Mar 1998 03:00:00 GMT  
 Forth flexibility

        On idea that I had, and to some degree implemented by modifying
        Until (over Unix)was that if the text I typed ins was not found and
        was not a number then it must be a command for the underlying OS so
        run it.

        It occurred to me that this could be extended for embeded forth systems
        as follows.

        The forth has an absolute minimum of pre-defined words.  A command is issued
        e.g. "words", if this cant be found by the usual search thru' the
        dictioanaries it would then use a pre-defined search path thru' a
        hierarchichal search path (defined as a string somewhere thru' a file system)
        to a source file which is loaded.  

        Any undefined words in this would be found in the same way.

        Any comments, well thats my 0.02 ECU's worth

rgds Andrew

----------------------------------------------------------------------  
C is the language of choice when you don't have a choice. Forth is the
language of choice when you don't have a job.
----------------------------------------------------------------------  


Quote:


>> > One thing that I see on Forth's side that is hard to pin down is
>> >that Forth allows more experimentation then other languages. Once

[ Stuff Deleted ]
Quote:

>I feel that the OS capabilities of forth are often damned with faint
>praise, ie. "and forth can also run stand alone since it has its own OS"
>or words to that effect, as if you would only use the forth OS if a *real*
>OS wasn't available. Forth is a remarkable combination of flexibility,
>integration, and simplicity. I find myself rather surprised that there
>don't seem to be any Forth file-systems that could be used to replace, for
>example, MSDOS (evil grin, followed by maniacal laughter and megalomanic
>posturing). Seriously though, a replacement file-system written in forth would
>add another level of integration to the user interface. While I don't think
>this would ever be a market buster it *might* find some niche markets that
>are currently going begging, and I believe there more of these than many
>people suspect. Forth has survived so far because there were a wide
>variety of people who found it useful, not an especially large number, but
>a variety.

>Just my opinion

>Brett K. Heath              \ Reply here or email, or not.



Fri, 20 Mar 1998 03:00:00 GMT  
 Forth flexibility

Quote:


> > > One thing that I see on Forth's side that is hard to pin down is
> > >that Forth allows more experimentation then other languages. Once

> >  I think this is a common mistake that the above is a LANGUAGE issue.
> > This is more an OS/user interface issue and Forth supports interactivity
> > by being all of them.

        I disagree.  If I was stuck with a Forth that compiled only on the
basis of text I edited in a text editor, and I wrote, compiled, and fixed
my word definitions while looking at error messages, I would *still* be
able to start with a low lying definition and test it without writing a
main() stub to pretend to be the higher level function.  Just as in APL,
the simplicity of connecting pieces together, and the ability to use the
language as a construction kit for new building blocks, lend themselves
to experimentation.  The OS / user interface may build upon this, but the
foundation is in the language itself.

Bruce McFarling, Knoxville



Sat, 21 Mar 1998 03:00:00 GMT  
 Forth flexibility

:On idea that I had, and to some degree implemented by modifying
:Until (over Unix)was that if the text I typed ins was not found and
:was not a number then it must be a command for the underlying OS so
:run it.

There's a major problem with this.

First of all, Forth uses the "not found" condition as an error (the
language's ONLY error).  Thus, it's possible to write code that's in error
and not get an error message.

Second, some OS commands will coincide with Forth words.  Therefore, you
simply can't call those OS commands with that facility.  Furthermore,
there's no logical reason why you can't; the only way to find out is to try
it.

It's far more effective to have a command like system" ...".

-Billy



Sun, 22 Mar 1998 03:00:00 GMT  
 Forth flexibility

<Below has been reformatted to clean up line wraps>

Quote:


> says...

> >(Brett K. Heath) writes:

> > > > [Zsoter snipped]
> > >[Me snipped]

> >I for one *would* only use the Forth OS *as an OS* if a real one were
> >not available. Someday standard Forth might have all the coverage of a
> >reasonable OS, but I think I'll wait a long time for that!
> >Forth may be good, but its not that good!

Seems that I (not for the first time) made it less than clear what I had
in mind. Although a fully implemented standardized forth operating system
would be nice, you're undoubtedly right that it will be awhile in coming!

Quote:
> > >[Me snipped again]

> >So instead of using a{*filter*}poor but popular filesystem (that most PC's
> >have installed) you want to invent a new one only users of Forth could use.
> >Yet again Forth turns its back on the rest of the world, a world that
> >won't notice.

I should have said "alternative file-system" rather than "replacement...".
My thought was that there must be quite a few applications where a simple
OS, which provided more than bare blocks but didn't required the the
resources of Windows (or even DOS) and which could be implemented on a
small target machine, would be quite useful. Something with about the same
functionality as CP/M but modularized (vertically) and integrated into the
forth environment. Not to compete with MS, but to open markets that they
ignore as being too small.

Quote:
> >By all means Forths should support file systems, should include some
> >sort of OS, but in ways compatible with the native installed OS on the
> >machine.
> >--
> >Paul Shirley: too lazy to change this sig.

And I'm too lazy to make a sig. :)

Quote:
> A forth-type O/S would be fine if the whole system were to be used only
> for forth development. As an O/S for general purpose end-users it sounds
> like only a little more fun than trying to maintain someone else's APL
> code.

As I said above, I wasn't thinking of a full blown general purpose OS, I
was suggesting that there might be applications where a less ambitious
enhancement of the existing functions would be useful.

Brett K. Heath          \ Comments welcome, here or email.



Sun, 22 Mar 1998 03:00:00 GMT  
 Forth flexibility
: So instead of using a{*filter*}poor but popular filesystem (that most PC's have
: installed) you want to invent a new one only users of Forth could use.
: Yet again Forth turns its back on the rest of the world, a world that won't
: notice.
: By all means Forths should support file systems, should include some sort of
: OS, but in ways compatible with the native installed OS on the machine.

   There are a variety of Forth implementations that use the MS-DOS file
system, and other file systems as well. Anybody who wants that can get
it. Research is being done on creating new filesystems all the time.
Why shouldn't this research be done with Forth? The world woun't notice
most of the research on "different" filesystems written with C either,
but that doesn't mean it shouldn't be done, or that there is something
wrong with using C to do it.

   The native installed OS on any machine is written in binary
numbers. If Forth is used to generate these machine instructions
so much the better for Forth. If any research is to have practical
applications, then it must be published and demonstrated to be
useful. Forth woun't help anybody who can't think of good ideas
or can't write these ideas for publication. But for those who do
know a better way to design a disk operating system, Forth can
get it working and tested faster than other ways of manipulating
those bits and chips.

--



Tue, 24 Mar 1998 03:00:00 GMT  
 Forth flexibility

This discussion of a Forth operating system strikes a cord with me.

Shortly after becoming acquainted with Forth and blocks, I decided
that a file system was needed to keep track of things and wrote one
which I've used since about 1979.  The system has been migrated from
8080 based floppy disks, to native (track & sector) hard disks, to the
PC. The original system worked either with or without DOS underneith,
but the non-dos implementation was eventually discarded.

My file system works on top of the Forth Block system, which in turn
lives within a DOS file.  Its features are:

 A) File names are multi-words with spaces up to 65 characters long.

 B) Files are selected with the CR key or the mouse.  Files have types
    that determine what happens when they are selected.  They can be
    text/word processing files, can contain source code, or
    semi-compiled forth code, or they can execute as programs.

 C) One file type is a DIRECTORY, so nested directories can be used to
    organize things.  Files can be moved or copied around and between
    directories by a mark and move/copy operation.  This is fast,
    since only pointers are changed except when moving or copying
    between volumes (explained below).

 D) Words in semi-compiled form can be changed and re-compiled
    individually or in blocks (contiguous ranges of words).

 E) When programming, I can bounce in and out of a file -- "out" being
    to a blank screen for typing executable words.  To compile a word
    or range of words, I write them in the file, mark them, exit to
    the blank Forth screen and type LOAD. Or to compile words from
    several files, I mark them in the directory screen, exit to the
    blank Forth screen and type LOAD. CHANGE returns me to the
    directory/file system right where I left off.

The file system is structured as follows:

1 KB blocks are pre-written to a DOS file up to 2Mb in size.  This is
called a Volume.

Each block is split into 32 "notes." A note consists of 2 bytes for a
pointer link to the next note and 30 bytes for data.  Before use, all
Notes are linked into chains of empty space called Tracks. Each Track
has responsibility for 256 Notes. An array SPCARRAY points to the
beginning of each chain of spaces for each track.  The SPCARRAY has
room for 255 pointers to tracks.

When the system needs space, it issues a request to the system.  The
objective is to keep storage fairly contiguous within a file, but to
distribute files evenly across the volume (disk), so that when adding
to or editing a file, there should always be some free space nearby.
For this reason, new files are started on the track with the most free
space - on a fresh system 256x32=8,192 bytes away from any other file
data.  Once a file is created, the system searches the current track
first, then toward higher, then toward lower numbered tracks to find
the space it needs in the current neighborhood.  The underlying block
system buffers the disk accesses.  The Notes that compose the
requested storage are linked together and unlinked from the space
chains (Tracks).

Files and directories consist of arrays that point to the heads of
allocated chains of storage line by line.  These file arrays are
stored on disk in the same manner.  When a file is selected, its line
pointer array is copied into memory.  The lines pointed to are
accessed from disk only when needed for display or some other purpose.
Again, the block system works great for buffering.

Transfer of data between linked notes containing pointers is done in a
text buffer, one line at a time.

DIRECTORIES are files containing file names, pointers and links used
in directory nesting.  One type of directory entry points to the root
directory of another volume, so the system is not limited to the 2mby
volume size maximum.

In my system up to 20 volumes can be open at once.  Since everything
is based on pointers, it is easy to jump around between files in any
volume, either through a menu system that allows you to "bookmark"
places in the file space, or a hypertext link, or a rapid one-key
return to the last file location you had previously worked on.

This design has its strengths and weaknesses, but it has served me
well for many years and has been the basis for several commercial
products.  The more primitive levels of the code are not pretty, since
a) they represent some of my first Forth programming attempts, b) they
have since been transformed across several platforms, and c) once they
worked reliably, I left them alone.

What this all means, I don't know.  But thought it worth sharing in
the context of the current discussion.

Regards,
  Martel Firing

---------------------------------------------------------------------
Martel Firing                  

---------------------------------------------------------------------



Tue, 24 Mar 1998 03:00:00 GMT  
 Forth flexibility

Quote:
>I should have said "alternative file-system" rather than "replacement...".
>My thought was that there must be quite a few applications where a simple
>OS, which provided more than bare blocks but didn't required the the
>resources of Windows (or even DOS) and which could be implemented on a
>small target machine, would be quite useful.

We have had a great deal of experience of this over the years.  In the 70's
we used completely native Forths exclusively.  We developed a very flexible
file system -- actually a simple data base -- built on blocks, which we used
for multi-user data base applications (some quite large and complex).  In
the 80's we used both native and host-OS systems, and ported the data base
tools to run equivalently on both.  Nowadays we use host-OS systems almost
exclusively except in embedded systems, where the need for data bases is
typically much less.  However, some of our customers have continued with the
native systems, and have enhanced the data base tools quite a lot.

So, I quite agree with Brett -- it's not only a quite reasonable thing to
do, it's been done!



Tue, 24 Mar 1998 03:00:00 GMT  
 Forth flexibility

Quote:

>   There are a variety of Forth implementations that use the MS-DOS file
>system, and other file systems as well. Anybody who wants that can get
>it. Research is being done on creating new filesystems all the time.

errr Mike.... who mentioned research? (Oh silly me you did...:)

--
Paul Shirley: too lazy to change this sig.



Wed, 25 Mar 1998 03:00:00 GMT  
 Forth flexibility

Quote:
(Martel Firing) writes:
> B) Files are selected with the CR key or the mouse.  Files have types
>    that determine what happens when they are selected.  They can be
>    text/word processing files, can contain source code, or
>    semi-compiled forth code, or they can execute as programs.

How is the type information implemented?  Is the type ID a string to be
executed as if it were a FORTH line entered from the text?  In other
words:

FILENAME: MyFile.Doc
TYPE: ONLY FORTH ALSO WORDPROCESSOR WORDPRO

Thus, when a person selects MyFile.Doc, "ONLY FORTH ALSO WORDPROCESSOR
WORDPRO" is automatically executed?

Thanks for the information.



Wed, 25 Mar 1998 03:00:00 GMT  
 Forth flexibility

Quote:
: (Martel Firing) writes:

: > B) Files are selected with the CR key or the mouse.  Files have types
: >    that determine what happens when they are selected.  They can be
: >    text/word processing files, can contain source code, or
: >    semi-compiled forth code, or they can execute as programs.
: >
: >

: How is the type information implemented?  Is the type ID a string to be
: executed as if it were a FORTH line entered from the text?  In other
: words:

: FILENAME: MyFile.Doc
: TYPE: ONLY FORTH ALSO WORDPROCESSOR WORDPRO

: Thus, when a person selects MyFile.Doc, "ONLY FORTH ALSO WORDPROCESSOR
: WORDPRO" is automatically executed?

That's a clever idea, Sam.  But in my file system "type" is simply an
integer that is used to set pointers to a number of execution vectors
that govern what happens when a file is selected.  These vectors include
routines for inserting, deleting, keyboard behavior, screen display, etc.

The "files" live inside of a DOS volume file, a large, pre-allocated
block arrray on disk.  The files used by the system have names like: "My
response to Sam" and the "types" have names like: DIRECTORY, TEXT,
CHAPTER, PROGRAM, etc.  By entering a type name along with the file name,
the system knows what to do when the file is selected.

Your idea would be more flexible, but would require the system to present
data to foreign programs in a format they are comfortable with -- beyond
the modest capabilities I've implemented.  My system assumes that the
code it works with is aware of the file structure, which is line oriented
with easy and quick insertion and deletion of lines.  This is suitable
for a variety of applications.  I've used it for word processing, text
editing, database, forms, spreadsheet and Forth executables, among others.

Hope this answers your question,

Regards,
   Martel

---------------------------------------------------------------------
Martel Firing                  

---------------------------------------------------------------------



Thu, 26 Mar 1998 03:00:00 GMT  
 Forth flexibility


Quote:

>>   There are a variety of Forth implementations that use the MS-DOS file
>>system, and other file systems as well. Anybody who wants that can get
>>it. Research is being done on creating new filesystems all the time.

>errr Mike.... who mentioned research? (Oh silly me you did...:)

     What did you have in mind? If you write a version of Forth that
uses MS-DOS, Unix, Apple DOS's, etc. then you are doing development.
If you invent your own file formats that can't be read under any
other operating system, then you are doing research. Either way you
can use Forth. If you try to sell your product as an advance in the
state of the art of file systems, you can't be criticised as creating
a new incompatable version of Forth. You might be criticised for
creating a lot of extra work in learning to use your new system, but
you can't advance the state of the art without doing research and
learning something new.

--



Sun, 29 Mar 1998 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. OO and Flexibility

2. OO and Flexibility

3. Namespaces, Flexibility & Dylan

4. IBM Compiler and Library for REXX on zSeries Release 4 increase efficiency and flexibility

5. try/except/else flexibility...

6. Getting Forth related files (was: Forth primer/teaching Forth)

7. Forth in Forth vs. Forth in assembly language

8. Forth in Forth vs Forth in assembly

9. Forth in Forth vs. Forth in assembly language

10. ans forth link broken at forth.org

11. Forth Dimensions, SIG Forth newsletter

12. C->FORTH FORTH->C Translators

 

 
Powered by phpBB® Forum Software