Re: [GNU-COBOL] New to COBOL

[Chad Slaughter <slaught@advancenet.net>]

David L. Nicol wrote :>
>
>But internal storage is an implementation detail.  Would not any 

yes, and we are implementing, thus... =)

Unlike more recently invented languages, COBOL has a s part of the langauge
many things which other langauges try and hide. 

>arbitrary-precision arithmatic package be able to APPEAR AS these data
>types?

sort of, matt f, worked on doing just this with the GNU MP pakcage i think.
part of the problem was the package was in complete and didnt allow for
things like fixed length (cant think of the word, the part after the decimal 
point) any rate, so there was soem issues there.
in cobol numbers are defined to a certain fixed length. this has to
be inforced, or you dont get proper results.
truncation/rounding, etc.. issue when the result doesnt fit into
the destations stroage(raise an on size error)
some other things too...

>
>Perhaps by using C++ and designing a few cobolesque base classes?
>
>Or by using perl5 and defining a few methods?
>

yes, perl and C++ could be used to build classes that implement
the cobol storage system...datea types asit were. =)

>It just seems to me that if COBOL functionality is, as is widely
>claimed,
>a proper subset of the functionality of so many other languages,

i am not sure i understand this statement or buy in to it.

>throwing
>together a rough translator, instead of a compiler, would not be
>difficult,

well at first we are making a translator then moving that to a compiler

>especially since I know (it was an aside in a lecture in AI class) that
>someone once wrote a full Common Lisp interpreter in dBase.

Lisp, even Common Lisp, is aobut a 1000 times easier to implement
then COBOL. In fact building translotors/compilers/interpeteors for
all Lisp like langues(lisp,scheme,etc) is suppose to be easy, that was one
of the orignal intentions fo the langauge. (if you wnat I can probaly
dig up some history on lisp to prove my point)

I think the dig against Lisp interpertors is that all you have to do is
count parens. =) but I digress.

>Perl arrays are all variable length.  Since COBOL gives access to
>hardware-oriented abstractions like "regions of storage" why not set up
>a COBOL VM that has them?  Create the "ideal COBOL machine" as an

Cobol vm, interesting idea..somone else around here had talked about that..
*shrug* i just dont know. its certainly a possiblity. I am not sure
if it would be esier gto buid a VM or just a runtime support
for translated code... *shrgus*

>ENVIRONMENT or something, instead of trying to keep up with (or even
>worse,
>duplicate) the egcs back-end?

duplicating the gcc back-end is not a goal. what is a goal is to
evenetually, integrate the compiler front-end with the gcc back-end
so we get instant wide=spread arch support.

>> Numeric-edited fields and alphanumeric-edited fields would be
>> particularly enjoyable.  Floating or fixed insertion symbols (+, - or
>> $), zero suppression with blank or asterisk replacement, CR and/or DB
>> symbols, BLANK WHEN ZERO, and so forth.
>
>These would be a property of the instance of the display method, rather 
>than the data, I think (coming to this with no experience of COBOL
>whatsoever.)

I wish. =) Unfortuantly some of these things effect calculations.
THere are just a ton of little gotchas with the cobol standard...
I agree with most things you are saying, I am not trying to diswade you.
I had the exact smae thoughts you are having..then I read the standard..
that was problabyu my first mistake. maybe I'll correct that.

>What kinds of file systems or other persistence abstractions exist in
>the general COBOL environment?  Does COBOL give low-level calls to
>things

Files, index,sequential, relative. are the persistent storage.
There is very little abstraction.

>like "read a block of records from tape drive 2" or what?  Do you have

yes, it does have calls to access tapes like that.

>to mount the tape with a name and then read the records from the device
>with the name?

yes. but part of that is implementation dependent.(ie we can do what we like)
my gut reaction was for unix, to ignore those requirements, since
unix can mount devices to look like files on the filesystem..thus just
treat everything like a file inside cobol..dont worry about devices, etc.

Remember COBOL was around before most moderna OS(i could have a long arguement
about that statement,but just accept it at face value please. =) thus
some features of the langauge, are readily handled by the OS, particularly
unix.
For instance the Segmentation module, which deals with object overlays, etc.
These issues are best handled by modern linkers and loaders and the OS
virtual memory system. This i skind of a bad example but there are others,
as the Sementation module is deprecated in teh 85 standard. 

>You're comparing re-implementing a programming language written in 1952
>with convincing a disinterested observer that a machine has
>consciousness?

I dont think he's compare the products, merely the method.

>Whew -- I was using as my role-modeling anecdote the existence of a
>full implementation of Common Lisp done with dBase III. :)

Maybe pick a better role model. =)

>How do people get into COBOL programming?  It's never offered in schools

Blackmail.


I think justin said it best when he explained that the hard
part is NOT the runtime system or emulating the functionality. Its the
translation of the grammar and deriving meaning from the text.
THe implementation is...easy. Primarily why, I have about 60% of it layed
out in paper and code. But the functionality has no meaning with out
the abiltiy to understand the text. Thats the hard problem here.
If you can help, please do. We lost the person who was mainly do it
and any and all help would be appreciated. I think Tim has picked up the ball
on that end, but I am sure he could use help.


Chad

-- 
Chad Slaughter  -- slaught at advancenet.net

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.