Re: PeuForth
I think this thread should be renamed to "Peuforth", this seem to be an
appropriate
EPITAPH, for this thread.
In summary, proponents of PeuForth pupport that if:
1) there is a modern commercial
2) highly optimized
3) platform specific
implementation of forth that
4) doesn't thrash the disk with memory operations
5) inlines something
6) stack operations efficiently something else
It will be able to "convert" or compile Euphoria to more efficient Forth code.
Hmmmmmmmmm ........... so just how much of a benefit do you anticipate?
I have subscribed to this list for several years and I really can't remember any
one who left the list, abandoned Euphoria because it was too slow.
OK, so do it. Buy a commercial, modern, platfor specific, implementation of
Forth. Write a program to convert Euphoria to Forth. You now have code that
runs:
a) significantly faster %25
b) slightly faster %10
c) somewhat faster <%10
d) is really cute coz u made it work
Euphoria is not slow. Windowing, & GUI's, at least under Microsoft impose a
significant performance penalty it seems to me. Pete's Windoze editor seems to
drag in loading. But then is FORTH really gonna benefit this?
Wake up, smell the coffee. Quit distracting David Cuny from writing graphical
interfaces that are the best thing going for making Euphoria a mainstream
language.
Speaking of which, Linux is the future. I have recently dumped Windows for
Linux.
It is no joy ride for sure. But I can't shake the fact that the Linux
implementation of Euphoria is 100k less than DOS/Win. And it performs pretty
much
on par with the DOS/Win version despite being implemented on a free compiler.
WAKE UP, SMELL THE COFFEE!!!! Open source is the way to go. You can't compete
with MS holding God Knows How Many cards in the hole.
Hellooooooooooooooo!!!! Knock, Knock, Knock. Anybody there?
Hellooooooooooooooo?!!!!!!
FORTH is, I am sure, a very fine language. I have several books I will gladly
ship
to anyone who wants them for just a little above shipping cost.
Starting Forth, Leo Brodie
Thinking Forth, Leo Brodie
Forth, A Text and Reference... Kelly & Spies
Writing a Euphoria to FORTH converter / compiler may be an interesting exercise.
What is the pay off?
Ken Rhodes
krhodes at cybersouth.com
Peter Lawrence wrote:
> >Noah Smith wondered:
> >
> >> what is Forth, and why is there so much porting of it?
> >
> >Forth is a TIL - Threaded Interpreted Language. The Forth version of:
> >
> > function foo( integer x )
> > bar()
> > grill()
> > return x + 1
> > end function
> >
> >would look something like this (stuff in parenthesis are comments):
> >
> > : foo ( n - n ) bar grill +1 ;
> >
> >and compile to something like this:
> >
> >
> > [ call bar ] [ call grill ] [ call +1 ] [ return ]
>
> Only with a call threaded implentation - benchmarks have shown that direct
> threaded ones are both smaller and slightly faster (which I wouldn't have
> expected). They compile to something like this:
>
> [ bar ] [ grill ] [ +1 ] [ unnest ]
>
> .
> .
> .
>
> You may be a little out of date, so I'll qualify your remarks:-
>
> >The disadvantages of Forth include:
> >
> > - extensible = nonstandard
>
> True.
>
> > - rpn not humanly readable
>
> Depends on the human writing and the human reading - but irrelevant when
> Forth is only being used for intermediate data in a cascading Euphoria
> compiler.
>
> > - doesn't hide hardware from you
>
> See above for why irrelevant to Euphoria.
>
> > - easy to blow the stack
>
> See above for why irrelevant to Euphoria.
>
> > - text-only
>
> False - although many Forths are text only, and many with GUIs are only
> compatible at the text level, they have been used with GUIs for ages, for
> instance in the early development of pie menus. But see above for why
> irrelevant to Euphoria.
>
> > - 64K memory model
>
> False. Many early Forths were like this, but there have been 32 bit variants
> for a long time - and more recently the ANSI standard admits them.
>
> > - scaling is difficult
>
> See above for why irrelevant to Euphoria.
>
> > - stacks are inefficient
>
> False in general. (a) some platforms provide efficient stacks, and (b) some
> implementations map top of stack into registers. The commercial optimised
> Forths beat the inefficiencies of return addresses on stacks by inlining,
> and of data passing on stacks by doing the parts inside heavily used code
> (e.g. inner loops) via registers.
>
> > - threading is inefficient
>
> Depends - and see above for how to work around it. The main trade off is
> getting a quart into a pint pot; it used to be that a Fortran program might
> be theoretically more efficient than the Forth equivalent, except that it
> didn't run at all because it didn't fit.
>
> > - forth is the language, os and editor
>
> See above for why irrelevant to Euphoria.
>
> > - can do real clever stuff
>
> See above for why irrelevant to Euphoria.
>
> > - standards groups
>
> See above for why irrelevant to Euphoria.
>
> > - forward declarations are a pain (like Euphoria)
>
> See above for why irrelevant to Euphoria.
>
> > - not mainstream language
>
> I'd say that anyone using Euphoria is already investing in user groups for
> support for precisely this reason, so the investment of getting support for
> a cascader is already covered.
>
> > - crummy memory management
>
> Again, it depends on the implentation.
>
> >
> >There are a lot of parallels between Forth and Euphoria, and a Euphoria to
> >Forth converter might be a good match.
>
> Which is what made me think of it in the first place - that, and some
> familiarity with Forth. PML.
>
> >
> >-- David Cuny
> >
> >
> GST+NPT=JOBS
>
> I.e., a Goods and Services Tax (or almost any other broad based production
> tax), with a Negative Payroll Tax, promotes employment.
>
> See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
> items on that page for some reasons why.I
|
Not Categorized, Please Help
|
|
