strongForth 1.1 with floating-point word set
Stephan Becher
http://home.vrweb.de/~stephan.becher/forth/.
StrongForth supports strong static type checking and extensively uses
operator overloading, which makes it a non-standard system. For example,
words whose stack effect cannot be determined at compile time, like ?DUP,
are not available. Since the interpreter and the compiler are aware of the
data types, many words can be overloaded. For example, overloaded versions
of + replace +, D+, M+ and F+. Every definition has an unambiguous stack
effect that is stored in the header. However, care has been taken to make
strongForth as close to ANS as possible.
The most important addition in version 1.1 is the floating-point word set.
The floating-point word set actually demonstrates a number of unique
features of strong static type checking. Most floating-point words do not
need the prefix "F" in their name. F+ becomes +, FCONSTANT becomes CONSTANT
and FSWAP becomes SWAP. Stack movement words like DUP, DROP, SWAP, OVER and
ROT are overloaded to work on any combination of data types.:
1234 TRUE 1000000. 3.1415926536E0 ROT . . SWAP . .
TRUE 3.1415926536 1234 1000000 OK
(Of course, . is heavily overloaded as well.) If you want to swap two data
items, you simple write SWAP without considering the size of the operands.
In ANS Forth, you have to write ROT or ROT ROT in order to swap a cell and a
double cell. This works fine, but is definitely not intuitive and can impact
readability. Swapping cells or double cells with floating-point numbers is
not possible in ANS Forth, but in strongForth it's no problem.
This raises the question whether strongForth uses the unique or the separate
floating-point stack model. And the answer is: Both. Floating-point numbers
are kept on the separate hardware floating-point stack, but the programming
model is the same as for a unique stack. This is possible, because the data
type of each stack item is known at compile time.
Data typing also allows a much more sophisticated usage of Forth as a
scripting language. For example, a word like
SET-VOLTAGE ( FLOAT -- )
works as expected when provided with a floating-point operand, but is
rejected when you accidentally provide it with an integer. Unless you define
an overloaded version that accepts an integer. Thus, serious mistakes are
less likely.
StrongForth is a 16-bit text-mode application that runs in the DOS-box of
every Windows PC. In order to allow ports to other environments, I finally
decided to make it available under the GNU General Public License.
Regards,
Stephan
Anton Ertl
>Version 1.1 of strongForth is now available at
>http://home.vrweb.de/~stephan.becher/forth/.
Nice to see that you are still working on it.
>This raises the question whether strongForth uses the unique or the separate
>floating-point stack model. And the answer is: Both. Floating-point numbers
>are kept on the separate hardware floating-point stack, but the programming
>model is the same as for a unique stack.
This raised the question: Why did you chose this programming model. A
separate-stack model is easier to program than even a unified-stack
model with 1-cell floats, because you don't have to worry about (and
count) the floating-point values when dealing with integers, and vice
versa.
However, thinking a little longer, I guess I have the answer to the
question: This programming model allowws using a single set of stack
manipulation words, instead of having another set for the
floating-point stack.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
Stephan Becher
news:2006Nov1...@mips.complang.tuwien.ac.at...
> "Stephan Becher" <stephan.remov...@t-online.de> writes:
>>Version 1.1 of strongForth is now available at
>>http://home.vrweb.de/~stephan.becher/forth/.
>
> Nice to see that you are still working on it.
Thanks. Progress has indeed been very slow in the past year, but I expect to
be able to reenforce my work on strongForth now.
>>This raises the question whether strongForth uses the unique or the
>>separate
>>floating-point stack model. And the answer is: Both. Floating-point
>>numbers
>>are kept on the separate hardware floating-point stack, but the
>>programming
>>model is the same as for a unique stack.
>
> This raised the question: Why did you chose this programming model. A
> separate-stack model is easier to program than even a unified-stack
> model with 1-cell floats, because you don't have to worry about (and
> count) the floating-point values when dealing with integers, and vice
> versa.
>
> However, thinking a little longer, I guess I have the answer to the
> question: This programming model allowws using a single set of stack
> manipulation words, instead of having another set for the
> floating-point stack.
Yes. IMO dealing with separate stacks for different data types is clumsy and
inconsistent. OTOH, floating-point applications in ANS Forth based on a
unique stack model are even more clumsy, mainly because of missing stack
manipulation words for mixed data types. It's obvious why those words are
missing. For example, we'd need 9 different versions of SWAP to deal with
all combinations of single-cell, double-cell and floating-point items. But
that's exactly the way strongForth does it. It has 9 overloaded versions of
SWAP (and 27 of ROT). However, their usage is transparent because they all
have the same name and the interpreter/compiler automatically selects the
correct one. Most of these overloaded versions are aliases and consist of
dictionary headers only.
The unique stack model is definitely more elegant and more natural to use.
Strong static data typing allows getting rid of the disadvantages this model
has in an ANS Forth system. Adapting cell size to the size of floating-point
numbers (like in LSE64) is another possible solution, but I don't think
64-bit cells are an option for small embedded controllers.
Regards,
Stephan
Anton Ertl
>Adapting cell size to the size of floating-point
>numbers (like in LSE64) is another possible solution, but I don't think
>64-bit cells are an option for small embedded controllers.
Small embedded controllers usually don't do FP in hardware (and there
fixed-point is often better), but there are probably some that have FP
hardware, but don't use 64-bit cells.
John Doty
> "Anton Ertl" <an...@mips.complang.tuwien.ac.at> schrieb im Newsbeitrag
> news:2006Nov1...@mips.complang.tuwien.ac.at...
>> However, thinking a little longer, I guess I have the answer to the
>> question: This programming model allowws using a single set of stack
>> manipulation words, instead of having another set for the
>> floating-point stack.
>
> Yes. IMO dealing with separate stacks for different data types is clumsy and
> inconsistent. OTOH, floating-point applications in ANS Forth based on a
> unique stack model are even more clumsy, mainly because of missing stack
> manipulation words for mixed data types. It's obvious why those words are
> missing. For example, we'd need 9 different versions of SWAP to deal with
> all combinations of single-cell, double-cell and floating-point items. But
> that's exactly the way strongForth does it. It has 9 overloaded versions of
> SWAP (and 27 of ROT).
This is a very good illustration of the problem with variable cell size:
the vocabulary explodes. In LSE64, I took the easy way out: just have
one cell size (except possibly at interfaces). But your approach may be
better in many cases.
> However, their usage is transparent because they all
> have the same name and the interpreter/compiler automatically selects the
> correct one. Most of these overloaded versions are aliases and consist of
> dictionary headers only.
>
> The unique stack model is definitely more elegant and more natural to use.
> Strong static data typing allows getting rid of the disadvantages this model
> has in an ANS Forth system. Adapting cell size to the size of floating-point
> numbers (like in LSE64) is another possible solution, but I don't think
> 64-bit cells are an option for small embedded controllers.
I have an ARM development board sitting on a bench, whispering softly to
me that it really needs an LSE32. But right now on that project I'm
spending all of my time writing ICD's and designing analog circuitry.
The question I have for you, though, is how much extra machinery do you
need in the compiler to make your approach work? Will it reasonably fit
in a small embedded controller, or do you plan on an umbilical version?
--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
Don Seglio
Congratulations, this version would tend to make forth easier to deal
with for people not familiar with Forth.
I find it refreshing when efforts such as StrongForth, LSE32, Timbre,
Factor...and others break the mold and show that other possibilities are
possible. Let those ideas battle it out and hopefully some of them will
be incorporated in future standards.
--
Cecil
KD5NWA
www.qrpradio.com www.hpsdr.com
"Sacred Cows make the best Hamburger!" Don Seglio Batuna
John Doty
> I find it refreshing when efforts such as StrongForth, LSE32, Timbre,
> Factor...
Don't leave out ColorForth!
> and others break the mold and show that other possibilities are
> possible.
Yes.
> Let those ideas battle it out
Or better, learn from each other.
> and hopefully some of them will
> be incorporated in future standards.
Please, no, not more stagnation. The trend in software is toward
implementation and publication: for the user this is much better than
standardization.
Don Seglio
> Don Seglio wrote:
>
>> I find it refreshing when efforts such as StrongForth, LSE32, Timbre,
>> Factor...
>
> Don't leave out ColorForth!
>
>> and others break the mold and show that other possibilities are possible.
>
> Yes.
>
>> Let those ideas battle it out
>
> Or better, learn from each other.
>
>> and hopefully some of them will be incorporated in future standards.
>
> Please, no, not more stagnation. The trend in software is toward
> implementation and publication: for the user this is much better than
> standardization.
>
I'm bound to get in trouble for what I say, but I have always been one
to speak my mind, so here it goes;
Well I'll agree that a formal standard is not totally necessary, but
even an informal one where more Forth implementors start using some of
the newer ideas would be good.
I don't comprehend why for use on a desktop where resources are no so
scarce is the Forth community generally limiting itself so much, and
also there is a lack of agreement on how to implement tools.
It does seem like the Forth community has forgotten the users and are
content to argue about DO and +LOOP, those arguments were going on 25
years ago and they still are, very little progress in terms of making
Forth more usable to non-diehard Forth programmers. And yes there are
some excellent Forth's available but the extensions they add on are
different from one version to the other, and different across different
OS's. All this makes it very hard for the users to just pick up a Forth
version write some software and if later they change to a different
version have it work, never mind changing the OS.
After being away from Forth for a number of years I want to get back
into it again. I see that I will not be happy with the same old Forth so
I will be concentrating my efforts to figure out which rogue Forth I
will settle on for programming desktop applications, plain ANSI will not
do, not without major extensions, and I want it to be usable across
multiple OS's so that will put some limits on my choices. I'm finding
alternatives as we speak so I keep looking, I'm not in a big hurry right
now, picking the right tool to start with will be worth the effort later.
Right now I'm looking at;
Promising starting point have a lot of features I like, minuses are lack
of large community and documentation.
Factor Lisp like flavor, a lot of Joy in it, excellent for making
tools.
L
Timbre Older Forth, but with ruled based programming features,
excellent for making tools.
Need a lot of additions to make me happy, but are good starting points,
solid, well documented
GForth Solid documentation, nice tools available
Reva Simple, CMForth like
Will be looking at in the future, unknown to me what the features are at
this point.
LSE32/64 Uniform type size, makes for fewer words needed, language
simple to use, unknown additional features.
StrongForth System handles type sizes, fewer words needed for use,
language is simpler to use, unknown additional features.
Chuck is a moving target, ever searching for ways to make Forth simpler
for his purposes, he seems content with making his own version of Forth,
I don't blame him, he is very smart, people are very resistant to any
kind of change and he is not afraid of making changes.
Don Seglio
The link to the reference manual gets a 404 error.
Stephan Becher
"Don Seglio" <don.s...@sbcglobal.net> schrieb im Newsbeitrag
news:A9y5h.5088$IR4....@newssvr25.news.prodigy.net...
[snip]
>> StrongForth is a 16-bit text-mode application that runs in the DOS-box of
>> every Windows PC. In order to allow ports to other environments, I
>> finally decided to make it available under the GNU General Public
>> License.
>>
>> Regards,
>> Stephan
>
> The link to the reference manual gets a 404 error.
I tried the link in "For further documentation, please see the strongForth
reference manual, ..." on the web site with two browsers, and it works fine.
Or is there any other location where I forgot updating a link? It would have
been a pity if the reference manual is not accessible, because comprehensive
documentation is one of strongForth's highlights.
Regards,
Stephan
Stephan Becher
"John Doty" <j...@whispertel.LoseTheH.net> schrieb im Newsbeitrag
news:JqmdnZMQs_Lbl8vY...@wispertel.com...
Of course, strong static data typing does not come for free. It's actually
difficult to find out how big exactly the extra effort is, because
strongForth has additional features with respect to ANS Forth that are a
consequence of making the language more consistent. In many cases,
overloaded versions for additional data types are provided, that have no
counterpart in ANS Forth. For example, strongForth has locals and values for
single-cell, double-cell and floating-point items, or (already mentioned)
SWAP for all combinations of data types.
Here's a small summary of the extra effort:
1. Two separate data type heaps (for interpreter and compiler) with about 80
bytes each need to be allocated in RAM.
2. The header of each word needs to include the word's stack diagram, which
takes 4n+4 bytes, where n is the total number of input and output
parameters.
3. FIND and EXIT need to be extended with non-trivial data type matching
algorithms.
4. Overloaded versions of words specified by ANS-Forth, that deal with
different data types and add consistency to the vocabulary (see above).
5. Words that explicitly deal with data types. Among these are the data
types (UNSIGNED, FLAG, DOUBLE etc.) themselves and words that handle stack
diagrams and the data type heaps.
6. Defining words and words that control the program flow get more
complicated, because they need to keep track of data types. For example,
CONSTANT additionally compiles the new constant's stack diagram into the
header, and THEN checks whether the data type heap is congruent in all
branches.
A stripped version of strongForth, which just loads the kernel library in
blocks 30 to 79, contains only the following word sets:
- Core
- Block
- Double-Number
- Exception
- Locals
- String
This version needs about 2.7 kBytes data space (including a 1 kByte block
buffer), 13.5 kBytes name space; 6.3 kBytes code space (pure machine code)
and 9 kBytes of constant data space (used for virtual code). Some additional
space can be saved by removing unused words from the kernel library. If your
application does not need the interpreter, you can remove the name space and
burn only the contents of the code space and and constant data space into
the controller's flash memory. Thus, a complete strongForth application can
fit into a controller with 2 to 4 kByte RAM and 16 kByte flash memory.
> --
> John Doty, Noqsi Aerospace, Ltd.
> --
> Specialization is for robots.
Regards,
Stephan
Don Seglio
< URL:http://home.vrweb.de/~stephan.becher/forth/doc/toc.htm >
The web site has this instead;
< URL:http://home.vrweb.de/~stephan.becher/forth/doc\toc.htm >
The last slash is in the wrong direction.
Stephan Becher
...
> This is the right link;
>
> < URL:http://home.vrweb.de/~stephan.becher/forth/doc/toc.htm >
>
> The web site has this instead;
>
> < URL:http://home.vrweb.de/~stephan.becher/forth/doc\toc.htm >
>
> The last slash is in the wrong direction.
Got it. Thanks for the hint.
Regards,
Stephan
yao Pygmy user
[by offering new strongForth version 1.1]
> 1234 TRUE 1000000. 3.1415926536E0 ROT . . SWAP . .
^^
It took me an hour to search in the docs how to write a
floating point, but than I looked at your posting again...
Anyway, it's a masterpiece of exploration and explanations and
your source and the documentation have shown me again
that Forth can lead to a marvellous clear and consistently
system and programming style. Really nice is that one/I can
now completely study your system, that it gives me more
knowledge and insights of programming in Forth and in
programming generally. I got very impressed how you'd worked
it out. Less is more one can see easily and that's by heavy
overloading, funny to see how to build software in eyesight
with an exploding complexity, very impressive stuff indeed.
BTW to work with your (nominally) 1000 screens library
file I use another free given masterpiece of Forth the block
editor BEDIT from Gary Chanson which I spent some days to
configure it for my needs. It's one of the best made works
of macro configurable Forth-software under DOS and allows to
open many files and operate on them. Astonishingly it didn't
show the complete number of blocks loaded with a file but it
wasn't a great job to add it.
--
With regards..
m_l...@yahoo.com
> Version 1.1 of strongForth is now available at
> http://home.vrweb.de/~stephan.becher/forth/.
>
> StrongForth supports strong static type checking and extensively uses
> operator overloading,
Nice to hear that it's not forgotten.
Is there a way to run it under Linux other than dosbox?
Stephan Becher
"yao Pygmy user" <nom...@nospam.invalid> schrieb im Newsbeitrag
news:47$kinhl$7in10e7y...@nospam.invalid...
> Stephan Becher (stephan.remov...@t-online.de) wrote:
>
> [by offering new strongForth version 1.1]
>
>> 1234 TRUE 1000000. 3.1415926536E0 ROT . . SWAP . .
> ^^
> It took me an hour to search in the docs how to write a
> floating point, but than I looked at your posting again...
I will improve the documentation to make it clear from the start how to
write numbers of different data types. The format for floating-point numbers
is specified in the ANS standard (see section 12.3.7), and strongForth
complies to this specification. However, strongForth has one peculiarity in
writing numbers: 1234 has data type UNSIGNED, while -1234 and +1234 have
data type SIGNED. A similar rule applies to double-cell numbers.
> Anyway, it's a masterpiece of exploration and explanations and
> your source and the documentation have shown me again
> that Forth can lead to a marvellous clear and consistently
> system and programming style. Really nice is that one/I can
> now completely study your system, that it gives me more
> knowledge and insights of programming in Forth and in
> programming generally. I got very impressed how you'd worked
> it out. Less is more one can see easily and that's by heavy
> overloading, funny to see how to build software in eyesight
> with an exploding complexity, very impressive stuff indeed.
>
> BTW to work with your (nominally) 1000 screens library
> file I use another free given masterpiece of Forth the block
> editor BEDIT from Gary Chanson which I spent some days to
> configure it for my needs. It's one of the best made works
> of macro configurable Forth-software under DOS and allows to
> open many files and operate on them. Astonishingly it didn't
> show the complete number of blocks loaded with a file but it
> wasn't a great job to add it.
> --
> With regards..
I googled for BEDIT and found only a hint that it's now called PSEDIT. It
seems not to be available for download. Anyway, using an external editor is
not really convenient, because strongForth locks the block file for editing.
But instead of providing a more powerful block editor, I will implement the
File-Access word in the next version of strongForth, which should make
blocks mostly obsolete.
Regards,
Stephan
Stephan Becher
<m_l...@yahoo.com> schrieb im Newsbeitrag
news:1163563600.5...@e3g2000cwe.googlegroups.com...
A 32-bit version for Linux is no my task list, but it hasn't the highest
priority. I was actually hoping that someone else would pick up this
challenge, now that the sources are available ... ;-)
Regards,
Stephan
yao Pygmy user
> I googled for BEDIT and found only a hint that it's now called
> PSEDIT. It seems not to be available for download.
you may try:
http://www3.primushost.com/~gchanson/bedit_07.zip
or maybe you'll find it here, where his Quest32 Forth lays:
http://arcaneincantations.mvps.org/
> Anyway, using an external editor is not really convenient,
> because strongForth locks the block file for editing.
> But instead of providing a more powerful block editor, I will
> implement the File-Access word in the next version of strongForth,
> which should make blocks mostly obsolete.
As I understand you you want to give everybody a chance to try
algorithmic stuff as easily as loading source and so file words
are needed, yes, In the meantime I'll prefer Bedit and don't
miss file words so much, make it simple and take it easy. :)
Just my 2 cents.
Gary Chanson
"yao Pygmy user" <nom...@nospam.invalid> wrote in message
news:38sq7zuoycjs...@nospam.invalid...
I'm glad to see someone using BEdit. Since it is being used, if you
have any suggestions for improvement, let me know. Is there any interest in
a Windows version of it?
--
- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools
yao Pygmy user
> "yao Pygmy user" <nom...@nospam.invalid> wrote in message
>> [...] In the meantime I'll prefer Bedit and don't
>> miss file words so much, make it simple and take it easy. :)
> I'm glad to see someone using BEdit. Since it is being used, if
> you have any suggestions for improvement, let me know. Is there any
> interest in a Windows version of it?
You made it very comfortable to handle and manipulate text in block
files. It's seldom that a typical programer application comes into my
daily personal use. I use it also to make my personal joblists where
screens naturally build a database. Another point for a powerful
extern block editor is that you have to learn just one. I have taken
the time to do some heavy customizations but it just works now.
By using editor macro stuff with another file editor since years
I'd liked to make some text manipulating features I use with Bedit
in a similar way.
So thanks no, I need no Windows version and like to see improved
just one thing that's to get a macro run directly after starting
Bedit. In other words I did not find a Bedit typical way to do this
because at first the editor reads it .cfg-file after start, then
organizes itself internally and and does not accept any order to
execute a macro from commandline or executing automaticly from the
.cfg-file because the stuff from .cfg file is just readed and nothing
executed.
Example:
I don't use the mouse. Bedit supports fully the mouse, that's
a nice feature and a must for somebody but to to supress it from
the very beginning I have to start a keystack program before Bedit
(seems to me that I cannot stop show-mouse from edit.block).
By this way I also start a sum-of-total-screens-number macro I've
hooked in in the ESC-key definition in the .cfg-File, so given to
the keystack-program is just the number of the ESC-key. (It's
hooked in some other key defs too, but that's not important here.)
--------------8<------------------
: SHOW#
HIDE-MOUSE
?CURSOR
CUR.WND @ >R INFO.WND @ ACTIVE
SET.COLOR BORDER-COLOR 57 0 CURSOR
." S " SET.COLOR INFO-COLOR #BLOCKS .
R> ACTIVE CURSOR
;
--------------8<------------------
Other Hints: Some macro-files laying in the library are not used by
key-definitions an not mentioned in the help-file. Very important
seems to me that export macro, exporting blocks to an extern file.
I thought that I have to build it myself at first but then found out
fortunately you'd done it. I think it's a rather complete set of
macros. Seems to be that you're near the maximum memory border since
the memory in the debug mode is very small, so I had to reduce box
graphic symbols in map.fth to get it run, but the editor works
without problems and gives me enough memory to execute every
macro I use.
I'd had another idea to change a thing internally. Maybe you know
that Albert v.d. Horst inserts an Asccii#10 at the 64. position as
line-termination character in his ciforth/mina/lina library screens.
I'd liked Bedit could handle this directly but changing the screen
format isn't worth the work I suppose and I have no problem
to use a little converting tool for this before loading and after
saving the library "forth.lab" file.
All in all I feel that Bedit is ready made and nothing more is needed
in that DOS environment. I thought about how I would use it's
possibilites in a Forth environment to develop/test Forth programs
with it but that's completely another thing. So I liked using the
string stack (to build an ID-macro to brand my files with date and my
name) and also liked interpreting do-loop constructions on the command
line in the debug mode of Bedit. It always makes me fun using it. It
did'nt take much effort to test my macros and by exploring you're
rather complete documentation to your Forth and the application
I learned Forth and was able to customize Bedit for my personal wishes.
Therefore thanks for that nice demo and sharing the application for
free.
Gary Chanson
"yao Pygmy user" <nom...@nospam.invalid> wrote in message
> Gary Chanson wrote:
>
> > "yao Pygmy user" <nom...@nospam.invalid> wrote in message
>
> >> [...] In the meantime I'll prefer Bedit and don't
> >> miss file words so much, make it simple and take it easy. :)
>
> > I'm glad to see someone using BEdit. Since it is being used, if
> > you have any suggestions for improvement, let me know. Is there any
> > interest in a Windows version of it?
>
> You made it very comfortable to handle and manipulate text in block
> files. It's seldom that a typical programer application comes into my
> daily personal use. I use it also to make my personal joblists where
> screens naturally build a database. Another point for a powerful
> extern block editor is that you have to learn just one. I have taken
> the time to do some heavy customizations but it just works now.
> By using editor macro stuff with another file editor since years
> I'd liked to make some text manipulating features I use with Bedit
> in a similar way.
Thank you!
I'd be interested in seeing what customizations you've made.
An autorun macro should be very easy to add.
> Other Hints: Some macro-files laying in the library are not used by
> key-definitions an not mentioned in the help-file. Very important
> seems to me that export macro, exporting blocks to an extern file.
> I thought that I have to build it myself at first but then found out
> fortunately you'd done it. I think it's a rather complete set of
> macros. Seems to be that you're near the maximum memory border since
> the memory in the debug mode is very small, so I had to reduce box
> graphic symbols in map.fth to get it run, but the editor works
> without problems and gives me enough memory to execute every
> macro I use.
Noted.
> I'd had another idea to change a thing internally. Maybe you know
> that Albert v.d. Horst inserts an Asccii#10 at the 64. position as
> line-termination character in his ciforth/mina/lina library screens.
> I'd liked Bedit could handle this directly but changing the screen
> format isn't worth the work I suppose and I have no problem
> to use a little converting tool for this before loading and after
> saving the library "forth.lab" file.
It would be easy enough to hide the character but that's only part of
the problem. It also wouldn't be hard to detect this type of block but it's
not so clear how to handle it. Maybe the best answer would be to set a flag
when the block is loaded and if the flag is set prevent changing that
character. Could you please send me a copy of the file so that I have
something to test with?
> All in all I feel that Bedit is ready made and nothing more is needed
> in that DOS environment. I thought about how I would use it's
> possibilites in a Forth environment to develop/test Forth programs
> with it but that's completely another thing. So I liked using the
> string stack (to build an ID-macro to brand my files with date and my
> name) and also liked interpreting do-loop constructions on the command
> line in the debug mode of Bedit. It always makes me fun using it. It
> did'nt take much effort to test my macros and by exploring you're
> rather complete documentation to your Forth and the application
> I learned Forth and was able to customize Bedit for my personal wishes.
> Therefore thanks for that nice demo and sharing the application for
> free.
Thank you, and thanks for the comments.
yao Pygmy user
> I'd be interested in seeing what customizations you've made.
I didn't try to make anything perfect maybe simpler. I'll send you
an email. I've changed some keys and put one or two macros that
one only can find in the menu on keys so that all those often
needed lay on keys now. Don't get shocked please, I don't need
the nice made menus and commented them out in the .cfg file.
(I know it's barbarian). I've changed some colors as everybody
would do and I reorganized the help-file suiting my needs a
little. I've built me an timestamp(id)-macro and modified the
center-macro and shiftleft/shiftright-macro (moving the line
one position left/right) that I haven't to mark the line at
first.
>> Other Hints: [...]
> Noted.
BTW some macro files I wasn't able to understand them right
how to use it or I just have to study more carefully.
Perhaps one or to comments in it can be useful IMHO.
boffset.fth
expand.fth
openlist.fth
pairs.fth
prepare.fth
strip.fth
stripq.fth
>> [...] the library "forth.lab" file.
> It would be easy enough to hide the character but that's only
> part of the problem. It also wouldn't be hard to detect this type
> of block but it's not so clear how to handle it. Maybe the best
> answer would be to set a flag when the block is loaded and if the
> flag is set prevent changing that character. Could you please send
> me a copy of the file so that I have something to test with?
I'll send you an example, but it's very easy to understand. The last
character in the row always is a LF with the normal 16 lines per
screen nothing else. So it's formatted to look at it in a viewer
program like List. The line delimiter is also used internally in
ciforth/lina/mina so that this little incompatibility also was
motivated by a system design decision, but I don't know much of it.
yao Pygmy user
> Gary Chanson wrote:
>> I'd be interested in seeing what customizations you've made.
> [...] I'll send you an email.
> I'll send you an example [lab.file ...]
Done.
Albert van der Horst
yao Pygmy user <nom...@nospam.invalid> wrote:
>Gary Chanson wrote:
>
<SNIP>
>
>
>>> [...] the library "forth.lab" file.
>
>> It would be easy enough to hide the character but that's only
>> part of the problem. It also wouldn't be hard to detect this type
>> of block but it's not so clear how to handle it. Maybe the best
>> answer would be to set a flag when the block is loaded and if the
>> flag is set prevent changing that character. Could you please send
>> me a copy of the file so that I have something to test with?
>
>I'll send you an example, but it's very easy to understand. The last
>character in the row always is a LF with the normal 16 lines per
>screen nothing else. So it's formatted to look at it in a viewer
>program like List. The line delimiter is also used internally in
>ciforth/lina/mina so that this little incompatibility also was
>motivated by a system design decision, but I don't know much of it.
>
>
where at first the blocks are divided into variable length lines. A
source field of a word in the future would point to a string that
contains the definition of the word. That could then be edited
by the computer intelligence itself and recompiled. So she
would grow/evolve/learn (whatever you name it).
Interestingly the screen oriented block editor of wina/mina
remains usable all the way to edit the source fields.
The line delimiter internally in ciforth's is the same over different
OS's. This allows to have multiple line strings in a portable way. On
Unix forth.lab is a regular text file, so it can be handled with
regular editors, with some care. On Windows gvim probably does
a good job, although I didn't try it.
This said, if you hate the LF's in forth.lab you can just
replace them by spaces, BUT you have to do something about
the word \ . Instead of replacing \ in blocks with ( en ),
the easier thing is to redefine \ to detect whether the
current source is a block, then behave differently.
Use SAVE-SYSTEM and you can forget you ever had LF's.
Note:
Personally I don't think of forth.lab as classical
forth code but as a convenient way to organize a library.
All my application codes (number theoretical, manx2,
ciasdis) are in files.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
yao Pygmy user
[detailed explanations deleted]
Thank you for giving these insights.
> This said, if you hate the LF's in forth.lab you can just
> replace them by spaces, BUT you have to do something about
> the word \ . Instead of replacing \ in blocks with ( en ),
> the easier thing is to redefine \ to detect whether the
> current source is a block, then behave differently.
> Use SAVE-SYSTEM and you can forget you ever had LF's.
I don't hate the LF in that forth.lab but but I'll not miss
them at the moment. Thanks, you'd precisely answered a question
I wanted to ask, but didn't ask because I thought it can be
misunderstood as an unkind criticism.
Since it can be changed much easier than changing the Bedit I
suggest not to change this block editor to manage the LFs
in the forth.lab-file.
> Note:
> Personally I don't think of forth.lab as classical
> forth code but as a convenient way to organize a library.
I know, your library file is part of a concept which allows
an easy use and administration of many customizations.
The block-system is essentially needed if running your Forth
as a stand-alone system I suppose.
> All my application codes (number theoretical, manx2,
> ciasdis) are in files.
Just curios and ignoring stand-alone versions here, do I
understand right that you have almost the same possibilities
to do all configurations with files like with blocks?
Or does it mean that you make explicitly a distinction between
application and the Forth system?
Albert van der Horst
yao Pygmy user <nom...@nospam.invalid> wrote:
>
>Just curios and ignoring stand-alone versions here, do I
>understand right that you have almost the same possibilities
>to do all configurations with files like with blocks?
>Or does it mean that you make explicitly a distinction between
>application and the Forth system?
>
Absolutely!
Once the library is right, applications (like the metallophone
playing program manx2) are portable accross Windows/Linux.
It is on my todo list to make a forth.lab for gforth, such
that all my applications run on gforth implementations too,
especially the assembler/disassembler.