1. Re: euForth
- Posted by Peter Lawrence <peterl at NETLINK.COM.AU> Aug 28, 1999
- 301 views
>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.