Subject | RE: [IB-Architect] enhancement to procedure/trigger language |
---|---|
Author | Jeroen W. Pluimers (mailings) |
Post date | 2001-06-07T14:55:44Z |
> >AFAIK Pascal has never had or needed a return statement,nor is it a
> >committee product. My personal opinion is also that it is a much moreBecause of the same reason many other languages don't need it either.
> >coherent language than C. But this is going OT.
>
> Why doesn't it need a return statement?
Like C / C++ / Java / many other languages, Pascal is block oriented. A
procedure simply ends at the procedure block, and will return from there to
the callee.
Some languages have a means of 'returning' prematurely (i.e. in the middle
of a function). In Borland Object Pascal (the language underneath Delphi),
this is called 'exit', and if my memory serves me right, it is called
'return' in C and C++.
Some languages use 'return' to pass back a function result. In Pascal this
is split into two steps: there is an assignment operation filling in the
function result, and (optionally) second there is 'exit' to actually leave
the function.
So return is an extension to the regular point of return: like 'break', it
is another way to leave a procedure or function in a predetermined way
without the need to resort to labels and goto's.
The good thing about labels and jumping (either using goto, or leave) is the
added flexibility.
The hard thing about labels and jumping to them (one way or the other) is to
tighten any potential 'loopholes' from the parser side.
The bad thing about labels and jumping is that it makes code harder to
maintain because of the added degrees of freedom.
> Pascal was the only "language" that required separate GRPE code generatorsAs were many other languages suffering from the same issue. Remember
> for each implementation. Apollo, DEC, and Sun Pascals were so radically
> different they might as well been different languages.
FORTRAN? Same thing - each machine vendor invented specific extensions to
it, and it was hart to write portable code (especially because the lowest
common denominator was quite poor).
Same holds for SQL, lots of different implementations that are usually far
behind the actual standard, or diverse much from each other (and the
standard).
So maybe we can do something good here: extend Interbase SQL to get more
functionality, and at the same time adhere as much as possible to standards.
--jeroen