what kind of non microconroller app are done in forth?
gavino
in forth?
Stuff like databases?
data mining?
things like that
is anyone at al trying to create a i686 operating system done in
forth? like linux?
pablo reda
gavino
> I'm making games and graphics & interactive things
Disk Space
Make sure you have at least 50 MB of temporary free disk space
available. After installation Apache occupies approximately 10 MB of
disk space.
here I see apache needs 10M space....... isn't that an OCEAN of space
for forth?
Stephen Pelc
wrote:
>Can the room give some examples of non microcontroller based apps done
>in forth?
>
>Stuff like databases?
>data mining?
>things like that
Laundry control system
http://www.microssautomation.com/index.php?menu=tn_&page=tn_01Tracknet
(the site does not work today with Firefox)
Construction planning - Candy
http://www.ccssa.com
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
pablo reda
if you askme for the site is http://www.reda4.org
Is a blog and you can download all the system, in spanish for now
gavino
> On 16 abr, 20:13, gavino <gavcom...@gmail.com> wrote:
>
> > On Apr 16, 3:57 pm, pablo reda <pablor...@gmail.com> wrote:
>
> > > I'm making games and graphics & interactive things
>
> > Disk Space
> > Make sure you have at least 50 MB of temporary free disk space
> > available. After installation Apache occupies approximately 10 MB of
> > disk space.
>
> > here I see apache needs 10M space....... isn't that an OCEAN of space
> > for forth?
>
> Is a blog and you can download all the system, in spanish for now
english available?
gavino
> On Wed, 16 Apr 2008 15:31:12 -0700 (PDT), gavino <gavcom...@gmail.com>
> wrote:
>
> >Can the room give some examples of non microcontroller based apps done
> >in forth?
>
> >Stuff like databases?
> >data mining?
> >things like that
>
> Laundry control system
> http://www.microssautomation.com/index.php?menu=tn_&page=tn_01Tracknet
> (the site does not work today with Firefox)
>
> Construction planning - Candy
> http://www.ccssa.com
>
> Stephen
>
> --
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads
Both look successful. Nice. What things are forth inc doing lately I
wonder?
Helmar
> Can the room give some examples of non microcontroller based apps done
> in forth?
>
> Stuff like databases?
I do.
> data mining?
Depends on what your understanding of "data mining" is. I do apply
some questions to the databases. That is mainly linguistic research
and shows some structure in the given data. Up to now I dont use
neural networks or similar things for the investigations - so you
might argue that it is no "data mining".
> things like that
I also work on typesetting (or better text processing) procedures in
Forth. I already did some stuff successfully - for example special
purpose PDF generation for inclusion with TeX. Or what I also did was
some workflow related stuff for bringing TeX-related things to
publishers. For example if the author does not want to give you .DOC
files: if you are the publisher, you'd have to handle them if they are
TeX, AmiPro, WordStar, ClarisWorks etc. That sound trivial but is not
that trivial if a lot of different special fonts and text encodings
come into play. And it gets more worse the more authors you have. I
made some solutions for such things in Forth (and some in Perl).
> is anyone at al trying to create a i686 operating system done in
> forth? like linux?
Why something like Linux?
-Helmar
Elizabeth D Rather
...
>
> Both look successful. Nice. What things are forth inc doing lately I
> wonder?
FORTH, Inc. does tend to specialize in embedded systems. Don't
disparage them, though -- they're far more numerous than PC's! Recent
major projects include:
* A series of power distribution controllers for GE Multilin,
http://www.geindustrial.com/multilin/products/lentronics/, including
(most recently) the JungleMUX Sonet product line. The relationship with
GE goes back quite a few years. We provide system-level and
communications/networking code, while the "domain experts" at GE write
the higher-level applications using SwiftX.
* Antenna controllers for Vertex/RSI
http://www.forth.com/resources/appNotes/app-Vertex.html. These are used
for a number of military antennas, as well as all the uplink antennas
for DirectTV (the main satellite TV system in the US).
* A very interesting experimental system designed to facilitate coaching
world-class competitive swimmers. The swimmers (during practice) wear
little devices with LEDs that are monitored by cameras, and analysis
determines things about their speed and techniques that enable their
coaches to improve their performance. No web site yet!
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
pablo reda
only the tiny manual
A friend of france traslate this manual and start programing, perhaps
this start a blog too
gavino
or something really advanced and way beyond linux....
gavino
> gavino wrote:
>
> ...
>
>
>
> > Both look successful. Nice. What things are forth inc doing lately I
> > wonder?
>
> FORTH, Inc. does tend to specialize in embedded systems. Don't
> disparage them, though -- they're far more numerous than PC's! Recent
> major projects include:
>
> (most recently) the JungleMUX Sonet product line. The relationship with
> GE goes back quite a few years. We provide system-level and
> communications/networking code, while the "domain experts" at GE write
> the higher-level applications using SwiftX.
>
> for a number of military antennas, as well as all the uplink antennas
> for DirectTV (the main satellite TV system in the US).
>
> * A very interesting experimental system designed to facilitate coaching
> world-class competitive swimmers. The swimmers (during practice) wear
> little devices with LEDs that are monitored by cameras, and analysis
> determines things about their speed and techniques that enable their
> coaches to improve their performance. No web site yet!
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310-491-3356
> 5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
computer, what could it do on a pc with 2G ram adn 3.0ghz intrel p4??
Elizabeth D Rather
...
> I always think to myself, wow if forth can do THAT on a small
> computer, what could it do on a pc with 2G ram adn 3.0ghz intrel p4??
Well, the thing about PCs is that they're doing a bunch of things
concurrently, while managing a very pretty and easy-to-use (though quite
resource-intensive) user interface. That's an awesomely different
challenge from any dedicated system, though they often have their own
challenges (such as high data rates and extreme reliability requirements).
The first half of my computing career was spent in database-intensive
IT-type applications, and the second half in embedded systems. In both
cases, my colleagues thought their challenges were significant, and the
"other" kind of computing trivial. They're both wrong (and both right).
The challenges are all significant, but quite different.
jennifer....@gmail.com
<snip>
> is anyone at al trying to create a i686 operating system done in
> forth? like linux?
Like linux? You mean strip down a linux system to boot up a kernel and
just a forth with bare minimal niceties? I think the Gforth guys have
something like that - check their site. Or do you mean
While there take a look at:
I expect there's a lot of juicy code to be gleaned from these 2
projects.
I've been meaning to take a look at these but been way too busy at
work and in my free time trying to port Albert's ciforth to OS X. A
great way to learn forth and more about its innards, I discovered by
the way, if you've not looked at Albert's forth I recommend you do -
it's small, simple and quite elegant.
It may be best to boot off another 'host' OS linux/windows/xx if
you've a 386 or better and run your forth there.
It may be that writing an entire modern OS may be a surmountable
obstacle that you could 'solo'.
But you go do that and you're stuck with.... the problem of....
It looks like WAY WAY too much work to write device drivers etc... I
mean, look every PC's gonna be different, you're gonna have one with
this network card, that GFX card etc, mmmm... PCI bus...mmm... USB...
Sounds like a royal pain. How you gonna cover all the devices people
are reasonably expected to have? Even writing drivers for just the
stuff you own yourself's gonna be a right pain.
Then you got to convince everyone your OS is the next great thing and
to come and write drivers, utils and apps for it etc..
= Dead OS.
Time invested in writing a modern OS is no small thing.
I reckon it's way tuffer today to code an OS for an IA-32 or AMD64
than chugging out code for a Z80 or 6502 or a 6800. Unless of course,
you restrict it to just doing simple things, which sometimes may be a
good idea, but then why not just use something smaller and less
sophisticated?
So you see the problem?
Is the _time_spent_ worth the _effort_?
Linus was in the right place and the right time with pretty damned
good code...
I don't know I may be talking bollocks, but I'm sure those who are
more 'long in the tooth' will chime in.
Here, you got some free time? Got a mac? Why not you help me debug
that thing that's been a thorn in my side for the past couple of
days.. (linux execve <--> OSX/BSD execve - in the word SYSTEM) don't
flipping know what I'm doing wrong and haven't had a decent 2-3 hours
to sit down to it till .. God, Thursday.. work = ftl :(.
Robert Spykerman
Duke Normandin
<jennifer....@gmail.com> wrote:
[snip]
> Here, you got some free time? Got a mac? Why not you help me debug
> that thing that's been a thorn in my side for the past couple of
> days.. (linux execve <--> OSX/BSD execve - in the word SYSTEM) don't
> flipping know what I'm doing wrong and haven't had a decent 2-3 hours
> to sit down to it till .. God, Thursday.. work = ftl :(.
>
> Robert Spykerman
Have you looked at `man 2 execve' on your OS X box? Compare _it_ to its
counterpart on your Linux system. Who knows, `man' is often your friend.
As well, it may be worth your while to join the freebsd-developers
mailing list. After all, those boys are responsible for lineage that
Darwin OS X originates from. HTH....
-- Duke Normandin
Jonah Thomas
> It may be that writing an entire modern OS may be a surmountable
> obstacle that you could 'solo'.
>
> But you go do that and you're stuck with.... the problem of....
>
> It looks like WAY WAY too much work to write device drivers etc... I
> mean, look every PC's gonna be different, you're gonna have one with
> this network card, that GFX card etc, mmmm... PCI bus...mmm... USB...
> Sounds like a royal pain. How you gonna cover all the devices people
> are reasonably expected to have? Even writing drivers for just the
> stuff you own yourself's gonna be a right pain.
>
> Then you got to convince everyone your OS is the next great thing and
> to come and write drivers, utils and apps for it etc..
>
> = Dead OS.
Yes. The point of an OS is to provide a steady interface between
variable/changing apps and variable/changing hardware. In the ideal case
hardware manufacturers would pay for the information they need to write
their own drivers, and application developers pay for the information
they need to write apps for your OS, and Bob's your uncle. But it
doesn't usually work like that unless Bob's your uncle.
You might get a foothold if you have an application that could use a
dedicated platform similar to a PC. If the PC is cheaper than dedicated
hardware, then use it even though it does more than you want. You write
your limited OS that works on a particular common PC architecture, maybe
specific components, and you can sell it because people want the
application and of course it works much better with your OS thasn it
would if it was rewritten to run under Windows or Linux. You might need
drivers for new components as the one it works on become unavailable and
your customers need replacement parts, and as you upgrade. Expand to
other drivers as you find the time. If possible, publish the specs of
what your OS demands of drivers in case somebody else wants to do some
of that.
Then you might get a second dedicated application, and maybe a third.
Let other people make dedicated apps for your OS. If there's some
special function your OS does particularly well they might do that. And
move on from there.
The Java guys tried to widen that bottleneck. Java serves as an OS for
java apps. Get a good java compiler/interpreter/JIT-compiler etc for a
particular set of hardware and in theory all the java apps will run on
it. Once your OS has java then it has everything. Java doesn't run all
that fast (no faster than a good Forth) and it's very slow to write and
debug apps in it. But more and more code is being written in it anyway.
The TIOBE measure puts java at 20% usage. (Disclaimer -- I don't know
what the survey measures or whether it actually measures anything
interesting. It's merely a convenient source of factoids, and I lack a
good source that says what I want to know.) That might translate into
roughly 20% of new desktop apps in Java? It would be a big deal to have
a new OS and 20% of the apps people might want, run on it out of the
box.
It ought to be easier to port one particular Forth compiler than a java
compiler, but then you don't get so many apps. And Forth doesn't have
anything like a standard GUI user interface. What might work is to write
a java compiler in Forth. Then you port the Forth and the Java compiler
ports too. Even if it isn't the best Java compiler it could be the first
that ports to a new system. And it could get improvements as fast as
somebody wants to bother.
Again going by the utterly unreliable TIOBE numbers, if you write other
langauges in Forth and port the Forth, you could theoretically port a
lot of apps easily.
Java 20%
+ C 35%
+ C++ 45%
+ PHP 55%
+ Perl 61%
+ Python 66%
Of course, in reality some of these languages have multiple incompatible
implementations so of course you can't compile all the code. And some of
them use lots and lots of conditional compilation so that you can only
run their code if you pretend to be some system they chose to write for.
But this is certainly suggestive. We say that Forth is particularly good
for low-level hardware type things. And Forth is particularly good for
writing application-specific languages. If the specific application is
"tools to easily write traditional languages"....
I'd start with a tool that parses traditional EBNF. Anton Ertl's Grey
and Brad Rodriguez's BNF parser both parse BNF, but as I understand it
they both use their own idiosyncratic commands and they both parse by
whitespace. Traditional BNF code doesn't care about whitespace and
usually will have to be massaged to fit a Forth parser. If we can accept
EBNF as it's usually written that might be a start toward writing
compilers for languages that have EBNF descriptions.
Doing the whole thing looks like a big job. But as one end-point, you'd
have a bunch of Forth applications, and on any particular new OS that
somebody else made, you could port the Forth and a lot of applications
in other languages would come with it. And it would be very easy to port
those applications to an OS written in Forth.
You'd still be left with the problem of drivers for a bewildering
variety of hardware components. But at least solving that problem
wouldn't be building a road to nowhere.
Bruce McFarling
> > = Dead OS.
> Yes. The point of an OS is to provide a steady interface between
> variable/changing apps and variable/changing hardware. In the ideal case
> hardware manufacturers would pay for the information they need to write
> their own drivers, and application developers pay for the information
> they need to write apps for your OS, and Bob's your uncle. But it
> doesn't usually work like that unless Bob's your uncle.
Well, unless Bill's your uncle.
> You might get a foothold if you have an application that could use a
> dedicated platform similar to a PC. If the PC is cheaper than dedicated
> hardware, then use it even though it does more than you want. ...
But then, where is the network economy, because if the PC is cheaper
than dedicated hardware, it can more often be done by stringing
together existing libraries plus a little glue code. And it may end up
being overkill in terms of the computing resources devoted to the
task, but *so what*? If the PC is cheaper than the dedicated hardware
that can *just* do the task, then the extra resources to do it by
stringing together libraries written for the PC resources are *free*.
The foothold for this strategy is if you have an application that
could use a dedicated platform that is *massively underpowered*
compared to a PC, and *massively cheaper* than a PC. An order of
magnitude cheaper. Since the cost of a PC is in $100's, then an order
of magnitude means in the $10's. And then the "PC" port is simply
emulating that cheap piece of hardware on the PC, typically with
upwardly compatible expansions of resources (RAM, display space,
etc.), and running the same apps in both the PC and the cheap piece of
hardware.
On this:
> Again going by the utterly unreliable TIOBE numbers, if you write other
> langauges in Forth and port the Forth, you could theoretically port a
> lot of apps easily.
> Java 20%
> + C 35%
> + C++ 45%
> + PHP 55%
> + Perl 61%
> + Python 66%
Again, there's no network economy available to any of those languages
in working with Forth. They get the theoretical opportunity to more
quickly port their language base to marginal or not-yet-developed
hardware, assuming the support of an active developer base around the
"Java-in-Forth" implementation that does not in fact exist, while in
practice, due to the size of their language community, they already
get ported reasonably quickly to most of the fringe or not-yet-
developed hardware that is of interest to them for most of their code
base.
Better to target a language with a smaller language community, where
there is more likely to be an actual opportunity to have an actual
network economy from having a "Language-in-Forth" implementation. I
have long used Lua as an example ... another example would be Cobra:
Bruce McFarling
> variety of hardware components. But at least solving that problem
> wouldn't be building a road to nowhere.
For hardware that is going to have the resources that *someone* is
going to develop a Linux for it, that's where the foreign function
interface comes in. Write a wrapper for the Linux driver.
For hardware that is *not* going to have those resources, there is the
mix of the foreign function interface for drivers that are already
developed, and if the driver has to be brought up for *any* system,
Forth is a good language for bringing up a new driver.
Guy Macon
Bruce McFarling wrote:
>The foothold for this strategy is if you have an application that
>could use a dedicated platform that is *massively underpowered*
>compared to a PC, and *massively cheaper* than a PC. An order of
>magnitude cheaper. Since the cost of a PC is in $100's, then an order
>of magnitude means in the $10's.
Just as a data point, many of the systems I created at Mattel had
a total cost for the microcontroller and all associated support
electronics (crystal, bypass cap, etc.) of less than ten cents.
--
Guy Macon
<http://www.guymacon.com/>
Jonah Thomas
> Jonah Thomas <jethom...@gmail.com> wrote:
> > You might get a foothold if you have an application that could use a
> > dedicated platform similar to a PC. If the PC is cheaper than
> > dedicated hardware, then use it even though it does more than you
> > want. ...
>
> But then, where is the network economy, because if the PC is cheaper
> than dedicated hardware, it can more often be done by stringing
> together existing libraries plus a little glue code. And it may end up
> being overkill in terms of the computing resources devoted to the
> task, but *so what*? If the PC is cheaper than the dedicated hardware
> that can *just* do the task, then the extra resources to do it by
> stringing together libraries written for the PC resources are *free*.
Except you have to adapt them to do what you want. And you get whatever
overhead that comes with these foreign libraries and OS etc.
So for it to work as I suggest, you need something that can be done
adequately with PC hardware, but that works *sufficiently better* with
your own OS and application that there's an advantage to using them.
This makes the reasonable assumption that it will cost you more effort
to do it yourself than to hook into foreign libraries etc on top of an
existing OS. But after you do that once, then it's a sunk cost and you
get it cheap for the second application.
> The foothold for this strategy is if you have an application that
> could use a dedicated platform that is *massively underpowered*
> compared to a PC, and *massively cheaper* than a PC. An order of
> magnitude cheaper. Since the cost of a PC is in $100's, then an order
> of magnitude means in the $10's. And then the "PC" port is simply
> emulating that cheap piece of hardware on the PC, typically with
> upwardly compatible expansions of resources (RAM, display space,
> etc.), and running the same apps in both the PC and the cheap piece of
> hardware.
That's where Forth already has a foothold. But I haven't heard that
there's any big economy of scale there, unless you already know you have
a product that will sell in large numbers. If you develop an "OS" for a
particular board with a particular processor etc, aren't there thousands
of other boards that do somewhat similar things or very different things
in the same price range? You can use that one until they stop making it
but there isn't anything to get momentum with other people. For that
sort of thing you'd probably do better with something like SwiftX. Write
SwiftX code that ports to whichever boards and processors. Ask Forth,
Inc to write a compiler for the next system you want to use.
> On this:
> > Again going by the utterly unreliable TIOBE numbers, if you write
> > other langauges in Forth and port the Forth, you could theoretically
> > port a lot of apps easily.
>
> > Java 20%
> > + C 35%
> > + C++ 45%
> > + PHP 55%
> > + Perl 61%
> > + Python 66%
>
> Again, there's no network economy available to any of those languages
> in working with Forth. They get the theoretical opportunity to more
> quickly port their language base to marginal or not-yet-developed
> hardware, assuming the support of an active developer base around the
> "Java-in-Forth" implementation that does not in fact exist, while in
> practice, due to the size of their language community, they already
> get ported reasonably quickly to most of the fringe or not-yet-
> developed hardware that is of interest to them for most of their code
> base.
Oh. Too bad. But if you have a Forth OS and you implement the popular
languages for it, then you get to import apps. Chances are the other
language communities won't bother. And if you can port your Forth and
piggyback languages to other marginal OSes then they get that advantage
too. It could make the difference between a marginal OS having a chance
versus having no chance.
But it doesn't look like something you could write a great business plan
for.
> Better to target a language with a smaller language community, where
> there is more likely to be an actual opportunity to have an actual
> network economy from having a "Language-in-Forth" implementation. I
> have long used Lua as an example ... another example would be Cobra:
> http://cobra-language.com/
Same problems, though. If the language doesn't have much of a code base,
what good does it do to port it? And how much good does it do them to
port their language to marginal systems? Actually I guess you could get
a little momentum that way. But don't the big wins usually come from
hooking up with winners?
Bruce McFarling
... which is the point where the question of the cost of the
electronics, at least in quantity, is replaced by the question of the
cost of the balance of the system.
There's a reason why the 8-bit rip-off "all-in-one" systems tend to
come in a joystick with A/V output ... digital switch joypad and
auxiliary buttons and an NTSC or PAL video output built around a
resister ladder gets the system cost down into the right price point.
Bruce McFarling
> That's where Forth already has a foothold. But I haven't heard that
> there's any big economy of scale there,
There's no need for any *additional* economy of scale, if you can get
network economies from the system. Get something that an SD card can
plug into, and load new applications, and there's an opportunity for
new applications to spread across the web.
> If you develop an "OS" for a particular board with a particular
> processor etc, aren't there thousands of other boards that do
> somewhat similar things or very different things in the same
> price range?
I don't understand the question. It sounds like you are asking
whether Contiki will fail to spread to new applications on new
configurations of hardware because there are thousands of
possible configurations similar to the hardware it was first
implemented on.
> Oh. Too bad. But if you have a Forth OS and you implement the popular
> languages for it, then you get to import apps.
Yes, but if there's no mutual benefit, there's more likelihood
that it'll stall/
> > Better to target a language with a smaller language community, where
> > there is more likely to be an actual opportunity to have an actual
> > network economy from having a "Language-in-Forth" implementation. I
> > have long used Lua as an example ... another example would be Cobra:
> >http://cobra-language.com/
> Same problems, though. If the language doesn't have much of a code base,
> what good does it do to port it?
If you have a new OS, what good does it do to port a language
with the primary appeal of being able to compile applications
that will not run because they were written for a different OS?
> And how much good does it do them to port their language to
> marginal systems?
This is posing a question as if it is a logical question
when the question is an empirical question. The answer is
not going to be found by armchair speculation, but by
exploration.
> Actually I guess you could get a little momentum that way.
> But don't the big wins usually come from hooking up with
> winners?
No, of course not. The big wins come from hooking up with
the marginal player that then *becomes* a winner. If its
already clearly becoming a winner, that's when everyone is
trying to jump on the bandwagon.
Robert Spykerman
> > Here, you got some free time? Got a mac? Why not you help me debug
> > that thing that's been a thorn in my side for the past couple of
> > days.. (linux execve <--> OSX/BSD execve - in the word SYSTEM) don't
> > flipping know what I'm doing wrong and haven't had a decent 2-3 hours
> > to sit down to it till .. God, Thursday.. work = ftl :(.
> > Robert Spykerman
>
> Have you looked at `man 2 execve' on your OS X box? Compare _it_ to its
> counterpart on your Linux system. Who knows, `man' is often your friend.
Actually I have. Great idea. It would seem all that differs is the
calling convention (registers in linux nd stack in BSD/OSX).
I can't figure it out at the moment, the forth code looks good, the
syscall hooks look good, but for now the OSX version doesn't call up
and execute the shell (I refer to the word SYSTEM). I'm sure there's
something blindingly obvious I'm missing but I'll get there :)
> As well, it may be worth your while to join the freebsd-developers
> mailing list. After all, those boys are responsible for lineage that
> Darwin OS X originates from. HTH....
True. I guess if this ports over to OSX, it'll probably mean just a
similar port over to BSD.
Robert Spykerman
Duke Normandin
> On Apr 20, 12:20 am, Duke Normandin <dukeofp...@ml1.net> wrote:
[snip]
>> As well, it may be worth your while to join the freebsd-developers
>> mailing list. After all, those boys are responsible for lineage that
>> Darwin OS X originates from. HTH....
>
> True. I guess if this ports over to OSX, it'll probably mean just a
> similar port over to BSD.
>
> Robert Spykerman
What I meant was that if you continue to have problems with
`man 2 execve', then asking one of the FreeBSD developers for a clue
will probably save you a lot of time. Some of those BSD kernel
hackers are awesome.
--
Duke Normandin
Thomas Pornin
> I'd start with a tool that parses traditional EBNF.
For Java, the "natural" thing to do would not be implementing a new
parser and compiler for the Java syntax, but a virtual machine for the
compiled Java code (the "bytecode", aka ".class format"). The tool which
converts Java source code into bytecode is provided by Sun (it is the
"Java compiler") and it is already written in Java (i.e. provided as
bytecode).
Turning bytecode into Forth code is not difficult: the bytecode runs
over an abstraction which happens to be a stack machine. But you need a
good garbage collector and most of the work is implementing a proper
standard library compatible with the standard one from Sun (and it is
_huge_ !).
The same applies for C#. Implementing the virtual machine means that
you immediately support all the languages which target that machine.
--Thomas Pornin
Elizabeth D Rather
...
> It looks like WAY WAY too much work to write device drivers etc... I
> mean, look every PC's gonna be different, you're gonna have one with
> this network card, that GFX card etc, mmmm... PCI bus...mmm... USB...
> Sounds like a royal pain. How you gonna cover all the devices people
> are reasonably expected to have? Even writing drivers for just the
> stuff you own yourself's gonna be a right pain.
Writing drivers is vastly overrated as far as difficulty is concerned.
It is waaay easier to write drivers than to interface to an OS (any OS).
For many years FORTH, Inc. supported fully native implementations on
PCs and various microprocessor "development systems". We abandoned
supporting a native Forth on PCs because the utility of being able to
run other apps with minimal fuss under DOS and later Windows was more
valuable, not only to us but to our customers.
The problem isn't individual drivers, which (in a native Forth) take
somewhere between a few hours and a few days each, it's that there's a
virtually unlimited number of them. Providing a general-purpose system
that will support virtually any device you throw at it is unrealistic,
unless you have either an unlimited market (e.g. Microsoft) or vast
number of contributors (e.g. Linux). That's the "network economy" at
work. We don't have it.
My friend Greg Bailey still supports a fully native Forth OS on PCs for
a number of customeers (less aggressively since he started working for
Intellasys), but at least they trust him to configure their hardware.
And his systems only run large databases (many, many times faster than
*nix, let alone Windows) plus email/ftp services. They don't attempt to
be "everything to everybody".
> Then you got to convince everyone your OS is the next great thing and
> to come and write drivers, utils and apps for it etc..
That's the killer.
Gerry
>
> I'd start with a tool that parses traditional EBNF. Anton Ertl's Grey
> and Brad Rodriguez's BNF parser both parse BNF, but as I understand it
> they both use their own idiosyncratic commands and they both parse by
> whitespace. Traditional BNF code doesn't care about whitespace and
> usually will have to be massaged to fit a Forth parser. If we can accept
> EBNF as it's usually written that might be a start toward writing
> compilers for languages that have EBNF descriptions.
>
Just over a year ago when using the Gray parser generator I found the
Gray syntax too cumbersome so I wrote a EBNF to Gray converter i.e.
takes in a EBNF grammar [1], with embedded actions, and outputs a Gray
source file. This converter is itself a Gray application that takes in
its EBNF description to produce its own Gray source code. If anyone is
interested I can make it available.
Gerry
[1] 2 small additions to EBNF, firstly each production has to end with
a semicolon, secondly the first production is assumed to be the root
and name of the grammar.
Jonah Thomas
> Jonah Thomas <jethom...@gmail.com> wrote:
> >
> > I'd start with a tool that parses traditional EBNF. Anton Ertl's
> > Grey and Brad Rodriguez's BNF parser both parse BNF, but as I
> > understand it they both use their own idiosyncratic commands and
> > they both parse by whitespace. Traditional BNF code doesn't care
> > about whitespace and usually will have to be massaged to fit a Forth
> > parser. If we can accept EBNF as it's usually written that might be
> > a start toward writing compilers for languages that have EBNF
> > descriptions.
> >
>
> Just over a year ago when using the Gray parser generator I found the
> Gray syntax too cumbersome so I wrote a EBNF to Gray converter i.e.
> takes in a EBNF grammar [1], with embedded actions, and outputs a Gray
> source file. This converter is itself a Gray application that takes in
> its EBNF description to produce its own Gray source code. If anyone is
> interested I can make it available.
>
>
> a semicolon, secondly the first production is assumed to be the root
> and name of the grammar.
I'd be very much interested. I put an hour into doing it from scratch.
Something that already works....
Albert van der Horst
Saturday April 12th we had a very interesting talk about the
usage of Forth to build a switched power supply. With very
few external components (mainly a FET and a choke) the micro
processor took up the chores of feedback to establish
a good on/off ratio and a reasonable working frequency.
(Code size 271 bytes). This is of course a cross compiling system
using the Byteforth of Willem Ouwerkerk.
http://forth.hccnet.nl/ (most pages in Dutch, sorry)
It compares favourably, at least for DIY, to dedicated chips,
that are hard to come by in single quantities. It is very flexible.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Gerry
>
> - Show quoted text -
I've emailed you a copy. I'd appreciate it if you let me know how you
got on with it or if the email doesn't reach you
Gerry
Jonah Thomas
> I've emailed you a copy. I'd appreciate it if you let me know how you
> got on with it or if the email doesn't reach you
It arrived intact. I've spent half an hour looking at it, I can follow
in general what it's doing. It looks more complicated than I expected. I
probably haven't noticed all the subtle problems that need to be solved.
I want to ask anyone who's interested about a programming puzzle I ran
into when I tried something similar.
The idea is to have a routine GOOD-STRING that accepts a string ( ca len
) and an execution token that acts on the string and checks the first
part of the string for some condition. Like, it couild test whether a
character is an uppercase letter, or whether it's a digit, or
alphanumeric, or whether two characters are ":=" or whatever. The
execution token should accept an address in the string, and it returns a
flag.
XT ( ca -- flag )
The routine does ( ca len xt -- ca len' ) . It returns as much of the
string as meets the condition the execution token tests for.
So I'd wind up with:
: STRING-CHECKER ( S: xt "name" -- )
( child: ca len -- ca len' )
CREATE ,
DOES> @ GOOD-STRING ;
to make a collection of named routines to check strings in various ways.
My first attempt at GOOD-STRING was like this:
: GOOD-STRING1 ( S: ca len xt -- ca len' )
>R
2DUP BEGIN
DUP 0 > WHILE
OVER R@ EXECUTE WHILE
1 /STRING
REPEAT
THEN
NIP - RDROP ;
This works adequately but it's clumsy. A complicated loop and a return
stack item. No way to simplify it that matters, not without getting rid
of either the complex loop or the >R or both. Using locals would handle
it easily but I didn't want to do that. I thought there ought to be a
good way to do this without locals. I only care about 3 items, surely I
can handle 3 stack items.
So I tried to get rid of the loop with recursion. I had just the looping
part recurse.
: CHECK-STRING2 ( ca len xt -- ca' len' xt )
OVER 0 > IF
>R OVER R@ EXECUTE IF
1 /STRING R> RECURSE
ELSE
R>
THEN
THEN ;
This is not great. My first recursive approach was even worse. I tried
to get rid of the xt, but then I needed extra branches to get rid of it
consistently. Easier to DROP it once when the routine is done. I figure
branches are a little better than loops and there's only one RECURSE
isntead of two WHILEs. But it isn't simple and there's no obvious way to
factor it.
I could get rid of the return stack ops by using DEFER .
DEFER CHECKER
: CHECK-STRING3 ( ca len -- ca' len' )
DUP 0 > IF
OVER CHECKER IF
1 /STRING RECURSE
THEN
THEN ;
The DOES> child can simply put the xt into CHECKER and it works. Simple.
But not easily re-entrant. I will want to be checking a string and in
the middle I'll need to start checking for something else, and then
continue where I left off. To do that I have to save the old value of
CHECKER and there's no standard way to get that. I'd have to save the
old value on a stack. The complication pops up there.
So I did without the deferred variable.
: CHECK-STRING4 ( xt ca len -- xt ca' len' )
DUP 0 > IF
OVER 2OVER DROP EXECUTE IF
1 /STRING RECURSE
THEN
THEN ;
Changing the stack order helped some. The return stack mess is gone, and
the side branches. The only troublesome bit is a little spot of stack
noise. Would 3PICK look better than 2OVER DROP ?
I can make it look nicer.
: CHECK-STRING5 ( xt ca len -- xt ca' len' )
3DUP 0 > IF
SWAP EXECUTE IF 1 /STRING RECURSE THEN
THEN ;
3DUP is not really simpler than 3PICK . It's easier for me to see what's
going on, but the obvious way to implement 3DUP in high-level standard
Forth is : 3DUP 2PICK 2PICK 2PICK ;
Only 3 stack items. Why is it so hard? Because with ( a b c ) the things
we need to do require copies
len
ca xt
ca len original, not copy
xt ca len original
There's no way to get all four patterns without some stack juggling. (Or
locals.)
When is this sort of perfectionism justified? I got something that
worked in 3 minutes. After a series of false starts I got something that
approched elegance. It still has a RECURSE so it wouldn't be as easy to
debug at the keyboard as something that didn't have recursion or loops.
Luckily it passed my tests the first try.
: GOOD-STRING2 { ca len xt }
ca len BEGIN
DUP 0 > WHILE
OVER xt EXECUTE WHILE
1 /STRING
REPEAT
THEN
NIP ca len ROT - ;
A few locals are enough to get past some of the worst problems. And if a
few locals are good, maybe more locals are better. With 2 more locals
and liberal use of TO I can eliminate every stack word.
: GOOD-STRING2 0 0 { ca len xt ca' len' }
ca TO ca' len TO len' BEGIN
len' 0 > WHILE
ca' xt EXECUTE WHILE
ca' len' 1 /STRING TO len' TO ca'
REPEAT
THEN
ca len len' - ;
Better? Not only do you eliminate the stack words, the stack comments
are part of the code.
When is it worthwhile to make the code simple? I have to figure the
ideal approach is to do it simply the first time. If you write elegant
code quickly, so the first version is easy to understand and easy to
test and easy to document etc, then you don't have to think about how
much time to spend improving it.
Gerry
Personally I think you're worrying unnecessarily, your first attempt
looks OK to me. When working with strings I often end up with a
BEGIN... WHILE...WHILE...REPEAT...THEN structure. The only thing that
grates is the THEN. I think it looks more complicated because of the
way you've laid it out.
Incidentally if you have a Forth that handles multiple local
declarations( I think GForth does) you can simplify your last attempt
by getting rid of the TO's e.g.
: GOOD-STRING2 { ca len xt }
ca len
BEGIN
{ ca' len' }
len' 0 >
WHILE
ca' xt EXECUTE
WHILE
ca' len' 1 /STRING
REPEAT
THEN
ca len len' -
;
Untested but I don't see why it wouldn't work, but probably isn't
F200X compliant. It also shows my preferred layout.
Gerry
Gerry
> > I've emailed you a copy. I'd appreciate it if you let me know how you
> > got on with it or if the email doesn't reach you
>
> It arrived intact. I've spent half an hour looking at it, I can follow
> in general what it's doing. It looks more complicated than I expected. I
> probably haven't noticed all the subtle problems that need to be solved.
>
Yes it's more complicated than it need be to solve that particular
problem but this converter was a by-product from finding a general
solution to the problem of using my LexGen tool with the Gray parser
generator. It was a simple example that was a proof of concept and
just happens to be useful. I found that using Gray is rather
complicated, the BNF to Gray converter makes it somewhat simpler. Does
the internal complexity matter if it works and is easy to use?
Gerry
Josh Grams
>
>: GOOD-STRING1 ( S: ca len xt -- ca len' )
> >R
> 2DUP BEGIN
> DUP 0 > WHILE
> OVER R@ EXECUTE WHILE
> 1 /STRING
> REPEAT
> THEN
> NIP - RDROP ;
>
> This works adequately but it's clumsy. A complicated loop and a return
> stack item.
I don't see anything wrong with using a return stack item...actually I
rather like the return stack for things like this. I find it easier to
remember that there is one thing on the return stack, and what it is,
than remembering the order of the three things on the data stack.
And you have two loop-ending conditions, so it's bound to be at least
slightly complicated. And this is a low-level word, so IMO a bit of
complexity is acceptable...
I found this in one of my programs:
\ For both of the following words, XT should be ( char -- flag )
: SKIP-WHILE ( addr u xt -- addr' u' )
>R BEGIN DUP WHILE
OVER C@ R@ EXECUTE WHILE 1 /STRING
REPEAT THEN R> DROP ;
: SPLIT-WITH ( addr u xt -- addr' u' addr u2 )
>R 2DUP R> SKIP-WHILE 2TUCK NIP - ;
> I can make it look nicer.
>
>: CHECK-STRING5 ( xt ca len -- xt ca' len' )
> 3DUP 0 > IF
> SWAP EXECUTE IF 1 /STRING RECURSE THEN
> THEN ;
I like that...except you need a 3DROP after the final THEN.
> 3DUP is not really simpler than 3PICK . It's easier for me to see what's
> going on, but the obvious way to implement 3DUP in high-level standard
> Forth is : 3DUP 2PICK 2PICK 2PICK ;
I think 3DUP is definitely simpler than 3 PICK, but then I don't really
care about the implementation; just whether I can read the code.
--Josh
David N. Williams
> [...]
> [improvement iterations]
Like Gerry, I think this first attempt looks fine.
Here's a similar approach, from a translator I've stopped
working on for the time being.
: make-recog ( "name" xt -- )
---
Define a word that executes the "is" string test procedure
xt, leaving true if so, else false and the string. The
stack pattern for the procedure is
( s -- after.s is.s true | s false )
where is.s is the part of the input string up to the
character where it fails to "be-a", and after.s is the rest
of the string, including that character. In the true case,
it is assumed that is.s cannot be empty.
---
create ,
DOES> ( s -- after.s true | s false )
@execute ( after.s is.s true | s false)
IF ( is.s) sdrop ( after.s) true
ELSE ( s) false THEN ;
The "is" recognition procedures are coded as C primitives, in a
pfe loadable module. SDROP is an alias for 2drop, "s" and "x.s"
stand for ANS Forth strings, and --- is a multiline comment
word.
-- David
Jonah Thomas
First off, I think that anything that works is better than anything that
doesn't work. And I don't want to look a gift horse in the mouth, I sure
don't want to complain about your work.
You pointed out that the documentation isn't finished. With the
documentation it will be clearer that some of the sections provide
simple tools that make the next sections easier to manage.
It was late at night and I was feeling kind of philosophical. A fair
number of people have tried Forth and quit it, and some of them say
afterward that when they started it they had a dream that they could
build things out of simple parts connected simply. That it would all
work out, and they wouldn't get drowned in complexity. But then they
tried Forth and it didn't work for them. Sometimes they say they could
do 70% of what they wanted simply, but the result was a toy. Or they got
drowned in complexity anyway. Etc. The dream wasn't fulfilled for them,
and they gave it up.
People say it works for Chuck Moore. He writes lots of routines that are
a line or two each. Simple, clear, powerful. It does 90% of what you'd
want it to, and the other 10% isn't needed. If it's true that 10% of the
specs generate 90% of the complexity and that 10% isn't really
needed.... People say Chuck is the best at using Forth. I'd like to be
better at it than I am. What does Chuck do that I don't do? What do I do
that I shouldn't?
So here we are doing string manipulation in Forth. Only the most
primitive tools are provided. We can do anything we want and we have to
do it ourselves. Come up with a simple elegant low-overhead approach
that makes the later stuff simpler, and we'll really have something.
Implement the same things that Python already has and we wind up with
RPN stack-oriented Python with our own special names. It's OK to do
something that takes a little extra effort to learn, that makes it
simpler later. But if we have to do it ourselves and we don't wind up
with something better than what other languages give us already,
batteries-included, why do it?
I think you're doing some of that. You use mini-OOF and you have your
special LexGen tool, which will both turn out to be used simply. I was
thinking about Forth complexity and I happened to be looking at your
code at the time. I didn't intend to criticise it.
Jonah Thomas
: CHECK-STRING5 ( xt ca len -- xt ca' len' )
3DUP 1- 0< IF
2DROP
ELSE
SWAP EXECUTE IF 1 /STRING RECURSE THEN
THEN ;
> Personally I think you're worrying unnecessarily, your first attempt
> looks OK to me. When working with strings I often end up with a
> BEGIN... WHILE...WHILE...REPEAT...THEN structure. The only thing that
> grates is the THEN. I think it looks more complicated because of the
> way you've laid it out.
A loop with mutiple WHILEs is inherently complex. And the results are
separated from the code that creates them. I don't want to do that when
there's a better way. This particular time it turned out that a pretty
simple tail-recursion worked. So I want to try tail-recursion and
recursion before I try a loop with multiple WHILEs.
> Incidentally if you have a Forth that handles multiple local
> declarations( I think GForth does) you can simplify your last attempt
> by getting rid of the TO's e.g.
>
> : GOOD-STRING2 { ca len xt }
> ca len
> BEGIN
> { ca' len' }
> len' 0 >
> WHILE
> ca' xt EXECUTE
> WHILE
> ca' len' 1 /STRING
> REPEAT
> THEN
> ca len len' -
> ;
>
> Untested but I don't see why it wouldn't work, but probably isn't
> F200X compliant. It also shows my preferred layout.
I like to indent to show the nesting. Every now and then I start to make
an error that this catches. I figure that if I'm making errors then my
code is too complicated -- but how do you simplify a loop with multiple
exits? I think it's kind of simpler to use EXIT . You know the stack
state when you do EXIT is just what you'll get when your definition is
done. You don't have to depend on code somewhere else to do the right
thing. But sometimes that isn't simpler after all.
I made an error even with my simple tail-recursion code. I changed
something and forgot about the case where the string was empty. The code
that handled that was down at the bottom.
I'm better off if my habits make it easier to avoid errors. Try the
simplest way first. Do things that let me concentrate on one part at a
time without having to think about how it affects code somewhere else,
apart from the stack.
I liked multiple WHILEs when I first saw them. They were technically
good, and they made it easy to do multiple tests. But maybe it made it
easier to write things in complicated ways.
It would be good if the layout of the language encouraged good coding
habits. When I started using Forth it had some things that strongly
discouraged some bad coding habits. Code went into 1K blocks which
discouraged routines longer than 16 lines of 64 characters. There were
no tools to help debug complicated routines, which discouraged big
complicated routines. The overhead for factoring was small, so there was
no particular advantage to putting in .S and ." statements to show what
was happening inside the code, as opposed to making each section be its
own routine that could be tested in isolation.
It encouraged adequate coding habits by breaking when people used bad
habits. Of course, a lot of people who tried it decided that it didn't
work rather than find out how to make it work.
So I'm starting to see multiple WHILE kind of like I see PICK though
less so. I like to have it available in case I get into a jam that needs
it. But if I need it, that's a hint that maybe I've already made a
mistake, I've painted myself into a corner where I need PICK to get out.
Bruce McFarling
> Only 3 stack items. Why is it so hard? Because with ( a b c ) the things
> we need to do require copies
>
> len
> ca xt
> ca len original, not copy
> xt ca len original
> There's no way to get all four patterns without some stack juggling. (Or
> locals.)
Or a string reference stack. Or an xt-stack ...
>ACT
USE-ACT ( destructive)
REPEAT-ACT ( non-destructive)
ACT>
DROP-ACT
... indeed, if you don't need the R-stack except for the XT, you could
start out with those as R-stack macros until they proved out as useful.
Gerry
> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> > Jonah Thomas <jethom...@gmail.com> wrote:
> > > Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> > > > I've emailed you a copy. I'd appreciate it if you let me know how
> > > > you got on with it or if the email doesn't reach you
>
> > > It arrived intact. I've spent half an hour looking at it, I can
> > > follow in general what it's doing. It looks more complicated than I
> > > expected. I probably haven't noticed all the subtle problems that
> > > need to be solved.
>
> > Yes it's more complicated than it need be to solve that particular
> > problem but this converter was a by-product from finding a general
> > solution to the problem of using my LexGen tool with the Gray parser
> > generator. It was a simple example that was a proof of concept and
> > just happens to be useful. I found that using Gray is rather
> > complicated, the BNF to Gray converter makes it somewhat simpler. Does
> > the internal complexity matter if it works and is easy to use?
>
> First off, I think that anything that works is better than anything that
> doesn't work. And I don't want to look a gift horse in the mouth, I sure
> don't want to complain about your work.
>
Don't worry I hadn't taken umbrage. I was simply trying to explain why
I had taken what might seem to be a heavyweight approach.
Gerry
Elizabeth D Rather
...
> People say it works for Chuck Moore. He writes lots of routines that are
> a line or two each. Simple, clear, powerful. It does 90% of what you'd
> want it to, and the other 10% isn't needed. If it's true that 10% of the
> specs generate 90% of the complexity and that 10% isn't really
> needed.... People say Chuck is the best at using Forth. I'd like to be
> better at it than I am. What does Chuck do that I don't do? What do I do
> that I shouldn't?
Understanding that your percentages here are entirely rhetorical, I
think you're on the right track. The big difference between Chuck and a
lot of folks here is that he only solves the particular problem at hand
-- he is never groping for a general solution. He would never say, "I
need a better string handling package." Instead, confronted with a
particular string challenge, he'd find the most direct way of dealing
with it. If he is working on an application full of strings, he'd find
ways to deal with its specific issues, and factor some of the common
needs into reusable definitions, but he would never be searching for
either "general purpose" functions or attempting to replicate what some
other language did.
Whether this is good or bad, I can't say... but if you ask "What does
Chuck do that I don't do?" that's the answer.
Marcel Hendrix
[..]
> I want to ask anyone who's interested about a programming puzzle I ran
> into when I tried something similar.
> : GOOD-STRING2 0 0 { ca len xt ca' len' }
> ca TO ca' len TO len' BEGIN
> len' 0 > WHILE
> ca' xt EXECUTE WHILE
> ca' len' 1 /STRING TO len' TO ca'
> REPEAT
> THEN
> ca len len' - ;
Or:
: GOOD-STRING2 ( ca len xt -- ca' len' )
LOCALS| xt len |
len BOUNDS DO I xt EXECUTE
0= IF I len UNLOOP EXIT ENDIF
-1 +TO len
LOOP
0. ;
-marcel
Gerry
> Jonah Thomas wrote:
>
> ...
>
> > People say it works for Chuck Moore. He writes lots of routines that are
> > a line or two each. Simple, clear, powerful. It does 90% of what you'd
> > want it to, and the other 10% isn't needed. If it's true that 10% of the
> > specs generate 90% of the complexity and that 10% isn't really
> > needed.... People say Chuck is the best at using Forth. I'd like to be
> > better at it than I am. What does Chuck do that I don't do? What do I do
> > that I shouldn't?
> >...
>
> Understanding that your percentages here are entirely rhetorical, I
> think you're on the right track. The big difference between Chuck and a
> lot of folks here is that he only solves the particular problem at hand
> -- he is never groping for a general solution. He would never say, "I
> need a better string handling package." Instead, confronted with a
> particular string challenge, he'd find the most direct way of dealing
> with it. If he is working on an application full of strings, he'd find
> ways to deal with its specific issues, and factor some of the common
> needs into reusable definitions, but he would never be searching for
> either "general purpose" functions or attempting to replicate what some
> other language did.
>
> Whether this is good or bad, I can't say... but if you ask "What does
> Chuck do that I don't do?" that's the answer.
>
Yes different approaches to getting the job done. Earlier in this
thread I was effectively apologising for the BNF to Gray format
converter being a bit complicated but on thinking about it I don't
think it is really. To build this converter, which is an off-line
tool, I used:
- some library code to provide memory buffers
- an off-line tool (LexGen) to generate transition tables for a
lexical scanner
- library code for the lexical scanner
- another tool (Gray) for the parser generator
and then wrote higher level code to tie it together and make it all
work.
Contrast this with the typical Forther approach of doing the whole
thing from scratch, e.g. Jonah developing code for text recognition -
a problem that is already solved by a general purpose lexical scanner.
This of course results in more concise source code, faster code etc.
but probably takes longer to develop.
Which is the best approach, I don't know, I suppose it depends on your
point of view, but I know which I prefer.
Gerry
Ian Osgood
This has come to be known as "post-modern programming", and is
supported by various glue and scripting environments like shells,
Perl, Python, etc. coupled with growing code libraries like Unix,
Boost, CPAN and various other standard libraries.
The premise is that as time goes on, the number of existing solutions
to programming problems increases, and the practical effort to plug
existing solutions together should become less than
the effort to craft one's own solutions. The post-modern skill set is
slightly different, synthetic instead of creative.
Note that you can still get the benefits of tight custom solutions
with post-modern programming, if you have access to source and not
just black-box libraries. In one application, I took an existing
device driver that was both too general and half-baked, stripped 75%
of the code out of it, leaving only a tight core that was tailored to
our application. This works well in shared source cultures like Forth.
> Contrast this with the typical Forther approach of doing the whole
> thing from scratch, e.g. Jonah developing code for text recognition -
> a problem that is already solved by a general purpose lexical scanner.
> This of course results in more concise source code, faster code etc.
> but probably takes longer to develop.
I suggest that the Forth way of writing from scratch was a product of
its time. In the 70s and 80s, you didn't have public repositories of
existing solutions. Also, each programmer became his own resource,
notably Chuck and Forth vendors, and their experience porting to wide
varieties of systems.
> Which is the best approach, I don't know, I suppose it depends on your
> point of view, but I know which I prefer.
>
> Gerry
I personally think post-modern programming is the way of the future. A
language which cannot support it is doomed to the sidelines. Thus, I
think Forth should start borrowing from other languages, continuing to
standardize but focusing more on standard code libraries, import
mechanisms, foreign-function interfaces and otherwise working well
with others.
Ian
John Passaniti
> Contrast this with the typical Forther approach of doing the whole
> thing from scratch, e.g. Jonah developing code for text recognition -
> a problem that is already solved by a general purpose lexical scanner.
> This of course results in more concise source code, faster code etc.
> but probably takes longer to develop.
>
> Which is the best approach, I don't know, I suppose it depends on your
> point of view, but I know which I prefer.
Actually, what is the best approach has little to do with one's point of
view. It has to do with requirements.
I come to you and say, "I need code to execute on a platform that is
very resource limited. You have a relatively slow processor and data
coming in at a constant rate that can't be dropped. We want to ship
this in a couple months." These requirements suggest a "from scratch"
implementation, maximizing space and time efficiency, and eschewing
abstractions.
Now I come to you and say, "I have a few megabytes of data that I need
to extract some features from. The data I care about can be described
as a grammar, and the processing I need is some pretty basic statistics.
Oh, and I need this tomorrow." These requirements suggest reusing
existing generalized tools, working at a high level of abstraction, and
not worrying about space and time efficiency because it's far more
important to get an answer quickly than in having the most elegant code
possible.
Where I work, this kind of dynamic range between projects happens all
the time. And so it demands getting out of the mental trap that there
is a general best approach. It's certainly possible to say that a
particular approach is best for a specific context, but to suggest that
can be generalized is usually evidence that the person making the claim
has limited scope. (And here in comp.lang.forth, this is also often
evidenced by how dogmatic the person is about the claim.)
So getting back to Elizabeth Rather's description of Charles Moore's
approach (solve only the problem in front of you, be direct, avoid
unnecessary abstraction), she stated that she couldn't say if that
approach was good or bad. Okay, I'll say: It's exactly the right
approach for cases where it makes sense, and exactly the wrong approach
for cases where it doesn't. Shocking. This will require people *think*
not just about the problem being solved, but the appropriateness of the
approach.
John Passaniti
> The premise is that as time goes on, the number of existing solutions
> to programming problems increases, and the practical effort to plug
> existing solutions together should become less than
> the effort to craft one's own solutions. The post-modern skill set is
> slightly different, synthetic instead of creative.
Of course, there isn't a strict wall between the two. Look at mash-ups
based on web services as one example. Yeah, the people doing that work
are just gluing existing services things together, but sometimes the
creativity comes from seeing how two services can be put together to
create something entirely new.
Elizabeth D Rather
Actually, what I meant by "I can't say" above is that I completely agree
with you -- it depends on the circumstances. In addition to the two
very valid scenarios you describe, other common ones here are, "I want
to re-write because it helps me understand the problem better" and "I
want to write a Forth version to get more practice with Forth."
Gerry
> Gerry wrote:
> > Contrast this with the typical Forther approach of doing the whole
> > thing from scratch, e.g. Jonah developing code for text recognition -
> > a problem that is already solved by a general purpose lexical scanner.
> > This of course results in more concise source code, faster code etc.
> > but probably takes longer to develop.
>
> > Which is the best approach, I don't know, I suppose it depends on your
> > point of view, but I know which I prefer.
>
> Actually, what is the best approach has little to do with one's point of
> view. It has to do with requirements.
>
Yes of course, that was a rather careless statement of mine
Gerry
Alex McDonald
>
> I personally think post-modern programming is the way of the future. A
> language which cannot support it is doomed to the sidelines. Thus, I
> think Forth should start borrowing from other languages, continuing to
> standardize but focusing more on standard code libraries, import
> mechanisms, foreign-function interfaces and otherwise working well
> with others.
>
> Ian
Prosaic mode:
Then there is hope for "fat Forths" like Win32Forth. If there's one
thing W32F encourages, it's getting leverage from existing libraries
of code (DLLs primarily). The only downside at the moment is the
automation of the interface, where MPE's VxForth has the neat ability
to import C function headers directly. I've worked a little with SWIG
(http://www.swig.org/) and used XSLT on the XML output it generates,
but it's far from automatic.
Anton Ertl started some time back on a generalised C function
interface (http://www.complang.tuwien.ac.at/papers/ertl06.ps.gz and
http://www.complang.tuwien.ac.at/papers/ertl07euroforth.ps.gz). More
please.
--
Regards
Alex McDonald
Stephen Pelc
<bl...@rivadpm.com> wrote:
>Then there is hope for "fat Forths" like Win32Forth. If there's one
>thing W32F encourages, it's getting leverage from existing libraries
>of code (DLLs primarily). The only downside at the moment is the
>automation of the interface, where MPE's VxForth has the neat ability
>to import C function headers directly. I've worked a little with SWIG
>(http://www.swig.org/) and used XSLT on the XML output it generates,
>but it's far from automatic.
VFX Forth started from the user perspective. Where does the
information come from? In the main, it comes from C header
files.
Sure you can go through SWIG, but the required parser just isn't
that complicated. For a big hint, start with Brad Rodriguez BNF
implementation, which is tiny, good, and not difficult to extend.
Brad's BNF parser can also be used to solve a wide range of
notational issues. It is often stated that Forth is a way of
writing new notations, so I am constantly amazed that tools
for writing notations are widely ignored.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Gerry
> On Apr 22, 6:00 pm, Ian Osgood <i...@quirkster.com> wrote:
>
>
>
> > I personally think post-modern programming is the way of the future. A
> > language which cannot support it is doomed to the sidelines. Thus, I
> > think Forth should start borrowing from other languages, continuing to
> > standardize but focusing more on standard code libraries, import
> > mechanisms, foreign-function interfaces and otherwise working well
> > with others.
>
> > Ian
>
> Prosaic mode:
>
> Then there is hope for "fat Forths" like Win32Forth. If there's one
> thing W32F encourages, it's getting leverage from existing libraries
> of code (DLLs primarily).
That's something I want to introduce into my system, a project for
the future as I haven't a clue how to do it at present.
> The only downside at the moment is the
> automation of the interface, where MPE's VxForth has the neat ability
> to import C function headers directly. I've worked a little with SWIG
> (http://www.swig.org/) and used XSLT on the XML output it generates,
> but it's far from automatic.
>
Presumably this is essentially text translation, XML to Forth and this
is probably a silly question. Is there scope for using LexGen and
Gray to do this as for the BNF to Gray tool discussed earlier in this
thread or would that not offer any advantage over XSLT.
Gerry
Alex McDonald
> On Wed, 23 Apr 2008 01:00:52 -0700 (PDT), Alex McDonald
>
> >Then there is hope for "fat Forths" like Win32Forth. If there's one
> >thing W32F encourages, it's getting leverage from existing libraries
> >of code (DLLs primarily). The only downside at the moment is the
> >automation of the interface, where MPE's VxForth has the neat ability
> >to import C function headers directly. I've worked a little with SWIG
> >(http://www.swig.org/) and used XSLT on the XML output it generates,
> >but it's far from automatic.
>
> VFX Forth started from the user perspective. Where does the
> information come from? In the main, it comes from C header
> files.
>
> Sure you can go through SWIG, but the required parser just isn't
> that complicated. For a big hint, start with Brad Rodriguez BNF
> implementation, which is tiny, good, and not difficult to extend.
Thanks for the hint. Link; http://www.zetetics.com/bj/papers/bnfparse.htm
>
> Brad's BNF parser can also be used to solve a wide range of
> notational issues. It is often stated that Forth is a way of
> writing new notations, so I am constantly amazed that tools
> for writing notations are widely ignored.
I've toyed with the idea of extending the interpreter; for instance,
switching to an XML parse on sight of <xml etc> at the head of a file.
If Brad's work makes it easier to write parsers, then that's a route
I'll investigate.
>
> Stephen
>
> --
> Stephen Pelc, stephen...@mpeforth.com
Alex McDonald
Yes, the XSLT is just transformation of the SWIG XML output. However,
there's still a lot of hand editing to do; not all C function headers
are amenable to this level of automation in XSLT without a lot of
work. Plus, XSLT is quite hard to use and write; it qualifies as a
write-only language IMHO. Revisiting it today made me realise how ugly
it is for humans to parse. There must be better transformation
languages out there, but when the input is XML...
>
> Gerry
--
Regards
Alex McDonald
Jonah Thomas
> Jonah Thomas wrote:
> ...
> > People say it works for Chuck Moore. He writes lots of routines that
> > are a line or two each. Simple, clear, powerful. It does 90% of what
> > you'd want it to, and the other 10% isn't needed. If it's true that
> > 10% of the specs generate 90% of the complexity and that 10% isn't
> > really needed.... People say Chuck is the best at using Forth. I'd
> > like to be better at it than I am. What does Chuck do that I don't
> > do? What do I do that I shouldn't?
> >...
>
> Understanding that your percentages here are entirely rhetorical,
Yes. I was using the generalized 90:10 rule where people say that 10% of
something is responsible for 90% of something else. (Occasionally they
use an 80:20 rule instead, which gives a hint of the precision
intended.) And I read somewhere that you found Chuck to produce things
that were always 90% complete. But a quick lit search didn't find that.
It did find you saying that he'd look at the specs and say "This is
easy!" and then make something simple that solved the core of the
problem. Then there would be a lot of this-and-that with the customer
where they said what else they wanted, and he'd add it, and it got more
complicated. Then when it was clear what the customer really wanted he'd
rewrite that simply, from the beginning.
> I think you're on the right track. The big difference between Chuck
> and a lot of folks here is that he only solves the particular problem
> at hand -- he is never groping for a general solution. He would never
> say, "I need a better string handling package." Instead, confronted
> with a particular string challenge, he'd find the most direct way of
> dealing with it. If he is working on an application full of strings,
> he'd find ways to deal with its specific issues, and factor some of
> the common needs into reusable definitions, but he would never be
> searching for either "general purpose" functions or attempting to
> replicate what some other language did.
So, after he'd done that a number of times he'd have a sense of which
tools are most useful for a string package. He'd have those handy
because they worked consistently before. If you start out wanting to
design a string package you might easily do things that aren't what you
need. You might easily have complications that you think ahead of time
are needed, and then when you or others use it they accept those
complications as a necessary part of string handling.
> Whether this is good or bad, I can't say... but if you ask "What does
> Chuck do that I don't do?" that's the answer.
Thank you. It sounds like, by continually re-inventing wheels he both
refines his concept of what kind of wheels he likes, so he does it
better, and also he improves his tools for rebuilding wheels. But his
new code may not be much like his old code, so he'd have more trouble if
he has to go back to old stuff to make small changes. But if he has the
excuse to rewite completely he's likely to do even better this time....
When you regard something as "already solved" then you get the benefit
of using the existing code, and you lose the benefit of improving it.
And if you do enough of that, at some point it isn't worth using a
better solution because if you do you have to keep converting to the
style that the libraries use so you can keep using them.
So we have people who do things with HTML with TCP/IP when it's utter
overkill for their application, because they need to have all that
machinery available for unrelated purposes and so it's available. Unless
they desperately need something more efficient, why go to the trouble of
developing anything else?
Anton Ertl
>Then there is hope for "fat Forths" like Win32Forth. If there's one
>thing W32F encourages, it's getting leverage from existing libraries
>of code (DLLs primarily). The only downside at the moment is the
>automation of the interface, where MPE's VxForth has the neat ability
>to import C function headers directly. I've worked a little with SWIG
>(http://www.swig.org/) and used XSLT on the XML output it generates,
>but it's far from automatic.
>
>Anton Ertl started some time back on a generalised C function
>interface (http://www.complang.tuwien.ac.at/papers/ertl06.ps.gz and
>http://www.complang.tuwien.ac.at/papers/ertl07euroforth.ps.gz). More
>please.
What has been described there is implemented in the current
development version (but it needs more polishing before we can release
it for use on machines that may have several Gforth processes).
This also processes C header files automatically. However, in
addition to the C types, which are described in the C header file, we
need to know the Forth types of the function arguments.
One approach to this is to have a mapping from the basic C type to the
Forth type, but that's not portable across platforms: on one platform
the C type of an argument can be a long long, which might be mapped to
a double-cell in Forth, and on another it can be a long, which may be
mapped to a single cell in Forth.
The current approach in development Gforth is to declare the Forth
types manually, but a student of mine works on a SWIG-based tool that
generates declarations automatically from C header files, based on a
mapping from the abstract C type to the Forth type (e.g., off_t would
always be a double, whether the basic type is long or long long an the
actual platform). Moreover, the idea is that someone would use that
tool to generate the Forth declarations for a given API once (and
possibly apply manual corrections), and from then on we would use the
file containing the Forth declarations whenever we want to interface
with that API.
- 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
EuroForth 2008: http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
John Passaniti
> When you regard something as "already solved" then you get the benefit
> of using the existing code, and you lose the benefit of improving it.
> And if you do enough of that, at some point it isn't worth using a
> better solution because if you do you have to keep converting to the
> style that the libraries use so you can keep using them.
I am constantly amazed at the cynical spin you manage to put on anything
that doesn't match your world view. I know it plays well in
comp.lang.forth, but where does this cynicism come from? It certainly
don't sound like experience.
Take a look at any library repository for any language that's been
around for a few years (Perl, Python, Lua, Ruby, TCL, PHP, etc.) and
what you will see is that there are often competing libraries for the
same problem. Why? If as you suggest that when problems that are
"already solved" people threw up their hands and said, "well, that's
done" then you wouldn't see that.
You also wouldn't see libraries that over time are marked as
"deprecated" with suggestions to use something newer (and presumably
better) if programmers didn't reevaluate existing libraries with
"already solved" solutions to look for something better.
Yes, there are certainly some programmers who when given a library can
only see problems in terms of that library. So what? If it enables
them to do their work, in what sense is that wrong or bad? And more
importantly, why are these programmers given such undue attention in
discussions like this?
I am *delighted* that there are libraries and tools that enable people
who in the past wouldn't be considered programmers be able to get
results. I think it's great, both because it brings more people to
actually making computers work for them they way they want, and it
upsets the priesthood of programmers. And that to me is always a good
thing.
> So we have people who do things with HTML with TCP/IP when it's utter
> overkill for their application, because they need to have all that
> machinery available for unrelated purposes and so it's available. Unless
> they desperately need something more efficient, why go to the trouble of
> developing anything else?
Any reasonably competent programmer can look at a standard like HTML or
a set of protocols like TCP/IP and probably come up with something that
is simpler or more efficient in some sense. But in doing that, you
create an island. And that's fine if you are able to operate in a
closed environment, but these days, interoperability is often a key
aspect of any design.
So it isn't that application developers turn to standards (like HTML and
TCP/IP) because their underlying systems already have it. In the
embedded world, your system rarely has anything by default-- you pick
and choose what you want based on what you need. Standards like HTML
and TCP/IP provide you something compelling you don't get by creating
your own simpler standard-- it gives you interoperability.
People *do* develop alternatives to standards all the time. In a system
I'm now working on, we store sensor data in a unique database format of
our own design. We could have used an existing database (such as
SQLite) for this application, but we didn't like the memory footprint or
some of the overhead. So the good part is we have a highly efficient
database that is tuned for our specific application.
But that's strength is also a weakness. You can't take our database and
read it in with desktop tools because it's a unique format. We've
created an island that works great for the specific things we want to
do, but will be a disappointment for people who may want to do something
more sophisticated. In our case, we don't care-- the pros of a custom
solution outweigh the cons of going with a database standard. But
that's not a general rule. It's specific to the application.
William James
> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> > I've emailed you a copy. I'd appreciate it if you let me know how you
> > got on with it or if the email doesn't reach you
>
> It arrived intact. I've spent half an hour looking at it, I can follow
> in general what it's doing. It looks more complicated than I expected. I
> probably haven't noticed all the subtle problems that need to be solved.
>
> into when I tried something similar.
>
> ) and an execution token that acts on the string and checks the first
> part of the string for some condition. Like, it couild test whether a
> character is an uppercase letter, or whether it's a digit, or
> alphanumeric, or whether two characters are ":=" or whatever.
Ruby:
--- code ---
p "abc"[ /^\d*/ ]
p "8abc"[ /^\d*/ ]
p "89abc"[ /^\d*/ ]
--- output ---
""
"8"
"89"
--- code ---
def good_string str
str.size.times do |i|
return str[0,i] if not yield str[i..-1]
end
str
end
p good_string( 'abc' ){|s| s =~ /^\d/ }
p good_string( '8abc' ){|s| s =~ /^\d/ }
p good_string( '89abc' ){|s| s =~ /^\d/ }
--- output ---
""
"8"
"89"
> The
> execution token should accept an address in the string, and it returns a
> flag.
>
> XT ( ca -- flag )
>
> The routine does ( ca len xt -- ca len' ) . It returns as much of the
> string as meets the condition the execution token tests for.
>
> So I'd wind up with:
>
> : STRING-CHECKER ( S: xt "name" -- )
> ( child: ca len -- ca len' )
> CREATE ,
> DOES> @ GOOD-STRING ;
>
> to make a collection of named routines to check strings in various ways.
>
> My first attempt at GOOD-STRING was like this:
>
> : GOOD-STRING1 ( S: ca len xt -- ca len' )
> >R
> 2DUP BEGIN
> DUP 0 > WHILE
> OVER R@ EXECUTE WHILE
> 1 /STRING
> REPEAT
> THEN
> NIP - RDROP ;
>
> This works adequately but it's clumsy. A complicated loop and a return
> OVER CHECKER IF
> 1 /STRING RECURSE
> THEN
> THEN ;
>
> The DOES> child can simply put the xt into CHECKER and it works. Simple.
> But not easily re-entrant. I will want to be checking a string and in
> the middle I'll need to start checking for something else, and then
> continue where I left off. To do that I have to save the old value of
> CHECKER and there's no standard way to get that. I'd have to save the
> old value on a stack. The complication pops up there.
>
> So I did without the deferred variable.
>
> : CHECK-STRING4 ( xt ca len -- xt ca' len' )
> DUP 0 > IF
> OVER 2OVER DROP EXECUTE IF
> 1 /STRING RECURSE
> THEN
> THEN ;
>
> Changing the stack order helped some. The return stack mess is gone, and
> the side branches. The only troublesome bit is a little spot of stack
> noise. Would 3PICK look better than 2OVER DROP ?
>
> I can make it look nicer.
>
> : CHECK-STRING5 ( xt ca len -- xt ca' len' )
> 3DUP 0 > IF
> SWAP EXECUTE IF 1 /STRING RECURSE THEN
> THEN ;
>
> 3DUP is not really simpler than 3PICK . It's easier for me to see what's
> going on, but the obvious way to implement 3DUP in high-level standard
> Forth is : 3DUP 2PICK 2PICK 2PICK ;
>
> Only 3 stack items. Why is it so hard? Because with ( a b c ) the things
> we need to do require copies
>
> len
> ca xt
> ca len original, not copy
> xt ca len original
>
> There's no way to get all four patterns without some stack juggling. (Or
> locals.)
>
> When is this sort of perfectionism justified? I got something that
> worked in 3 minutes. After a series of false starts I got something that
> approched elegance. It still has a RECURSE so it wouldn't be as easy to
> debug at the keyboard as something that didn't have recursion or loops.
> Luckily it passed my tests the first try.
>
> : GOOD-STRING2 { ca len xt }
> ca len BEGIN
> DUP 0 > WHILE
> OVER xt EXECUTE WHILE
> 1 /STRING
> REPEAT
> THEN
> NIP ca len ROT - ;
>
> A few locals are enough to get past some of the worst problems. And if a
> few locals are good, maybe more locals are better. With 2 more locals
> and liberal use of TO I can eliminate every stack word.
>
> : GOOD-STRING2 0 0 { ca len xt ca' len' }
> ca TO ca' len TO len' BEGIN
> len' 0 > WHILE
> ca' xt EXECUTE WHILE
> ca' len' 1 /STRING TO len' TO ca'
> REPEAT
> THEN
> ca len len' - ;
>
gavino
> jennifer.spyker...@gmail.com wrote:
>
> ...
>
> > It looks like WAY WAY too much work to write device drivers etc... I
> > mean, look every PC's gonna be different, you're gonna have one with
> > this network card, that GFX card etc, mmmm... PCI bus...mmm... USB...
> > Sounds like a royal pain. How you gonna cover all the devices people
> > are reasonably expected to have? Even writing drivers for just the
> > stuff you own yourself's gonna be a right pain.
>
> Writing drivers is vastly overrated as far as difficulty is concerned.
> It is waaay easier to write drivers than to interface to an OS (any OS).
> For many years FORTH, Inc. supported fully native implementations on
> PCs and various microprocessor "development systems". We abandoned
> supporting a native Forth on PCs because the utility of being able to
> run other apps with minimal fuss under DOS and later Windows was more
> valuable, not only to us but to our customers.
>
> The problem isn't individual drivers, which (in a native Forth) take
> somewhere between a few hours and a few days each, it's that there's a
> virtually unlimited number of them. Providing a general-purpose system
> that will support virtually any device you throw at it is unrealistic,
> unless you have either an unlimited market (e.g. Microsoft) or vast
> number of contributors (e.g. Linux). That's the "network economy" at
> work. We don't have it.
>
> My friend Greg Bailey still supports a fully native Forth OS on PCs for
> a number of customeers (less aggressively since he started working for
> Intellasys), but at least they trust him to configure their hardware.
> And his systems only run large databases (many, many times faster than
> *nix, let alone Windows) plus email/ftp services. They don't attempt to
> be "everything to everybody".
>
> > Then you got to convince everyone your OS is the next great thing and
> > to come and write drivers, utils and apps for it etc..
>
> That's the killer.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather (US & Canada) 800-55-FORTH
> FORTH Inc. +1 310-491-3356
> 5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
databases many times faster than unix/windows wow
I know you mentioned starting forth "not best" tutorial, what is best?
Elizabeth D Rather
...
>
> I know you mentioned starting forth "not best" tutorial, what is best?
Well, I have to mention my two books, "Forth Application Techniques"
(which is a real tutorial, with problem sets, for beginning Forthers)
and "Forth Programmer's Handbook", which is a more detailed reference
book. Handbook was extensively revised in summer 2007, and is pretty
up-to-date. The other is the book FORTH, Inc. uses for its Forth
courses. Both can be ordered through FORTH, Inc. or Amazon.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
Robert Spykerman
> gavino wrote:
..
>
> > I know you mentioned starting forth "not best" tutorial, what is best?
>
> Well, I have to mention my two books, "Forth Application Techniques"
> (which is a real tutorial, with problem sets, for beginning Forthers)
> and "Forth Programmer's Handbook", which is a more detailed reference
> book. Handbook was extensively revised in summer 2007, and is pretty
> up-to-date. The other is the book FORTH, Inc. uses for its Forth
> courses. Both can be ordered through FORTH, Inc. or Amazon.
>
> Cheers,
> Elizabeth
I can second this, Gavino. I'm still very much a forth noobie and I
think Elizabeth's books are excellent.
I also got both Brodie's books just out of interest, there is a lot of
obsolete material (ie blocks and editor stuff) in Starting Forth but
nevertheless it's a good read. Thinking Forth is good for food for
thought.
There's also Stephen Pelc's forth book, which is excellent and free to
download
http://www.mpeforth.com/arena.htm
And of course Julian Noble's stuff. May God grant him eternal peace.
Hopefully his tute will be archived for posterity.
http://www.forth.org/tutorials.html - you can find other stuff here
too.
His book Scientific Forth is still available I believe online.
The one thing I've noticed is that forth is very polymorphic, when I
mean this, I mean there is a lot of advanced code out there that is
just not seen in beginner tutes, you see all kinds of ways of doing
stuff.
I'm only just beginning to touch the tip of the iceberg. I would
probably still consider myself 6th, maybe 5th kyu LOL. ie a white belt
vs a dan grade.
In many ways it's a very TIMWTOTDI type of language. Or metalanguage.
And because of differing ways forths are implemented, I think it's
also unfortunately (or fortunately depending on how you look at it)
much like programming in assembly, if you're interested in the most
efficient solution you've got to know the compiler and the hardware
you're working with. But that's where the fun is IMHO.
Forth. It's a great way of spending time having fun. But I can see how
if you actually need a working solution quickly, other languages may
be more appropriate. I don't quite much care. I'm a hobbyist, you see.
And oh, Gavino, this day and age I would strongly suggest running a
hosted Forth. Preferably on a reasonably robust OS like a *nix. That
way when you F up as you will do many times (as I certainly have), you
only do it in userland, you can get back up very quickly.
For example, I accidentally fork bombed myself the other day while I
was fixing the OSX lina port. LOL. That was fun.
Robert