Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #4464 > unrolled thread

Interesting article

Back to article view | Back to comp.lang.forth

Contents

  Interesting article Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-28 13:32 +0100
    Re: Interesting article anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-28 13:06 +0000
      Re: Interesting article Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-07-29 14:49 -0700
        Re: Interesting article Elizabeth D Rather <erather@forth.com> - 2011-07-29 19:32 -0500
          Re: Interesting article Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-08-02 16:27 -0700
        Re: Interesting article anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-30 11:41 +0000
          Re: Interesting article Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-08-02 16:38 -0700
          Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-02 17:47 -0700
            Re: Interesting article Peter Fälth <peter.falth@tin.it> - 2011-08-03 07:26 +0200
              Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-11 16:19 -0700
                Re: Interesting article Julian Fondren <ayrnieu@gmail.com> - 2011-08-11 22:57 -0500
                  Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-12 16:40 -0700
                    Re: Interesting article "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:59 -0400
                      Re: Interesting article Julian Fondren <ayrnieu@gmail.com> - 2011-08-14 13:13 -0500
                        Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-15 03:27 -0500
                          Re: Interesting article anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-16 17:49 +0000
                            Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-17 02:47 -0500
                      Re: Interesting article "Elizabeth D. Rather" <erather@forth.com> - 2011-08-14 08:28 -1000
                      Re: Interesting article Nomen Nescio <nobody@dizum.com> - 2011-08-14 20:41 +0200
                        Re: Interesting article Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 13:01 -0700
                      Re: Interesting article Richard Owlett <rowlett@pcnetinc.com> - 2011-08-14 14:14 -0500
                      Re: Interesting article kenney@cix.compulink.co.uk - 2011-08-14 21:05 -0500
                      Re: Interesting article BruceMcF <agila61@netscape.net> - 2011-08-14 22:23 -0700
                Re: Interesting article Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-13 12:29 -0700
                  Re: Interesting article "Elizabeth D. Rather" <erather@forth.com> - 2011-08-13 10:42 -1000
                  Re: Interesting article John Passaniti <john.passaniti@gmail.com> - 2011-08-13 13:50 -0700
                    Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-14 03:14 -0500
                    Re: Interesting article Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 02:12 -0700
                      Re: Interesting article John Passaniti <john.passaniti@gmail.com> - 2011-08-14 14:31 -0700
                  Re: Interesting article "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:58 -0400
      Re: Interesting article Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-29 19:18 -0700
        Re: Interesting article Julian Fondren <ayrnieu@gmail.com> - 2011-07-30 04:13 -0500
        Re: Interesting article Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-31 10:07 +0000
          Re: Interesting article mhx@iae.nl (Marcel Hendrix) - 2011-07-31 11:31 +0200
            Re: Interesting article Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-31 22:24 +0000
    Re: Interesting article Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-28 10:02 -0500

Page 2 of 2 — ← Prev page 1 [2]

#4895

Rod Pemberton wrote:
> "Hugh Aguilar"<hughaguilar96@yahoo.com>  wrote in message
> news:1f5417de-5702-4127-ac23-6c29f0e61695@t20g2000prf.googlegroups.com...
>>
>> I am old enough (45)

You youngster - got you beat by > 2 decades ;)

>> to remember a time when Forth was taken seriously
>> in the general programming world.
>>
>
> I'm old enough also.  Nobody knew of it.  Apparently, it was available for
> some of the home built computers, perhaps IMSAI or Altair.  AFAIK, Forth
> wasn't available for the personal home computers in the PC revolution such
> as C64's, Apple II's, Timex Sinclair's.  Byte magazine was were people heard
> of Forth.

*ERROR*
FORTH was essentially the OS for the Jupiter Ace - a 1st cousin of 
the TIMEX Sinclair (q.v. http://en.wikipedia.org/wiki/Jupiter_Ace )

I got a look at one when asked to do a review of it for someone 
considering importing it. My qualification (singular), I knew what 
FORTH was (can anyone say "Read BYTE"?) With 20/20 hindsight there's 
even a better chuckle. Where was I living? Rochester NY. I later 
purchased LMI FORTH and ran it on my S-100 system (Z80, CPM, 64k, 
2-8" floppies)

[toc] | [prev] | [next] | [standalone]

#4906

In article <j28kcu$d9n$1@speranza.aioe.org>, 
do_not_have@noavailemail.cmm (Rod Pemberton) wrote:

>  AFAIK, Forth
> wasn't available for the personal home computers in the PC revolution 
> such as C64's, Apple II's, Timex Sinclair's.

 The Jupiter Ace came with Forth in Rom. There were replacement roms 
available for the Sinclair models which implementated a multi tasking 
forth. Forth was available for the ST, HiSoft object Forth for example.

 It could well have been available for other home computers but those 
are just the cases I am personally aware off or have been told about. It 
was probably as common as any other language except Basic in the home 
market, I do not remember any 8 bit C compilers. 

 Ken Young

[toc] | [prev] | [next] | [standalone]

#4910

On Aug 14, 9:59 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> I'm old enough also.  Nobody knew of it.  Apparently, it was
> available for some of the home built computers, perhaps IMSAI or
> Altair.  AFAIK, Forth wasn't available for the personal home
> computers in the PC revolution such as C64's, Apple II's,
> Timex Sinclair's.  Byte magazine was were people heard of Forth.

The Commodore 64 was the computer where I got my first Forth system ~
I had a Timex Sinclair before that, which I must say was the most
closet compatible computer I ever owned.

Dr. Dobb's had regular Forth coverage.

> > In the late 1980s, ...

> In the late '80's, ...

This was in the early 80's, when more of the market was "learning
about computers".

[toc] | [prev] | [next] | [standalone]

#4835

On Aug 12, 12:19 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> The ANS-Forth standard is wishy-washy. It *allows* quite a lot, but it
> doesn't make any firm statement about anything. As another example,
> ANS-Forth allows the floating-point stack to be distinct from the
> parameter stack, but it doesn't require this. If you want your program
> to be ANS-Forth compliant, you have to assume the worst case, which is
> that floats are on the parameter stack. As another example, ANS-Forth
> allows the locals stack to be distinct from the return stack, but it
> doesn't require this. If you want your program to be ANS-Forth
> compliant, you have to assume the worst case, which is that locals are
> on the return stack. You can't use >R and R> in a function that uses
> locals, because this isn't going to work on every ANS-Forth compliant
> system. Apparently the ANS-Forth committee were so focused on
> supporting legacy code that they allowed both >R and R>, and locals,
> because both were commonly used --- but they didn't notice that the
> two were incompatible with each other!
>

I completely agree with Hugh's comments on this. Had things been
*mandated* then implementors would have had a clear, stationary
"target to aim at" and each Forth system would work exactly the same,
regardless of who wrote it. However, the reality is very different.
Therefore, in my mind, the "standard" is not a standard at all,
because adherence to it brings no guarantees. At best, it is a
"guideline", and that simply isn't good enough.

:-(

[toc] | [prev] | [next] | [standalone]

#4836

On 8/13/11 9:29 AM, Mark Wills wrote:
...
> I completely agree with Hugh's comments on this. Had things been
> *mandated* then implementors would have had a clear, stationary
> "target to aim at" and each Forth system would work exactly the same,
> regardless of who wrote it. However, the reality is very different.
> Therefore, in my mind, the "standard" is not a standard at all,
> because adherence to it brings no guarantees. At best, it is a
> "guideline", and that simply isn't good enough.
>
> :-(

With a new language, it is reasonable to mandate implementation details. 
For example, Guido van Rossum, Python's principal author, is considered 
by the Python community to be "Benevolent Dictator for Life".  When a 
language has been around for a while, developers of a standard need to 
avoid disenfranchising popular existing implementations.  There's also a 
considerable advantage in allowing implementers enough freedom to 
explore strategies that will allow the language to evolve in positive ways.

ANS Forth (and, in fact, most language standards) was never intended as 
an implementation guideline, but rather to define the *interface* 
between the implementation and the application.  So there are, in fact, 
significant guarantees to the application writer that programs written 
in Standard Forth will be portable across Standard Systems, providing 
any environmental dependencies the program has (e.g. presence of certain 
wordsets or cell size) are met.

The removal of restrictions on implementations in ANS Forth has allowed 
for optimizing code compilers and other improvements that have 
significantly benefited Forth as a useful tool.

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
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#4837

On Aug 13, 3:29 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> I completely agree with Hugh's comments on this.

All of Hugh's comments in this thread?  I mean if you want to hitch
yourself to his increasingly bizarre statements, that's fine.

> Had things been *mandated* then implementors would have had a
> clear, stationary "target to aim at" and each Forth system
> would work exactly the same, regardless of who wrote it.

Which also implies limits on innovation, and limits on targeting
architectures that don't meet the expectations of the standard.  This
isn't a problem for Hugh because he simply considers some platforms
(and apparently some problem domains) as irrelevant.  Given his
limited experience, limited interests, and limited tolerance for
learning from others, that's not surprising.

Seems to me the test of the value of ANS Forth isn't if Hugh can
portably implement questionable non-idiomatic programming techniques.
The test should be if other people implementing real-world systems can
have *reasonable* expectations of portability when they move their
code between targets.  Hard as it may be to believe, those of us who
derive a paycheck from our work as software developers aren't writing
programs to generate slide rules so that after civilization crashes
they can be exalted.  So the question of the ANS Forth's value-- at
least in terms of portability-- should be answered by those people who
have actual experience in porting code between targets.  Ask them if
the standard has value in their work.

I really don't understand where a lot of the more heated discussion
about ANS Forth comes from.  There has never been a gun held to
anyone's head to use it.  It has never prevented Charles Moore or
others (including some of the people in this newsgroup) from
implementing their own take on Forth.  There isn't a trademark symbol
after "Forth" that prevents anyone from calling their creation Forth.
If Hugh wants to create a new Forth based on what he thinks is find
and good, nobody is stopping him.  He and everyone else with their own
take on Forth is free to compete with ANS Forth and prove that their
solution is superior.  And if it turns out that real-world developers
actually are able to do better work with his Slide Rule Forth, then
great.

So my guess is that most of what causes the heated discussion about
ANS Forth is a psychological rigidity that is almost religious in
nature.  In exactly the same way that you see various fundamentalists
reject the notion that there can be more than one interpretation of
their faith, you see the same with some regarding Forth.  To them,
"Forth" must adhere to a purity test that unsurprisingly matches their
personal views.  And if it doesn't conform, then it must be attacked
(versus showing the real-world value of their flavor of Forth).

[toc] | [prev] | [next] | [standalone]

#4855

John Passaniti <john.passaniti@gmail.com> wrote:

> So my guess is that most of what causes the heated discussion about
> ANS Forth is a psychological rigidity that is almost religious in
> nature.  In exactly the same way that you see various
> fundamentalists reject the notion that there can be more than one
> interpretation of their faith, you see the same with some regarding
> Forth.  To them, "Forth" must adhere to a purity test that
> unsurprisingly matches their personal views.  And if it doesn't
> conform, then it must be attacked (versus showing the real-world
> value of their flavor of Forth).

There isn't anything particular to Forth about this: I see much of the
same kind of argument in comp.lang.c.

Andrew.

[toc] | [prev] | [next] | [standalone]

#4865

On Aug 13, 9:50 pm, John Passaniti <john.passan...@gmail.com> wrote:
> Which also implies limits on innovation, and limits on targeting
> architectures that don't meet the expectations of the standard.

Well John, I'm not an expert in the C language, and certainly not as
accomplished in the language as yourself, but I don't think I would be
far off the mark if I said that a C programmer, using the standardised
core C language, has a very high expectation of his code working
regardless of who's compiler he uses.  Unfortunately, that is just not
the case with C, and for the reasons cited by Hugh, which I agree
with; specifically, that in some aspects, the standard simply permits
too much freedom.

Regarding your comment on innovation, I essentially agree, though I
don't think it would wash in a professional programming shop, where
people are there to get the job done. They want the freedom to program
in a language and not be worried about breaking code if (for some
reason) management decide that company X's compilers are too expensive
and buy from company Y. Could this be one of the reasons for the lack
of Forth's traction in professional circles? The fact that, despite an
ANS standard, there are no guarantees?

Having said all of the above, I do recognise that being on the ANS
committee must be a very difficult, and probably frustrating job. It
is extremely difficult to satisfy everyone - vendors and users alike -
there's a lot of plates to keep spinning, and sooner or later, some
are bound to fall off!

Mark

[toc] | [prev] | [next] | [standalone]

#4899

On Aug 14, 5:12 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> Well John, I'm not an expert in the C language, and certainly
> not as accomplished in the language as yourself, but I don't
> think I would be far off the mark if I said that a C programmer,
> using the standardised core C language, has a very high
> expectation of his code working regardless of who's compiler he
> uses.  

It depends.  A C programmer can make choices that can have a dramatic
effect on portability and the language (and its standard) doesn't
protect you in the least.  And that's even more true when using C to
target the wild and wooly world of embedded systems.  Assumptions that
C programmers make on resource-rich desktop machines don't always hold
in the embedded world, usually for simple, pragmatic reasons.  In my
experience, portability of code starts not with a standard, but with
the developer.  An experienced developer knows the areas where
portability issues reside, and will either wrap that with an
abstraction or put in copious comments for future porting efforts.

> Unfortunately, that is just not the case with C, and for
> the reasons cited by Hugh, which I agree with; specifically,
> that in some aspects, the standard simply permits too much
> freedom.

I don't see that at all.  When I read the standard, I see two major
classes of such "freedom."

The first are freedoms granted because existing real-world Forth
systems made architectural decisions and the standard recognizes them
as valid approaches to implementing a Forth.  An example of this might
be the choice that a Forth vendor has between keeping the code as part
of the dictionary entry versus keeping it separate.  Both choices are
valid, but programs that make assumptions about how the dictionary is
organized are likely to have problems.  So one approach is to fixate
on a particular dictionary structure ensuring that people who want to
fiddle with the dictionary in their code can reliably do so.  But
making that decision is limiting, and it means that no innovation can
be made in that particular area.

The second are freedoms that are driven by the reality of the
underlying systems that Forths are implemented on.  And that can have
both dramatic and subtle effects on the Forth.  Want to lock down
things for portability?  Then what size should a CELL always be?  How
should data always be aligned?  Should the bits of numbers always be
big-endian or little-endian?  Are floating-point numbers always
available?  And it isn't just about hardware.  If the Forth runs on
top of an operating system, what services do we always assume that
operating system has, and how do we always get to them?

When I see a freedom that ANS Forth grants, I recognize that freedom
exists to address some real-world reality.  And it tells me that if
portability between different Forths is important to my application,
that I need to question if the code I'm writing that is exploiting
some implementation detail of the particular Forth I'm using is even
valid.  Maybe it is-- maybe exploiting that detail is necessary.  But
maybe it's just a convenience that can be accomplished in some other
more portable way.

> Regarding your comment on innovation, I essentially agree,
> though I don't think it would wash in a professional programming
> shop, where people are there to get the job done. They want the
> freedom to program in a language and not be worried about breaking
> code if (for some reason) management decide that company X's
> compilers are too expensive and buy from company Y. Could this be
> one of the reasons for the lack of Forth's traction in professional
> circles? The fact that, despite an ANS standard, there are no
> guarantees?

Again, I don't understand.  There *are* guarantees.  There is a set of
core words.  There are a set of optional extensions to those words.
There are semantics associated with those words.  And what is also
guaranteed is that if you're using a Forth that doesn't fully conform
to the guarantees in the standard, then that vendor has a
responsibility to document what doesn't conform.  What isn't
guaranteed are (as I wrote above) some esoteric implementation choices
in the Forth and some aspects of the underlying reality of the target
machine.

There are a variety of reasons why Forth doesn't have much traction in
"professional circles."  It seems ridiculous to assert that such
"professional circles" would suddenly rush to Forth if only the set of
guarantees that Hugh needs to implement questionable non-idiomatic
code existed.  Yeah, that's right-- Forth isn't used in web
programming because it lacks :NAME.  And Forth would be king in the
financial analysis if only developers could reliably fiddle with
internals of the language's implementation.

Your Occam's Razor appears to need some sharpening.  There are many
contributing factors to why Forth isn't widely used.  And probably the
biggest is that like most every other programming language, Forth is
great at some things and terrible at others.  Where Forth is strongest
is in the world of low-level direct control.  That means problem
domains like embedded systems are well served by Forth.  But other
problem domains... not so much.  You could come out with a Forth
standard that carefully guaranteed every possible detail about the
language.  And what you would have would be... Forth, a language that
still requires the developer to build up from scratch everything they
need.  Do you think that's going to compete with languages that come
with "batteries included"?

What developers outside the embedded systems world want is the ability
to focus their attention on the parts of their application that
matter.  Take a web developer for example-- they want a language (and
supporting libraries) that handle the uninteresting parts of the
application for them-- the "plumbing" in web applications.  They want
to put their effort on doing something special, not coming up with the
low-level routines to do BASE64 encoding, manage state, or dispatch
HTTP GET requests.  They want to get to the parts of the application
that matter.  They want to bring forward something new and innovative,
not in reinventing the same damn wheel.  And Forth has *never* been
that language.  It has nothing to do with "guarantees".  It has
everything to do with before you can use Forth, you need to invest
time and effort in creating the infrastructure you need.

Your homework assignment is to jump into a problem domain where you
don't see Forth.  Look at the languages commonly used in those problem
domains, and think about what those languages (and supporting
libraries) bring to the table-- what makes those languages stand out
for developers.  And after you do that, I want you to enumerate the
*specific* guarantees that Hugh thinks are important.  Do that, and
I'll make a guarantee-- that when you draw the Venn diagram of what
professional developers actually want and what Hugh wants to
guarantee, you'll have two non-intersecting circles.

[toc] | [prev] | [next] | [standalone]

#4874

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:ab439594-e2bd-422d-9eb1-d2b70637be98@gz5g2000vbb.googlegroups.com...
On Aug 12, 12:19 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> > The ANS-Forth standard is wishy-washy. It *allows* quite a lot, but it
> > doesn't make any firm statement about anything.
>
> I completely agree with Hugh's comments on this.
>

So do I, but AIR, I've argued that about C on numerous instances ...

Once a specification eliminates the underlying machine description, virtual
machine, requirements for assembly, etc then most spec implementors view the
spec as "portable".  However, the reality is that it means that many things
are host specific, i.e., non-standard across platforms or non-portable,
because *various methods cannot produce the same results*.  In the C camp,
the terms "undefined behavior", "unspecified", and "implementation-defined"
cover these areas, and those areas are the areas where C has it's real
power...  I.e., if it works in C, it's probably "undefined behavior",
"unspecified", "implementation-defined".  These are the areas of C that are
implemented differently on certain other ancient, obscure, obsolete, and
otherwise irrelevant platforms.  Those areas are commonly implemented in an
exact manner for near all post 1976 microprocessors since microprocessors
standardized on things like 8-bits bytes (ASCII), contiguous memory,
addressing, etc.  E.g., the C spec's allow "sign and magnitude" and "one's
complement" instead of "two's complement" arithmetic.  I can't think of any
platform I've personally used that didn't use two's complement.  AFAIR, they
all did.  E.g., pointer-to-integer conversions without loss are perfectly
acceptable on all microprocessors since they have the same integer size and
address size, but not every platform is "normal".


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#4493

On Jul 28, 7:06 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
> > Fromhttp://drdobbs.com/architecture-and-design/231002535
>
> [about language standardization in general]
>
> >So the language
> >gets no new lease on life and simply lives inside its original skin
> >getting progressively fatter, more complex, and dragged down by otiose
> >features."
>
> >The last sentence doesn't apply to Forth 200X - er does it?  :-)

Yes, very much so! The same people who screwed up Forth-79, Forth-83
and ANS-Forth, are now in charge of Forth-200x --- so what else would
you expect?

My impression of Forth-200x is that it will never get finished. It
started as Forth-200x, now it is Forth-201x, and it will still be
unfinished in the year 2020 and beyond. The reason is that everybody
knows that it will be a colossal failure, just like ANS-Forth in 1994;
they don't want to suffer the embarrassment of seeing it hit the
ground like a cow patty, so they avoid ever concluding the
standardization process and putting it on the ground. There is a fear
that if Forth-200x fails (is laughed at by the outside programming
world), then Forth itself will fail. People believe that so long as
the Forth-200x standardization process continues to putter forward,
Forth is still "alive" --- look! the dead walk!

It is similar to how Passaniti never posts any code because he is
afraid of getting laughed at --- the Forth-200x committee will never
post their standard as a finished product because they are afraid of
getting laughed at (a fear that is not unjustified!).

The Forth-200x committee continue to ramble on about "functional but
not inspiring changes" to ANS-Forth and they refuse to come to grips
with the fact that ANS-Forth failed miserably in the commercial world
allowing C to take over, and Forth-200x will also fail if it is seen
to be just "living in the same skin" as ANS-Forth. This is why
Forth-200x committee discussions revolve around things like N>R and
NR> that are trivial to implement and totally useless. We recently had
a discussion of how Forth-200x is going to support the Chinese
language, and this is despite the fact that none of us know Chinese.
It is all just nonsense --- the Forth-200x committee are killing time
making a show of progressing, without progressing at all. Every day
they figure out a new and different way to accomplish exactly nothing.

Ultimately, Forth-200x is cripple-ware. Gforth is intended to be a
stepping-stone into expensive commercial systems, and so Gforth (aka
Forth-200x) has purposeful gaps in the design --- the idea is that
Gforth will allow novices to get their feet wet, but as soon as the
novices learn enough about Forth to notice the gaps in the design,
they are encouraged to purchase SwiftForth or some other expensive
system sold by the Forth-200x committee members. This is why :NAME and
ALLOCATION were killed --- because these allow the user to do some
basic OOP-like programming (inheritance, anyway) --- the users never
need to spend the money on a non-standard commercial system to get OOP-
like facilities (SWOOP).
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/17b778f7496e945a/
In the above thread, I discussed how :NAME can be used to associate
more than one action to a data type. Ron Aaron suggested the idea of
using CREATE DOES> with its one action, and manually building a VMT in
front of the data with the DOES> code choosing between actions
according to a message sent to it as a parameter at run-time.
Elizabeth Rather enthusiastically supported this idea. It is all
nonsense though; this plan is horribly complicated and slow compared
to what I am doing. These kinds of complicated and slow solutions are
supported by the Forth-200x committee because they want Forth-200x to
be complicated and slow --- so people will feel the need to upgrade to
an expensive commercial system. The Forth-200x committee will never
accept simple and efficient solutions such as I'm proposing ---
Forth-200x is cripple-ware!

> Anyway, if the result of the standardization process is too fat,
> complex, and the standarized features are useless, people will stick
> to the old standard or flock to slimmer, simpler, non-standard
> systems; maybe machineForth, maybe Reva, HelForth, or RetroForth.  Or
> maybe to a system like Factor that offers features that will never
> make it into standard Forth.

You are assuming that the standardization process primarily involves
adding new features to the language, and making the language fatter.
This isn't true. When I eventually come out with my competing
standard, the primary difference from Forth-200x will be at a
fundamental level. My system will inherently be a cross-compiler; the
user is always cross-compiling with distinct HOST and TARG
dictionaries, even if his host and target machines are actually one
and the same. One purpose of this is so code can be easily ported
between such disparate targets as micro-controllers and desktop
computers, because you always have the same HOST and TARG distinction
in your application code. Another purpose of this is to solve the
problem in ANS-Forth in which it is unclear if words are supposed to
be executing at compile-time or run-time --- every word will have two
versions with distinct xt values, one in HOST that executes at compile-
time and one in TARG that executes at run-time. This is a very
fundamental (maybe even inspiring!) change from ANS-Forth.

I will also have functional upgrades, such as having a D/ word, but
the big change will be at the fundamental level as described above. I
don't expect to be much fatter than ANS-Forth, and I may even be
thinner. I will have extensions such as a string library, but these
are optional extensions so they don't count as fat. My standard will
be more complicated because it is a cross-compiler rather than a stand-
alone system, but this will make application programming *less*
complicated. From the application programmer's point of view, my
standard will be simpler. From the compiler writer's point of view, my
standard will be more complicated, but they can live with that ---
compiler-writers claim to be mighty smart, so they forfeit the option
of complaining about complexity!

I think that you can forget about Reva becoming the new standard.
Considering that Ron Aaron refers to the Arabs as "beasts," we can
rule out Reva being accepted anywhere that Arabs live (which includes
America, and pretty much every nation in the world except Israel).
Nobody wants to associate with a bigot!

I don't know enough about the other Forth systems that you mentioned
to comment on them. Most Forth systems are pretty uninspiring though.
They are not different from ANS-Forth on a fundamental level, as mine
will be. A lot of them (such as CIforth) started out life as FIG
implementations from one of those green-cover books, and nothing has
changed since that time except that they became bloated. They are not
cross-compilers --- they just run on whatever processor they run on,
with both compile-time and run-time code being executed on that
processor.

> Then people want to have this system in other environments and
> implement something like it, and they want to port between these
> systems, and for that they need another standard.  The cycle starts
> again.

If the standard is inherently a cross-compiler, then there is a
standard path to implementing on new systems.

> I don't know how the numbers of users of standard vs. non-standard
> Forth systems develops, but I don't have the impression that there is
> a significant movement away from standard to non-standard systems
> because of the fat acquired through the standard.

The problem is not the fat --- the problem is the fundamental bad
design of ANS-Forth (the compile-time and run-time code are just
jumbled together willy-nilly and without any distinction).

P.S. Anton --- What did you think of my EXECUTE-PARSING code?
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/46a1fb9b3ca2ff7f#
Did it suck? Or did you not have anything to say just because you knew
that Leon Wagner would never allow EXECUTE-PARSING or :NAME or
anything like that to be included in the standard no matter how they
are implemented, so discussion of such code is pointless anyway.

[toc] | [prev] | [next] | [standalone]

#4498

Hugh Aguilar <hughaguilar96@yahoo.com> writes:

> On Jul 28, 7:06 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>> > Fromhttp://drdobbs.com/architecture-and-design/231002535
>>
>> [about language standardization in general]
>>
>> >So the language
>> >gets no new lease on life and simply lives inside its original skin
>> >getting progressively fatter, more complex, and dragged down by otiose
>> >features."
>>
>> >The last sentence doesn't apply to Forth 200X - er does it?  :-)
>
> Yes, very much so! The same people who screwed up Forth-79, Forth-83
> and ANS-Forth, are now in charge of Forth-200x --- so what else would
> you expect?

Apart from how true or false this or your subsequent comments are,
what's your aim in making them?  These comments are so venomous, it's
like you're gloating.  "They wouldn't listen!  I told them but they
wouldn't listen! And now, FORTH WILL BURN."   This stuff wastes
your time, wearies your audience, and - to the extent that anyone puts
any faith in your account - just tells onlookers to stay far away from
this ship.

> We recently had
> a discussion of how Forth-200x is going to support the Chinese
> language, and this is despite the fact that none of us know Chinese.

我會讀中文

I still need to wake my Zaurus up so that I can copy my Chinese-study
program from it.  It's written in Forth, deals with BIG5 and GB2312
(16-bit characters), has a pinyin input method that displays characters
matching e.g. du2 and lets you select the appropriate character with the
arrow keys.  It's a great little system, and it got a lot of use after I
altered nethack a teensy bit (about to die?  No worries, I'll just study
Chinese for a bit and... there.  Full health, full belly!  Just like in
real life!)

> This is why :NAME and
> ALLOCATION were killed --- because these allow the user to do some
> basic OOP-like programming (inheritance, anyway) --- the users never
> need to spend the money on a non-standard commercial system to get OOP-
> like facilities (SWOOP).

gforth comes with _three_ OOP packages.  SwiftForth isn't a non-standard
system.  SWOOP apparently can't be ANS, but look at the portability
layer for VFX Forth in the package at FLAG:

   http://soton.mpeforth.com/flag/swoop/swoop.zip

When you proposed :NAME and ALLOCATION , you got some responses.  Your
attempt at telepathically divining the secret motivations behind these
responses has led you to the really super wrong and bizarre quote above,
so please try taking those responses at face value, instead.

Or rather, if gforth were an evil plot to deprive amateurs of OO and
:NAME and ALLOCATION , you could foil this plot as directly as putting
up a webpage that tells people how to install gforth and also your own
provisions of OO and :NAME and ALLOCATION .  You accomplish absolutely
nothing when you point out the conspiracy on c.l.f, but you frustrate
the sinister aims of the conspirators just by being a little bit
productive.

> When I eventually come out with my competing
> standard, the primary difference from Forth-200x will be at a
> fundamental level. My system will inherently be a cross-compiler; the
> user is always cross-compiling with distinct HOST and TARG
> dictionaries, even if his host and target machines are actually one
> and the same. One purpose of this is so code can be easily ported
> between such disparate targets as micro-controllers and desktop
> computers, because you always have the same HOST and TARG distinction
> in your application code. Another purpose of this is to solve the
> problem in ANS-Forth in which it is unclear if words are supposed to
> be executing at compile-time or run-time --- every word will have two
> versions with distinct xt values, one in HOST that executes at compile-
> time and one in TARG that executes at run-time. This is a very
> fundamental (maybe even inspiring!) change from ANS-Forth.
>
> I will also have functional upgrades, such as having a D/ word, but
> the big change will be at the fundamental level as described above. I
> don't expect to be much fatter than ANS-Forth, and I may even be
> thinner. I will have extensions such as a string library, but these
> are optional extensions so they don't count as fat. My standard will
> be more complicated because it is a cross-compiler rather than a stand-
> alone system, but this will make application programming *less*
> complicated. From the application programmer's point of view, my
> standard will be simpler. From the compiler writer's point of view, my
> standard will be more complicated, but they can live with that ---
> compiler-writers claim to be mighty smart, so they forfeit the option
> of complaining about complexity!

... or you can write Yet Another Incompatible Forth.  There should be a
"Friends Don't Let Friends" poster about that.

Ah, well.

[toc] | [prev] | [next] | [standalone]

#4507

In article <945a6782-257c-46ec-8928-f4de59b5b15a@d8g2000prf.googlegroups.com>,
Hugh Aguilar  <hughaguilar96@yahoo.com> wrote:
<SNIP>
>
>I don't know enough about the other Forth systems that you mentioned
>to comment on them. Most Forth systems are pretty uninspiring though.
>They are not different from ANS-Forth on a fundamental level, as mine
>will be. A lot of them (such as CIforth) started out life as FIG
>implementations from one of those green-cover books, and nothing has
>changed since that time except that they became bloated. They are not
>cross-compilers --- they just run on whatever processor they run on,
>with both compile-time and run-time code being executed on that
>processor.

I have no quarrel with ciforth being uninspiring.

Nobody ever said it was bloated, so I did some soul-searching.
Let's see how may words there were in figforth:
"
co -p -r1.1 ci86.gnr | grep "DB *'" |grep 80H | wc -w
211
"
and in lina
"
echo WORDS |lina | wc -w
355
"
Not incidentally this number has remained the same going from
version 4 to 5:
echo WORDS |/usr/bin/lina | wc -w
355

Indeed, it is discouraging to see how this went up by 75%, but
those 144 extra words get you:
1. file access, notably INCLUDED
2. exposed internals of headers
3. exposed factoring of interpreting/compiling
4. catch/throw based error mechanism
5. comprehensive operating system access.
6. ministring package
7. all CORE words

In combination with a library mechanism this appears to be sufficient
for some non-trivial programming, like ciasdis.
I find it hard to imagine cutting fat, but I'm all ears about
simplification proposals. FIND and WORD wouldn't be missed (by me),
but that is about it.

(And no, I don't have D/ , I don't have D- ).

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#4509

Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: Interesting article
[..]
> Nobody ever said it was bloated, so I did some soul-searching.
[..]
> Indeed, it is discouraging to see how this went up by 75%, but
> those 144 extra words get you:
> 1. file access, notably INCLUDED
> 2. exposed internals of headers
> 3. exposed factoring of interpreting/compiling
> 4. catch/throw based error mechanism
> 5. comprehensive operating system access.
> 6. ministring package
> 7. all CORE words

> In combination with a library mechanism this appears to be sufficient
> for some non-trivial programming, like ciasdis.
> I find it hard to imagine cutting fat, 
[..]

AFAIK your library mechanism is build on BLOCK, so obviously
1, 2, 4, 5, 6 and a large part of 7 could be a loadable option/extension.

The problem is ill-defined. What application of ciforth is hampered by
the fact that it is so large? What applications of ciforth are hampered by the
fact that users have to write basic stuff before they can get on with
currently popular programming problems?

There is something to be said for a system that easily fits in one's head,
but why is it better to memorize the (tremendously powerful) ABC but not 
TAOCP?

With current hardware (*), compiling iForth from scratch for a specific processor 
and OS takes about 400 ms. (4 of 5 passes are for optimizing size and could 
be disabled):

( from sym.tab )
  *** SYMBOL TABLE ***
  92043 lines processed.
  META time: 2.121 seconds.
  Generated: 00:27:26, June 27, 2011

It would therefore not really be unpractical to have a word-by-word customized Forth 
for any conceivable problem. (Or a Forth that simply recompiles and optimizes 
itself after each <CR> pressed by the user :-)

-marcel

BTW: On the same hardware, the C-based NGSPICE project I'm currently working on 
takes 45 minutes to recompile.

[toc] | [prev] | [next] | [standalone]

#4516

In article <04049204968436@frunobulax.edu>, Marcel Hendrix <mhx@iae.nl> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes Re: Interesting article
>[..]
>> Nobody ever said it was bloated, so I did some soul-searching.
>[..]
>> Indeed, it is discouraging to see how this went up by 75%, but
>> those 144 extra words get you:
>> 1. file access, notably INCLUDED
>> 2. exposed internals of headers
>> 3. exposed factoring of interpreting/compiling
>> 4. catch/throw based error mechanism
>> 5. comprehensive operating system access.
>> 6. ministring package
>> 7. all CORE words
>
>> In combination with a library mechanism this appears to be sufficient
>> for some non-trivial programming, like ciasdis.
>> I find it hard to imagine cutting fat,
>[..]
>
>AFAIK your library mechanism is build on BLOCK, so obviously
>1, 2, 4, 5, 6 and a large part of 7 could be a loadable option/extension.

It is a tightly integrated bunch, so no.

The internals of headers are defined by H_OFFSET etc in the generic
source. If I interchange two lines the order of the fields in a header
are interchanged for all versions of ciforth. It is silly to put
that in blocks and have a synchronisation problem.

The error mechanism is so basic that putting CATCH/THROW in blocks
would be a major rewrite resulting in an inferior system.
Etc.etc.

The lab mechanism is in block 1, so if you don't want to use the
library, it is not loaded.

>
>The problem is ill-defined. What application of ciforth is hampered by
>the fact that it is so large? What applications of ciforth are hampered by the
>fact that users have to write basic stuff before they can get on with
>currently popular programming problems?

It is not too large, I think. There is one user (me) and I write a
new kind of array for each Euler problem and don't feel hampered.

>There is something to be said for a system that easily fits in one's head,
>but why is it better to memorize the (tremendously powerful) ABC but not
>TAOCP?
>
>With current hardware (*), compiling iForth from scratch for a specific processor
>and OS takes about 400 ms. (4 of 5 passes are for optimizing size and could
>be disabled):
>
>( from sym.tab )
>  *** SYMBOL TABLE ***
>  92043 lines processed.
>  META time: 2.121 seconds.
>  Generated: 00:27:26, June 27, 2011
>
>It would therefore not really be unpractical to have a word-by-word customized Forth
>for any conceivable problem. (Or a Forth that simply recompiles and optimizes
>itself after each <CR> pressed by the user :-)

As long as the recompilation system is simple.
The only way I have found that I really like is :
You want GET-ENV ?
Type
WANT GET-ENV

So I made ciforth that way.

>
>-marcel
>
>BTW: On the same hardware, the C-based NGSPICE project I'm currently working on
>takes 45 minutes to recompile.

The better part of my week went by integrating the command
        asm11 tcp.asm
into Eclipse ..

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#4467

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> From http://drdobbs.com/architecture-and-design/231002535
> 
> "It is hard to argue that C (and separately, C++) have become more
> vital since control of their design passed from the original
> creators to committees. Likewise, Java since it migrated from the
> original design group to the JCP process. Language extension by
> committee roll call tends to result in functional but not inspiring
> changes. So the language gets no new lease on life and simply lives
> inside its original skin getting progressively fatter, more complex,
> and dragged down by otiose features."
> 
> The last sentence doesn't apply to Forth 200X - er does it?  :-)

Of course it does, and that's inevitable.  Nice names like VOCABULARY
and FIND get changed to names like SEARCH-COMPILING, for example.  The
same thing happens to every language that doesn't die!

Andrew.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web