Re: invoking a method

Frank Swarbrick wrote (edited):

about all OO languages ... pretty much all invoke methods in a somewhat similar format that the object comes first, followed by the name of the method, followed by any parameters.

COBOL 2002: invoke object "method" using by value parm1, parm2
MF COBOL: invoke object::"method"(parm1, parm2)
Java: object.method(parm1, parm2)
Objective-C: [object method:parm1 parm2name:parm2]
Ruby: object.method parm1, parm2

I've come to believe it would be more "natural" if the method
> name was specified first. The method is very often a
> verb. So why not something like:
insert employee into list

where 'insert' is the method name, 'employee' is the object to be inserted (the parameter) and 'list' is the object that is to receive the message. 'into' is just a noise word to make it more readable.

Okay, having actually done maintenance on compilers including written more than one, I'll state why I don't think your idea will work, at least, not in the context of Cobol.

Now, I will admit I have not worked on anyone else's Cobol compiler so I don't know how they work, I will offer some thoughts on the subject based on how I suspect they work. I may be wrong on this point but considering the way Cobol reference manuals show Cobol syntax, I have a reasonable belief that this would be the way it would be done.

Presumably the parser for a Cobol Compiler is going to presume some fixed syntax, i.e. a specific DIVISION having certain contexts. In fact, the typical reference manual for a Cobol Compiler will have line and box based syntax diagrams showing exactly what particular symbols are permissible at a particular point, e.g. in the DATA DIVISION, if there is a two-digit number, it is expected to be followed by either a data name, blank or FILLER, followed by PIC or PICTURE or some other terms.

Now, in order to allow something like this, you would have to have some way to allow a Cobol parser to identify that this is a method (or function) call.

If we enter the PROCEDURE DIVISION, typically what you have are a series of sentences in which the first word, which is a "verb", dictates what the sentence means, i.e. what action is to take place. That particular verb has certain permitted parameters and options.

Actually, you could do something like this if you had a provision that referencing an identifier is conditionally a method call. Of course, this also causes a problem if the method name or object name are the same as or similar to a Cobol keyword. But the high probability is that it would be an extreme effort to be able to implement such a thing, since I suspect that Cobol compilers tend to be keyword driven, thus allowing them to implement the "implicit call" function (where reference to a procedure or function implicitly calls that function without use of, say, a CALL (or PERFORM in Cobol) would require potentially a significant rewrite or even a reengineering of the parsing routines of the compiler.

Languages that implement "implicit call" can do this because they have provision for referencing an identifier as either an assignment (if the symbol following the identifier is the assignment symbol), or a procedure call if the identifier is a procedure / function, or is followed by a parameter list.

C, Pascal and Visual Basic all support "implicit call." Some languages, it would be very difficult to implement.

In Fortran, for example, you have something like

DO 5 I = 1, 10
or
DO 5 I = 1.10

The first is a loop construct, the second is an assignment. Fortran does not depend on spaces, does not have reserved words, and has few restrictions on how you form an identifier, so until it sees the "." or the "," it can't tell that the statement is an assignment or is a loop. In fact, while technically it is legal syntax, most people who write Fortran would consider the second example to be incorrect.

So in Fortran, you can't even use spaces or delimiters to determine whether some reference is a variable or an imperative statement until much further along in the line. Thus implementing an "implicit call" would be very difficult if it was even possible.

Now, Cobol has a number of advantages including imperative command-based statements. This makes writing a compiler easier, at the expense of making the language to be compiled more rigid. Which is exactly the state of Cobol programs.

Now, it is conceivable to allow such a construct if some way can be found to allow a method reference to be used such that some keyword in the stream allows the program to be aware that this is what is being done.

Actually, this might not be a bad idea, and it sounds interesting, although I don't know if it can be implemented in a reasonable fashion giving the method I suspect most Cobol compilers are implemented.

.

Relevant Pages

  • Re: invoking a method
    ... Okay, having actually done maintenance on compilers including written more than one, I'll state why I don't think your idea will work, at least, not in the context of Cobol. ... I was suggesting it for if I were developing my own language; a language that is not COBOL. ... I may be wrong on this point but considering the way Cobol reference manuals show Cobol syntax, I have a reasonable belief that this would be the way it would be done. ... Presumably the parser for a Cobol Compiler is going to presume some fixed syntax, i.e. a specific DIVISION having certain contexts. ...
    (comp.lang.cobol)
  • Re: I need help!!
    ... Most COBOL environments have utilities available to create standard ... but you will still have to deal with the packed fields. ... If you DON'T have a COBOL compiler available you should still try and get ... I would also look at converting the ...
    (comp.lang.cobol)
  • Re: Next project, C programming problem.
    ... writting with fopenit will be Stream. ... > If it is COBOL, then you really do need properly delimited records since ... The COBOL source files are the data my program needs to work with. ... otherwise the padding blew the COBOL compiler ...
    (comp.os.vms)
  • Re: [OT] Logic vs. Conversation (Was: Cobol Myth Busters)
    ... I've read that there is a French language CoBOL, ... I have compiled COBOL with both French and German compilers. ... I don't know whether the French COBOL compiler is in much use in France or ...
    (comp.lang.cobol)
  • Re: Cobol Copybook Parsing
    ... If you are trying to get XML data out of a COBOL file, ... in the "built-in" facilities of at least one COBOL compiler. ... See the XML ... > "Tom Morrison" wrote in message ...
    (comp.lang.cobol)