1. Re: euForth

>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.

new topic     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu