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

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

Re: Cross Platform Development

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Cross Platform Development rickman <gnuarm@gmail.com> - 2015-04-26 09:25 -0400
    Re: Cross Platform Development Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-26 19:43 +0000
      Re: Cross Platform Development rickman <gnuarm@gmail.com> - 2015-04-26 21:30 -0400
        Re: Cross Platform Development Steve Graham <jsgrahamus@yahoo.com> - 2015-04-28 15:16 -0700
      Re: Cross Platform Development hughaguilar96@gmail.com - 2015-04-26 19:46 -0700
      Re: Cross Platform Development "Elizabeth D. Rather" <erather@forth.com> - 2015-04-26 22:23 -1000
        Re: Cross Platform Development Steve Graham <jsgrahamus@yahoo.com> - 2015-04-28 15:12 -0700
          Re: Cross Platform Development The Natural Philosopher <tnp@invalid.invalid> - 2015-04-29 05:23 +0100
            Re: Cross Platform Development rickman <gnuarm@gmail.com> - 2015-04-29 13:34 -0400
              Re: Cross Platform Development Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-29 19:31 +0000
                Re: Cross Platform Development rickman <gnuarm@gmail.com> - 2015-04-29 15:43 -0400
                  Re: Cross Platform Development Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-29 20:07 +0000
                    Re: Cross Platform Development rickman <gnuarm@gmail.com> - 2015-04-29 18:49 -0400
                Re: Cross Platform Development Mike Fleming <{mike}@tauzero.co.uk> - 2015-05-01 18:23 +0100
                  Re: Cross Platform Development Michael J. Mahon <mjmahon@aol.com> - 2015-05-02 02:35 -0500
                  Re: Cross Platform Development Gordon Henderson <gordon+usenet@drogon.net> - 2015-05-02 10:08 +0000
    Re: Cross Platform Development The Natural Philosopher <tnp@invalid.invalid> - 2015-04-27 09:31 +0100

#38611 — Re: Cross Platform Development

On 4/25/2015 6:05 PM, Martin Gregorie wrote:
> On Sat, 25 Apr 2015 17:01:13 -0400, rickman wrote:
>
>> I believe you are confusing just what "interpreted" means in the context
>> of Forth.  Even if they "interpret" some portion of the system code, it
>> is usually compiled into a binary file which is loaded when the system
>> is run.  I don't know of *any* forths which were compiled from some
>> minimal assembler at load time rather than installation time.
>>
> I must respectfully disagree: I was messing about with a version of Forth
> that ran on a 6809 box under Flex09. I had all the source for this Forth
> and vividly remember that there was almost no compiled code in it - and
> that part of it was all assembler. This was code included the low level
> assembler words plus the jump into the initial word low-level word.
> Everything else was a file containing Forth source and was pulled in by
> the assembler words and prepared for use before it put up the initial
> user prompt. This set-up was traditional enough Forth to avoid the use of
> the FLEX filing system: all data and code 'screens' lived in a single
> random file containing numbered 1K chunks known as 'screens'. A 'screen'
> was 16 lines of 64 characters (1 kB). User written source code lived in
> this screenstore - it had do because the editor would only operate on one
> screen at a time and had no means of accessing normal Flex files.
>
> I don't remember how the system code was stored but it could well have
> been another of these Forth random access screen file: it would be
> logical to do it that way.
>
> Don't forget that Forth was developed to run on very low powered kit:
> IIRC something like a DEC PDP8 and much of it came out of the astronomy
> community.

You may have found a forth that didn't have much compiled code, which is 
not impractical since Forth generally compiles very quickly compared to 
other languages.  But I was disagreeing with this statement, 
"Traditional Forths didn't have a compiled form".  I think if you look 
around at Forths from any period you will find very few that are not 
compiled with only the user code loaded at run time.


>> I am not proficient at any software language at this time.  I used to
>> know C pretty well, but that is being pushed out by C++.  Since I don't
>> have much of a language bias I find most C code to be pretty much as
>> write-only as Forth.
>>
> I prefer ANSI C to C++, which I find hopelessly baroque and far too full
> of 'features'. Some support from this view comes from the point that any
> of the "C++" programs I've run into have been little more than ANSI C
> with added // comments and using cin and cout for I/O rather than C's
> stdio functions.
>
>> I find Forth to be extremely productive when interfacing to hardware
>> which is *my* area of expertise.  I produce boards and use Forth to
>> program the test fixtures.
>>
> Given its background that isn't all that surprising: I believe the
> astronomers used it to control telescopes of various types.

Funny how small aspects of something stand out and are remembered. 
Forth was invented by Charles Moore who was developing code to control 
telescopes.  Since then it has done many, many other things.  It has two 
main attributes in my opinion.  One is the interactivity when 
controlling hardware which is actually useful for many, many non-control 
apps as it facilitates testing.  The other is the flexibility as the 
language is easily extensible and allows the developer to create a 
"custom" language to suit the application.

-- 

Rick

[toc] | [next] | [standalone]

#38618

On Sun, 26 Apr 2015 09:25:37 -0400, rickman wrote:

> You may have found a forth that didn't have much compiled code, which is
> not impractical since Forth generally compiles very quickly compared to
> other languages.  But I was disagreeing with this statement,
> "Traditional Forths didn't have a compiled form".  I think if you look
> around at Forths from any period you will find very few that are not
> compiled with only the user code loaded at run time.
>
They might have had the ability to save state in a loadable form.
I can only quote (which is what I was doing from what I remember reading 
at the time (late 70s/early 80s).
  
> Funny how small aspects of something stand out and are remembered. Forth
> was invented by Charles Moore who was developing code to control
> telescopes.  Since then it has done many, many other things.  It has two
> main attributes in my opinion.  One is the interactivity when
> controlling hardware which is actually useful for many, many non-control
> apps as it facilitates testing.  The other is the flexibility as the
> language is easily extensible and allows the developer to create a
> "custom" language to suit the application.
>
Noted.

There were a number of odd/specialised languages around at the time which 
are not much used now and many of them had similar development 
characteristics and the ability to run on small, slow machines. 

MUMPS, anybody?


FWIW what attracted me to Forth in the first place is its RPN notiaion: 
I'm a huge fan of HP calculators and have an operating HP-21 on my desk 
at the moment - I bought it new in 1976. New batteries, of course, but 
the rest is original.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#38625

On 4/26/2015 3:43 PM, Martin Gregorie wrote:
> On Sun, 26 Apr 2015 09:25:37 -0400, rickman wrote:
>
>> You may have found a forth that didn't have much compiled code, which is
>> not impractical since Forth generally compiles very quickly compared to
>> other languages.  But I was disagreeing with this statement,
>> "Traditional Forths didn't have a compiled form".  I think if you look
>> around at Forths from any period you will find very few that are not
>> compiled with only the user code loaded at run time.
>>
> They might have had the ability to save state in a loadable form.
> I can only quote (which is what I was doing from what I remember reading
> at the time (late 70s/early 80s).
>
>> Funny how small aspects of something stand out and are remembered. Forth
>> was invented by Charles Moore who was developing code to control
>> telescopes.  Since then it has done many, many other things.  It has two
>> main attributes in my opinion.  One is the interactivity when
>> controlling hardware which is actually useful for many, many non-control
>> apps as it facilitates testing.  The other is the flexibility as the
>> language is easily extensible and allows the developer to create a
>> "custom" language to suit the application.
>>
> Noted.
>
> There were a number of odd/specialised languages around at the time which
> are not much used now and many of them had similar development
> characteristics and the ability to run on small, slow machines.
>
> MUMPS, anybody?

Lol!  I dated a gal who knew MUMPS and loved it.  She works for a 
medical testing lab and they use it in a lot of their internal systems.


> FWIW what attracted me to Forth in the first place is its RPN notiaion:
> I'm a huge fan of HP calculators and have an operating HP-21 on my desk
> at the moment - I bought it new in 1976. New batteries, of course, but
> the rest is original.

Yeah, I liked them too.  I even managed to find an inexpensive alternate 
RPN calculator once, but it didn't hold up like HPs did.  So now my only 
calculator is Excalibur for the PC which is RPN with some nice features. 
  It's not open source so I can't make any improvements myself.  But if 
you have forth, you can pretty easily roll your own.  I also use 
Win32Forth and there is a UI package for it which I have not explored yet.

-- 

Rick

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

#38699

rickman wrote:
> On 4/26/2015 3:43 PM, Martin Gregorie wrote:
>> On Sun, 26 Apr 2015 09:25:37 -0400, rickman wrote:
>>
>>> You may have found a forth that didn't have much compiled code, which is
>>> not impractical since Forth generally compiles very quickly compared to
>>> other languages.  But I was disagreeing with this statement,
>>> "Traditional Forths didn't have a compiled form".  I think if you look
>>> around at Forths from any period you will find very few that are not
>>> compiled with only the user code loaded at run time.
>>>
>> They might have had the ability to save state in a loadable form.
>> I can only quote (which is what I was doing from what I remember reading
>> at the time (late 70s/early 80s).
>>
>>> Funny how small aspects of something stand out and are remembered. Forth
>>> was invented by Charles Moore who was developing code to control
>>> telescopes.  Since then it has done many, many other things.  It has two
>>> main attributes in my opinion.  One is the interactivity when
>>> controlling hardware which is actually useful for many, many non-control
>>> apps as it facilitates testing.  The other is the flexibility as the
>>> language is easily extensible and allows the developer to create a
>>> "custom" language to suit the application.
>>>
>> Noted.
>>
>> There were a number of odd/specialised languages around at the time which
>> are not much used now and many of them had similar development
>> characteristics and the ability to run on small, slow machines.
>>
>> MUMPS, anybody?
>
> Lol!  I dated a gal who knew MUMPS and loved it.  She works for a
> medical testing lab and they use it in a lot of their internal systems.
>
>

MUMPS is still the primary language used at the Veterans Administration 
healthcare systems, which I believe is the largest such system in the world.

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

#38628

On Sunday, April 26, 2015 at 12:44:52 PM UTC-7, Martin Gregorie wrote:
> FWIW what attracted me to Forth in the first place is its RPN notiaion: 
> I'm a huge fan of HP calculators and have an operating HP-21 on my desk 
> at the moment - I bought it new in 1976. New batteries, of course, but 
> the rest is original.

There is the "6502 Group" in Denver. The name is nostalgic; they actually use the PIC18 or PIC24 for most of what they do.

They built an HP-48 using a PIC18 running a simulator for whatever chip was in the HP-48 originally, and it runs faster than the original HP-48 does (not surprising, as the HP-48 was awfully slow even in its own time).

As you are such a fan of HP calculators, you might be interested in their HP-48 clone. I don't know much about the HP-21, but I think it was pretty primitive compared to the HP-48 --- the HP-48 had quite a following in its day (I have one).

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

#38639

On 4/26/15 9:43 AM, Martin Gregorie wrote:
> On Sun, 26 Apr 2015 09:25:37 -0400, rickman wrote:
>
>> You may have found a forth that didn't have much compiled code, which is
>> not impractical since Forth generally compiles very quickly compared to
>> other languages.  But I was disagreeing with this statement,
>> "Traditional Forths didn't have a compiled form".  I think if you look
>> around at Forths from any period you will find very few that are not
>> compiled with only the user code loaded at run time.
>>
> They might have had the ability to save state in a loadable form.
> I can only quote (which is what I was doing from what I remember reading
> at the time (late 70s/early 80s).

All the Forths I ever worked on had a binary kernel, written in Forth 
and Forth assembler, that was cross-compiled by another Forth for the 
new target. Until the 80's, Chuck insisted in it being only 2K, and the 
rest of the system was compiled from source by that kernel. It was fast 
enough (a few seconds) that it wasn't worth compiling more.

In the 80's, with polyFORTH, we went to an 8K kernel and compiled 
everything else. Nowadays the precompiled kernel a good deal larger, but 
still a lot of the system is compiled at boot time. If the time it takes 
is not perceptable (under 1 sec.) the flexibility you gain by having a 
lot in source is a good thing.

>> Funny how small aspects of something stand out and are remembered. Forth
>> was invented by Charles Moore who was developing code to control
>> telescopes.  Since then it has done many, many other things.  It has two
>> main attributes in my opinion.  One is the interactivity when
>> controlling hardware which is actually useful for many, many non-control
>> apps as it facilitates testing.  The other is the flexibility as the
>> language is easily extensible and allows the developer to create a
>> "custom" language to suit the application.

Well said.

> There were a number of odd/specialised languages around at the time which
> are not much used now and many of them had similar development
> characteristics and the ability to run on small, slow machines.
>
> MUMPS, anybody?

MUMPS was unbelievably slow, even on fairly fast machines. Interactivity 
was its own advantage.

> FWIW what attracted me to Forth in the first place is its RPN notiaion:
> I'm a huge fan of HP calculators and have an operating HP-21 on my desk
> at the moment - I bought it new in 1976. New batteries, of course, but
> the rest is original.

:-)

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]

#38698

Elizabeth D. Rather wrote:
...

>
>> There were a number of odd/specialised languages around at the time which
>> are not much used now and many of them had similar development
>> characteristics and the ability to run on small, slow machines.
>>
>> MUMPS, anybody?
>
> MUMPS was unbelievably slow, even on fairly fast machines. Interactivity
> was its own advantage.
>

MUMPS is a lot like Forth in one aspect:  Both were able to create 
multi-user systems out of low-powered CPU's (Z80 for Forth (?) and 80286 
for MUMPS).  And when 386's and 486's appeared on the scene, these 
physically small machines took over the duties formerly relegated to 
much larger mini-computers.  As has been said of Forth in another 
thread, MUMPS was able to eek out a lot more performance from the same 
system than other languages could.

Steve

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

#38708

On 28/04/15 23:12, Steve Graham wrote:
> Elizabeth D. Rather wrote:
> ...
>
>>
>>> There were a number of odd/specialised languages around at the time
>>> which
>>> are not much used now and many of them had similar development
>>> characteristics and the ability to run on small, slow machines.
>>>
>>> MUMPS, anybody?
>>
>> MUMPS was unbelievably slow, even on fairly fast machines. Interactivity
>> was its own advantage.
>>
>
> MUMPS is a lot like Forth in one aspect:  Both were able to create
> multi-user systems out of low-powered CPU's (Z80 for Forth (?) and 80286
> for MUMPS).  And when 386's and 486's appeared on the scene, these
> physically small machines took over the duties formerly relegated to
> much larger mini-computers.  As has been said of Forth in another
> thread, MUMPS was able to eek out a lot more performance from the same
> system than other languages could.
>
> Steve
>
Your version of history is interesting, but appears to be unique.

MUMPS was a minicomputer  language developed in the 60s. Specifically 
for medical use.

Looking at the wiki entry reveals its more akin to a super COBOL than 
anything else.


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

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

#38714

On 4/29/2015 12:23 AM, The Natural Philosopher wrote:
> On 28/04/15 23:12, Steve Graham wrote:
>> Elizabeth D. Rather wrote:
>> ...
>>
>>>
>>>> There were a number of odd/specialised languages around at the time
>>>> which
>>>> are not much used now and many of them had similar development
>>>> characteristics and the ability to run on small, slow machines.
>>>>
>>>> MUMPS, anybody?
>>>
>>> MUMPS was unbelievably slow, even on fairly fast machines. Interactivity
>>> was its own advantage.
>>>
>>
>> MUMPS is a lot like Forth in one aspect:  Both were able to create
>> multi-user systems out of low-powered CPU's (Z80 for Forth (?) and 80286
>> for MUMPS).  And when 386's and 486's appeared on the scene, these
>> physically small machines took over the duties formerly relegated to
>> much larger mini-computers.  As has been said of Forth in another
>> thread, MUMPS was able to eek out a lot more performance from the same
>> system than other languages could.
>>
>> Steve
>>
> Your version of history is interesting, but appears to be unique.
>
> MUMPS was a minicomputer  language developed in the 60s. Specifically
> for medical use.
>
> Looking at the wiki entry reveals its more akin to a super COBOL than
> anything else.

You got all that from the wikipedia page?  You seem to read selectively. 
  It was developed in a medical environment but the applications are 
much more varied because the language is not specific to the medical 
community in any way.  Did you read that Ameritrade uses it to handle 12 
billion transactions per day?  Seems to do well for a language from the 
60's, no?

Is "super COBOL" a good thing or a bad thing?

-- 

Rick

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

#38716

On Wed, 29 Apr 2015 13:34:02 -0400, rickman wrote:

> You got all that from the wikipedia page?  You seem to read selectively.
> 
Of course he did. The first line of the article says:

MUMPS (Massachusetts General Hospital Utility Multi-Programming System)...

> Is "super COBOL" a good thing or a bad thing?
>
I wouldn't say so: its far too terse to ever be that. I mean, you can 
write 'Hello World' in a single line in it, but in COBOL it would be 
something like this at its shortest:

ENVIRONMENT DIVISION.
PROGRAM-ID.  hello_world.
PROCEDURE DIVISION.
PARA-1.
    DISPLAY "Hello, World".
    STOP RUN.

... untested: I don't have a COBOL compiler to hand and its been a while, 
but I'd be surprised if even a modern compiler would accept a program 
without both environment and procedure divisions being declared, at least 
one paragraph in the procedure division and either a STOP RUN or 
(possibly) an EXIT PROGRAM statement. 

To me MUMPS looks more like a 4GL (4th generation language) such as Dbase, 
Clipper, Sculptor or Cognos PowerHouse because all these combined a 
programming language with an integral database (often a set of ISAM 
files) than COBOL. 

COBOL latter supported ISAM and random files but, then so did many other 
languages. Admittedly, IDMS (a network database) looked as if it was part 
of COBOL, but that was merely an illusion caused by the excellent IDBMS 
preprocessor. You wrote code containing IDMS verbs that *looked* like 
part of COBOL, but the preprocessor replaced them with subroutine calls 
before passing the result to the compiler.  

Apologies for going on a length about this but I spent around 15 years 
writing many thousands of lines of COBOL, something that's remarkably 
hard to forget, try as one might.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#38717

On 4/29/2015 3:31 PM, Martin Gregorie wrote:
> On Wed, 29 Apr 2015 13:34:02 -0400, rickman wrote:
>
>> You got all that from the wikipedia page?  You seem to read selectively.
>>
> Of course he did. The first line of the article says:
>
> MUMPS (Massachusetts General Hospital Utility Multi-Programming System)...

The name is pretty clear to me... "Multi-Programming System".  It 
doesn't say anything about medical use, just that it was developed for a 
hospital.  They do more than medicine you know.  Inventory, finance and 
logistics are applicable to many, many things.

-- 

Rick

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

#38718

On Wed, 29 Apr 2015 15:43:33 -0400, rickman wrote:

> On 4/29/2015 3:31 PM, Martin Gregorie wrote:
>> On Wed, 29 Apr 2015 13:34:02 -0400, rickman wrote:
>>
>>> You got all that from the wikipedia page?  You seem to read
>>> selectively.
>>>
>> Of course he did. The first line of the article says:
>>
>> MUMPS (Massachusetts General Hospital Utility Multi-Programming
>> System)...
> 
> The name is pretty clear to me... "Multi-Programming System".  It
> doesn't say anything about medical use, just that it was developed for a
> hospital.  They do more than medicine you know.  Inventory, finance and
> logistics are applicable to many, many things.

I think that came later - the article says that it was developed by a 
group that worked in an animal testing lab to keep track of results and 
then was than spotted by patient admissions and used in that area.

After that it seems to have a home in finance and banking as well as in 
other medical situations.

Cm'on, who outside the medical world would would think that MUMPS was a 
great acronym? I think folks have largely forgotten the disease now, 
along with measles, but when I was a kid mumps, measles and chicken pox 
were the things you didn't want to get, and mumps may have been the 
nastiest of these, especially if you were bloke and past puberty.
 
...goes off fuming about the selfish bastards who refuse to vaccinate 
their kids...


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#38722

On 4/29/2015 4:07 PM, Martin Gregorie wrote:
> On Wed, 29 Apr 2015 15:43:33 -0400, rickman wrote:
>
>> On 4/29/2015 3:31 PM, Martin Gregorie wrote:
>>> On Wed, 29 Apr 2015 13:34:02 -0400, rickman wrote:
>>>
>>>> You got all that from the wikipedia page?  You seem to read
>>>> selectively.
>>>>
>>> Of course he did. The first line of the article says:
>>>
>>> MUMPS (Massachusetts General Hospital Utility Multi-Programming
>>> System)...
>>
>> The name is pretty clear to me... "Multi-Programming System".  It
>> doesn't say anything about medical use, just that it was developed for a
>> hospital.  They do more than medicine you know.  Inventory, finance and
>> logistics are applicable to many, many things.
>
> I think that came later - the article says that it was developed by a
> group that worked in an animal testing lab to keep track of results and
> then was than spotted by patient admissions and used in that area.
>
> After that it seems to have a home in finance and banking as well as in
> other medical situations.
>
> Cm'on, who outside the medical world would would think that MUMPS was a
> great acronym? I think folks have largely forgotten the disease now,
> along with measles, but when I was a kid mumps, measles and chicken pox
> were the things you didn't want to get, and mumps may have been the
> nastiest of these, especially if you were bloke and past puberty.
>
> ...goes off fuming about the selfish bastards who refuse to vaccinate
> their kids...

Lol.  Yeah, to paraphrase Lincoln, most of the people are goofy about 
some things and some of the people are goofy about most things...  More 
recently I have started looking at everything in life with a critical 
eye and I am finding no end to the things that people accept without 
questioning.  I believe this is mostly because people are lazy...  but, 
there is a point to where paying attention to all the details just 
becomes exhausting, especially if you try to live in the same world you 
have always lived in.  So most people just follow the herd.  Is that 
what they refer to as "herd immunity"... immunity from thought?

BTW, I am surprised they were even allowed to call it MUMPS.  I think 
that would be a real issue in the medical community.  It's like calling 
a new cell phone targeted to doctors... EBOLA.  "Honey, I can't find my 
EBOLA anywhere.  Would you give it a ring?  Oh, there's my EBOLA."

-- 

Rick

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

#38751

In article <mhrbiu$l8f$2@dont-email.me>, Martin Gregorie
<martin@address-in-sig.invalid> writes:

> On Wed, 29 Apr 2015 13:34:02 -0400, rickman wrote:
> 
> > You got all that from the wikipedia page?  You seem to read selectively.
> > 
> Of course he did. The first line of the article says:
> 
> MUMPS (Massachusetts General Hospital Utility Multi-Programming System)...
> 
> > Is "super COBOL" a good thing or a bad thing?
> >
> I wouldn't say so: its far too terse to ever be that. I mean, you can 
> write 'Hello World' in a single line in it, but in COBOL it would be 
> something like this at its shortest:
> 
> ENVIRONMENT DIVISION.
> PROGRAM-ID.  hello_world.
> PROCEDURE DIVISION.
> PARA-1.
>     DISPLAY "Hello, World".
>     STOP RUN.
> 
> ... untested: I don't have a COBOL compiler to hand and its been a while, 
> but I'd be surprised if even a modern compiler would accept a program 
> without both environment and procedure divisions being declared, at least 
> one paragraph in the procedure division and either a STOP RUN or 
> (possibly) an EXIT PROGRAM statement. 

I checked this at work today. The one-line COBOL program

display "hello world".

compiled and ran perfectly well, and produced the required output.
Right, now to get Microfocus to implement COBOL for the Pi.

-- 
Mike Fleming

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

#38762

Mike Fleming <{mike}@tauzero.co.uk> wrote:
> In article <mhrbiu$l8f$2@dont-email.me>, Martin Gregorie
> <martin@address-in-sig.invalid> writes:
> 
>> On Wed, 29 Apr 2015 13:34:02 -0400, rickman wrote:
>> 
>>> You got all that from the wikipedia page?  You seem to read selectively.
>>> 
>> Of course he did. The first line of the article says:
>> 
>> MUMPS (Massachusetts General Hospital Utility Multi-Programming System)...
>> 
>>> Is "super COBOL" a good thing or a bad thing?
>>> 
>> I wouldn't say so: its far too terse to ever be that. I mean, you can 
>> write 'Hello World' in a single line in it, but in COBOL it would be 
>> something like this at its shortest:
>> 
>> ENVIRONMENT DIVISION.
>> PROGRAM-ID.  hello_world.
>> PROCEDURE DIVISION.
>> PARA-1.
>>     DISPLAY "Hello, World".
>>     STOP RUN.
>> 
>> ... untested: I don't have a COBOL compiler to hand and its been a while, 
>> but I'd be surprised if even a modern compiler would accept a program 
>> without both environment and procedure divisions being declared, at least 
>> one paragraph in the procedure division and either a STOP RUN or 
>> (possibly) an EXIT PROGRAM statement. 
> 
> I checked this at work today. The one-line COBOL program
> 
> display "hello world".
> 
> compiled and ran perfectly well, and produced the required output.
> Right, now to get Microfocus to implement COBOL for the Pi.

Since their compilers are based on the "POP" pseudocode system, the port
should be quite easy. (But given the expected market size, it would be a
labor of love.)
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

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

#38765

In article <vfd7ka5hhd2uuogg97ert80b6plt4un9id@4ax.com>,
Mike Fleming  <mike@tauzero.co.uk> wrote:

>compiled and ran perfectly well, and produced the required output.
>Right, now to get Microfocus to implement COBOL for the Pi.

OpenCOBOL?

sudo apt-get install open-cobol

Works out of the box on a standard Raspbian install.

Gordon

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

#38641

On 26/04/15 14:25, rickman wrote:
> On 4/25/2015 6:05 PM, Martin Gregorie wrote:
>> On Sat, 25 Apr 2015 17:01:13 -0400, rickman wrote:
>>
>>> I believe you are confusing just what "interpreted" means in the context
>>> of Forth.  Even if they "interpret" some portion of the system code, it
>>> is usually compiled into a binary file which is loaded when the system
>>> is run.  I don't know of *any* forths which were compiled from some
>>> minimal assembler at load time rather than installation time.
>>>
>> I must respectfully disagree: I was messing about with a version of Forth
>> that ran on a 6809 box under Flex09. I had all the source for this Forth
>> and vividly remember that there was almost no compiled code in it - and
>> that part of it was all assembler. This was code included the low level
>> assembler words plus the jump into the initial word low-level word.
>> Everything else was a file containing Forth source and was pulled in by
>> the assembler words and prepared for use before it put up the initial
>> user prompt. This set-up was traditional enough Forth to avoid the use of
>> the FLEX filing system: all data and code 'screens' lived in a single
>> random file containing numbered 1K chunks known as 'screens'. A 'screen'
>> was 16 lines of 64 characters (1 kB). User written source code lived in
>> this screenstore - it had do because the editor would only operate on one
>> screen at a time and had no means of accessing normal Flex files.
>>
>> I don't remember how the system code was stored but it could well have
>> been another of these Forth random access screen file: it would be
>> logical to do it that way.
>>
>> Don't forget that Forth was developed to run on very low powered kit:
>> IIRC something like a DEC PDP8 and much of it came out of the astronomy
>> community.
>
> You may have found a forth that didn't have much compiled code, which is
> not impractical since Forth generally compiles very quickly compared to
> other languages.  But I was disagreeing with this statement,
> "Traditional Forths didn't have a compiled form".  I think if you look
> around at Forths from any period you will find very few that are not
> compiled with only the user code loaded at run time.
>
>
>>> I am not proficient at any software language at this time.  I used to
>>> know C pretty well, but that is being pushed out by C++.  Since I don't
>>> have much of a language bias I find most C code to be pretty much as
>>> write-only as Forth.
>>>
>> I prefer ANSI C to C++, which I find hopelessly baroque and far too full
>> of 'features'. Some support from this view comes from the point that any
>> of the "C++" programs I've run into have been little more than ANSI C
>> with added // comments and using cin and cout for I/O rather than C's
>> stdio functions.
>>
>>> I find Forth to be extremely productive when interfacing to hardware
>>> which is *my* area of expertise.  I produce boards and use Forth to
>>> program the test fixtures.
>>>
>> Given its background that isn't all that surprising: I believe the
>> astronomers used it to control telescopes of various types.
>
> Funny how small aspects of something stand out and are remembered. Forth
> was invented by Charles Moore who was developing code to control
> telescopes.  Since then it has done many, many other things.  It has two
> main attributes in my opinion.  One is the interactivity when
> controlling hardware which is actually useful for many, many non-control
> apps as it facilitates testing.  The other is the flexibility as the
> language is easily extensible and allows the developer to create a
> "custom" language to suit the application.
>
The key advantage of Forth is is code density.

I ported a version of Forth to a board I was staled with taking from 
hardware to basic OS, and it was indeed ALL assembler.

And yet what it would have compiled to, or been stored at if it were 
'Forth' would have been almost exactly the same.


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [standalone]

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

csiph-web