Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/20/90)
Hello:
I would appreciate a response from each of you (whether you use JPI M2 2.00 or not) concerning the following question/dilema:
PROCEDURE function (whatever: WhateverType): ReturnType;
BEGIN
END function;
If you compile the above example (filling in whatever, WhateverType, and ReturnType with names/types of your chosing), you should get a compile-time error.
JPI M2 1.17 gave you a compile time error if you compiled a module containing a procedure which was defined as having a return type/value, but did not issue a return.
JPI M2 2.00 does not give you a compile-time error; it will give you a run-time error when you go to executre the said procedure.
I would like to know the following from all of you:
1) The name of your Modula-2 compiler plus its version.
2) Do you receive a compile-time or run-time error for
the above procedure?
3) What is your preference and why?
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgPat.Terry@p101.f4.n494.z5.fidonet.org (Pat Terry) (07/23/90)
> I would appreciate a response from each of you (whether you use JPI M2 > 2.00 or not) concerning the following question/dilema: > MODULE t; PROCEDURE f () : INTEGER; BEGIN END f; VAR a : INTEGER; BEGIN a := f() END t. JPI 1.17 - compile time error FST, Logitech 3.03, JPI 2.0, QuickMod, FTL - no compile time error QM and FTL did not even report run time error. While a preference would be for a compile time error, note that the presence of a RETURN does not mean you cannot switch off run time checking, unless you are very clever. For example, the code below would not execute the RETURN. MODULE t; PROCEDURE f () : INTEGER; BEGIN IF FALSE THEN RETURN 1 ELSE END END f; VAR a : INTEGER; BEGIN a := f() END t. -- uucp: uunet!m2xenix!puddle!5!494!4.101!Pat.Terry Internet: Pat.Terry@p101.f4.n494.z5.fidonet.org
TRL3@psuvm.psu.edu (Tim Larson) (07/24/90)
In article <1960.26A95065@puddle.fidonet.org>, Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) says: > PROCEDURE function (whatever: WhateverType): ReturnType; > BEGIN > END function; > > If you compile the above example (filling in whatever, WhateverType, and >ReturnType with names/types of your chosing), you should get a compile-time >error. > > JPI M2 1.17 gave you a compile time error if you compiled a module >containing a procedure which was defined as having a return type/value, but >did not issue a return. > > JPI M2 2.00 does not give you a compile-time error; it will give you a >run-time error when you go to executre the said procedure. > > I would like to know the following from all of you: > > 1) The name of your Modula-2 compiler plus its version. > 2) Do you receive a compile-time or run-time error for > the above procedure? > 3) What is your preference and why? I have JPI M2 v1 rel. 1.14 (never got 1.17 and haven't opened v2 yet). I got a little curious about this and wrote the following silly example. MODULE TestFuncReturn; IMPORT IO; PROCEDURE IllBehavedFunc(IWantToBehave: BOOLEAN): BOOLEAN; BEGIN IF IWantToBehave THEN RETURN TRUE END END IllBehavedFunc; BEGIN IF IllBehavedFunc(TRUE) THEN IO.WrStr ('Sometimes I act properly.'); IO.WrLn END; IF IllBehavedFunc(FALSE) THEN IO.WrStr ('Sometimes I act up!'); IO.WrLn END END TestFuncReturn. This example gives no compile-time error, but does generate a run-time error. I would prefer compile-time errors myself, but if the compiler cannot catch an error as simple as the above (much less the worse ones that could be committed), then the run-time error seems to be the only recourse. Did rel. 1.17 fix this? Or is it intractable? Jes' Curious, -Tim Larson trl3@psuvm.bitnet
dhinds@portia.Stanford.EDU (David Hinds) (07/24/90)
In article <90204.213559TRL3@psuvm.psu.edu> TRL3@psuvm.psu.edu (Tim Larson) writes: >In article <1960.26A95065@puddle.fidonet.org>, > >I have JPI M2 v1 rel. 1.14 (never got 1.17 and haven't opened v2 yet). I >got a little curious about this and wrote the following silly example. >>... >PROCEDURE IllBehavedFunc(IWantToBehave: BOOLEAN): BOOLEAN; >BEGIN >IF IWantToBehave THEN >RETURN TRUE >END >END IllBehavedFunc; >... >This example gives no compile-time error, but does generate a run-time >error. I would prefer compile-time errors myself, but if the compiler >cannot catch an error as simple as the above (much less the worse ones >that could be committed), then the run-time error seems to be the only >recourse. > I would be very surprised to see a compiler that flagged the above routine as an error. I don't think that leaving the possibility of reaching the end of a procedure without a RETURN statement violates the syntax of M2 - am I wrong? If I'm right, then there is no way for the compiler, in the general case, to determine if the illegal exit might ever be executed. Sure, it could test for some trivial cases like the one in the example, but it seems pointless. The runtime trap can catch infinitely more cases of illegal exits than the compiler ever could. I guess the compiler could easily enough make sure that a procedure has at least one RETURN statement that could be reached, but beyond that, the problem is insurmountable. A compiler could require that all execution paths end in RETURN statements, but that is still a non-trivial extension to the language syntax. -David Hinds dhinds@popserver.stanford.edu
jensting@skinfaxe.diku.dk (Jens Tingleff) (07/24/90)
dhinds@portia.Stanford.EDU (David Hinds) writes: >In article <90204.213559TRL3@psuvm.psu.edu> TRL3@psuvm.psu.edu (Tim Larson) writes: >>In article <1960.26A95065@puddle.fidonet.org>, [..] >> > I would be very surprised to see a compiler that flagged the above >routine as an error. I don't think that leaving the possibility of [..] Quite right, a warning is perhaps appropriate. >the problem is insurmountable. A compiler could require that all execution >paths end in RETURN statements, but that is still a non-trivial extension >to the language syntax. As well as a VERY pointless one, isn't the general case the Halting Problem ?? Anyway, in a lot of code the programmer *knows* that a RETURN will be encountered. Even if checks are done manually, that may not result in a RETURN, e.g. PROCEDURE FunnyStuff(arg1 : INTEGER) : BOOLEAN; BEGIN IF arg1 < 126 THEN (* Cath errors. *) InOut.WriteString("ERROR : plane just crashed, tough luck. Bye"); InOut.WriteLn; HALT END; CASE arg1 OF (* So this is stupid, so what ? *) 127 : RETURN TRUE | 128 : RETURN FALSE END; END FunnyStuff; Even if M-2 *does* provoke the programmer to reflect on the programming, there is no reason for a straight-jacket requirement of a RETURN statement that's always reached.. . Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
preston@erato.rice.edu (Preston Briggs) (07/24/90)
In article <1990Jul24.060519.23417@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: >>PROCEDURE IllBehavedFunc(IWantToBehave: BOOLEAN): BOOLEAN; >>BEGIN >>IF IWantToBehave THEN >>RETURN TRUE >>END >>END IllBehavedFunc; > I would be very surprised to see a compiler that flagged the above >routine as an error. I don't think that leaving the possibility of >reaching the end of a procedure without a RETURN statement violates the >syntax of M2 - am I wrong? If I'm right, then there is no way for the >compiler, in the general case, to determine if the illegal exit might >ever be executed. You're correct that it isn't specified in the syntax. I think it probably can't be. However, the compiler can still detect that there exists a path from the entrance to the END of a function with no RETURN. It's one of the advantages of using control constructs with the infamous "single-entrance, single-exit" property. If people are curious, I can show how it works; but it'll be a somewhat involved posting. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu
pattis@cs.washington.edu (Richard Pattis) (07/25/90)
Just to see how this "problem" is handled elsewhere: Ada must report a static
semantic error (excuse me, for those of you reading SIGPLAN) if a function
has NO return statement. It does not have to diagnose whether the function
must execute a return statement. If the end of a function is reached without
executing a return statement, Ada raises one of its standard exceptions
(PROGRAM_ERROR). Interestingly enough, that exception can be handled in the
function itself, so we can include a safeguard (although such code is rarely,
if ever used).
FUNCTION F (params) RETURN INTEGER IS
locals
BEGIN
some hairy computation that terminates, but may or may not execute
a return statement
EXCEPTION
WHEN PROGRAM_ERROR => RETURN 0;
END F;
Rich Pattisjensting@skinfaxe.diku.dk (Jens Tingleff) (07/25/90)
preston@erato.rice.edu (Preston Briggs) writes: >In article <1990Jul24.060519.23417@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: [..] >I think it probably can't be. However, the compiler >can still detect that there exists a path from the entrance >to the END of a function with no RETURN. It's one of the >advantages of using control constructs with the infamous >"single-entrance, single-exit" property. Even if the language doesn't have the `nice' control structures, the compiler can still detect the presence of a path. I'm thinking of GNU CC which (when optimising) performs flow analysis that will pester the knowledgeable user ;-) with message about end of non-void function reached etc. If you don't have the (non-ANSI) patch declaring `exit()' to be non-returning, the `main()' function is a liable candidate for such a warning... As said (too) many times, the existance of a path doesn't mean that there is an error. Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
TRL3@psuvm.psu.edu (Tim Larson) (07/25/90)
In article <10180@brazos.Rice.edu>, preston@erato.rice.edu (Preston Briggs) says: >You're correct that it isn't specified in the syntax. >I think it probably can't be. However, the compiler >can still detect that there exists a path from the entrance >to the END of a function with no RETURN. It's one of the >advantages of using control constructs with the infamous >"single-entrance, single-exit" property. > >If people are curious, I can show how it works; >but it'll be a somewhat involved posting. > I would be very interested in that (references would be fine if the posting were too long). However, you state the "single-entrance, single-exit" requirement, which Modula-2 neatly destroys with LOOP..END. Is that require- ment necessary for the algorithm to work? -Tim Larson trl3@psuvm.bitnet "I still have the greatest confidence in our mission..." -HAL 9000
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/25/90)
Hello:
Chris at JPI stated that the developers moved flow-traced errors such as having no return statement in a procedure defined as having a return to run-time error checking because they did not have enough time to make it a comple-time error.
I am surprised Quick MOD did not catch this error at compile time. I though Stony Brook's compiler was superior to most DOS compilers.
Almost all C compilers following the ANSI standard will catch the error I mentioned at compile time.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orglins@Apple.COM (Chuck Lins) (07/25/90)
In article <90206.084158TRL3@psuvm.psu.edu> TRL3@psuvm.psu.edu (Tim Larson) writes: >In article <10180@brazos.Rice.edu>, preston@erato.rice.edu (Preston Briggs) >says: >>You're correct that it isn't specified in the syntax. >>I think it probably can't be. However, the compiler >>can still detect that there exists a path from the entrance >>to the END of a function with no RETURN. It's one of the >>advantages of using control constructs with the infamous >>"single-entrance, single-exit" property. >> >>If people are curious, I can show how it works; >>but it'll be a somewhat involved posting. Yes, I wouldn't mind seeing you involved posting on how this would work >> >I would be very interested in that (references would be fine if the posting >were too long). However, you state the "single-entrance, single-exit" >requirement, which Modula-2 neatly destroys with LOOP..END. Is that require- >ment necessary for the algorithm to work? LOOP..END is still single-entry, single-exit. You always enter the loop at the top, and will exit at the END statement. There's no way to jump into the middle of the LOOP statement, or leave it at other than the predetermined end. -- Chuck Lins | "Is this the kind of work you'd like to do?" Apple Computer, Inc. | -- Front 242 20525 Mariani Avenue | Internet: lins@apple.com Mail Stop 37-BD | AppleLink: LINS@applelink.apple.com Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" The intersection of Apple's ideas and my ideas yields the empty set.
preston@titan.rice.edu (Preston Briggs) (07/26/90)
In article <90206.084158TRL3@psuvm.psu.edu> TRL3@psuvm.psu.edu (Tim Larson) writes: > you state the "single-entrance, single-exit" >requirement, which Modula-2 neatly destroys with LOOP..END. Is that require- >ment necessary for the algorithm to work? LOOP - END is ok becase all the flow must come out of the END, regardless of how it gets there. My particular idea needs single-entrance, single-exit, though as another poster pointed out, we could could handle all sorts of nasty things during optimization when a complete flow graph is constructed anyway. I'll assume a recursive descent parser. In the routine handling statement-sequences, keep a flag called "unreachable". Initially, it's false. It is set to true if we notice a RETURN, an EXIT, or a call to HALT. At the end of statement-sequence, return the value of unreachable. In a procedure (function) body, when statement-sequence returns, check the unreachable flag. If it's true, then we must have encountered a RETURN or HALT. (EXITs don't count since they should only occur with a LOOP-END and would have already been caught by another mechanism). Note that unreachable only applies to the current statement-sequence. Nested statement-sequences have their own (local) variable. At the beginning of each statement, see if it's unreachable. If so, you might warn the user. If the statement is a RETURN or HALT or EXIT, set the unreachable flag. Also, if it's an EXIT (and the exit was reachable), set a global flag called "exit_reached". This will come up again in the LOOP handling. The other simple statements are uninteresting. Compound statments require more care. A RETURN occuring in a WHILE statement is ignored, since there's always a path around the body of a WHILE. REPEAT-UNTIL and WITH set the unreachable flag if their statement-sequence returns true (indicating that there's a RETURN inside). CASE statements will set unreachable if *all* of their alternatives contain RETURNs. I don't have a standard for M-2, but Oberon specifies that there's no fall through for a CASE. IF-THEN statements will set the unreachable flag if all the alternatives contain a RETURN and there is an ELSE clause. If there's no ELSE, we assume there's a path around the whole statement. LOOPs are a little tricky. We need a global variable called "exit_reached". When we enter a LOOP, we preserve the old exit_reached, a set it to false. Then we call statement_sequence. If any EXIT is reched within the statement sequence (no matter how nested), then exit_reached will be set. At the END, we set unreachable to NOT exit_reached. We also restore exit_reached. That's about it. I implemented it last night in an Oberon parser, and it works ok. There are some interesting effects. You'll get no error in this case BEGIN LOOP END END function; since we'll hang in the loop and therefore never require a return. It would be easy to print a warning in this case too, since we have all the necessary info. I decided not to. Of course, there are easy examples where you'll get a complaint and you *know* that it's unnecessary. BEGIN IF erroneous THEN emit_error_and_halt(1) ELSE RETURN 3 END END function; Here the compiler doesn't know that "emit_error_and_halt" won't be returning and so will complain of missing returns. I guess I'm not too concerned, but others may have opinions. Regarding JPI, if they've added a GOTO (as implied by an earlier posting) then they'd have to be trickier to issue compile-time warnings. Probably why they've gone to a run-time error. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu
Martin.Baur@p70.f801.n302.z2.fidonet.org (Martin Baur) (07/26/90)
In a message of <Jul 20 09:26> Peter M. Perchansky (1:273/101@fidonet) writes:
PMP: " PROCEDURE function (whatever: WhateverType): ReturnType;
PMP: " BEGIN
PMP: " END function;
Hi Peter
I guess you're after the FUNTION without RETURN behavior, aren't you? I
currently use Logitech 3.40. This compiler does not issue any error message
during compiler run. I don't even get a runtime error. It simply hangs the
system sometimes.
In one of my commerically sold libraries I forgot to place a return statement,
and it neverthless works until now. Strange, strange ...
I would like the compiler to report the missing RETURN statement. Although the
compiler normally doesn't know if the ERTURN is ever called. My wish would be:
The compiler should analyze the program flow to recognize a program branch
that doens't have a RETURN statement. This case should cause an error message.
!Beware of Martin Baur!
(His point of view: 2:302/801.70)
--
uucp: uunet!m2xenix!puddle!2!302!801.70!Martin.Baur
Internet: Martin.Baur@p70.f801.n302.z2.fidonet.orgGeorge.Emery@p42.f369.n105.z1.fidonet.org (George Emery) (07/26/90)
> PROCEDURE function (whatever: WhateverType): ReturnType; > BEGIN > END function; > 1) The name of your Modula-2 compiler plus its version. TDI Modula-2 for the Atari ST, Developer's Version 3.00b > 2) Do you receive a compile-time or run-time error for > the above procedure? Run-time error: No return from a function > 3) What is your preference and why? I'd prefer a compile-time error because it's nice to know about a problem before it gets to run-time and requires extra debugging effort. Pat Terry is correct, however, and run-time checking shouldn't be ignored in this example. -- uucp: uunet!m2xenix!puddle!369.42!George.Emery Internet: George.Emery@p42.f369.n105.z1.fidonet.org
Dominique.Willems@p4610.f46.n295.z2.fidonet.org (Dominique Willems) (07/26/90)
Hi Peter,
I have JPI M2 V2.0, as probably you had already guessed...
> 3) What is your preference and why?
Quite an intriguing dilemma. Especially since it's further complicated by
the result_optional switch in the Call pragma.
I'd say add another pragma giving you the choice; run-time, compile-time or
no checking at all, defaulting to compile-time.
Since we already entered the world of more relaxed form-checking, like
variable numbers of parameters and optional returns, I don't think another
"philosophy-breaking" pragma can do any harm. If you're really a hard-core
"no-compromises" Modula programmer, you can just leave all the pragmas alone
and default to the standard.
What do you think ?
Regards,
Dominique
--
uucp: uunet!m2xenix!puddle!2!295!46.4610!Dominique.Willems
Internet: Dominique.Willems@p4610.f46.n295.z2.fidonet.orgPeter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/26/90)
Hello Tim:
(by the way, Thank you for sending me the article from TugBoat; did you receive my letter?)
JPI 1.17 produces a compile-time error if you do not issue a return statement period, or if you do not issue a return statement under all possible condidtions.
JPI 2.00 moved the compile-time error to run-time. I have been hounding JPI (on the JPAM BBS) to move the error checking back to compile time; Chris stated the developers would try to do so.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgjensting@skinfaxe.diku.dk (Jens Tingleff) (07/27/90)
preston@titan.rice.edu (Preston Briggs) writes: >In article <90206.084158TRL3@psuvm.psu.edu> TRL3@psuvm.psu.edu (Tim Larson) writes: >> you state the "single-entrance, single-exit" >>requirement, which Modula-2 neatly destroys with LOOP..END. Is that require- >>ment necessary for the algorithm to work? >LOOP - END is ok becase all the flow must come out of the END, regardless of >how it gets there. My particular idea needs single-entrance, single-exit, >though as another poster pointed out, we could could handle all sorts >of nasty things during optimization when a complete flow graph >is constructed anyway. [.......] Isn't this method flow-analysis ? The whole point about flow-graphs in "single-entrance / single-exit" languages is that they are *easy* to contruct. The "single.." property gives only reducable flowgraphs (I think that's Aho and Ulmanns term for it), which may be processed on the fly when parsing, which (to my understanding..) is what's done here. The ease of contruction of flowgraphs is one of the points where Modula-2 can be snotty and superior in the company of other languages ;-) ;-). Note that this ease was put to good use in optimising BLISS compilers (BLISS also has reducable flowgraphs) [Wulf et al. "the design of an optimising compiler" American Elsevier New York 1975]. Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
preston@titan.rice.edu (Preston Briggs) (07/28/90)
In article <1990Jul27.102753.21385@diku.dk> jensting@skinfaxe.diku.dk (Jens Tingleff) writes: >preston@titan.rice.edu (Preston Briggs) writes: >>My particular idea needs single-entrance, single-exit, >>though as another poster pointed out, we could could handle all sorts >>of nasty things during optimization when a complete flow graph >>is constructed anyway. >Isn't this method flow-analysis ? The whole point about flow-graphs in >"single-entrance / single-exit" languages is that they are *easy* to >contruct. The "single.." property gives only reducable flowgraphs (I think >that's Aho and Ulmanns term for it), which may be processed on the fly >when parsing, which (to my understanding..) is what's done here. Well sure. Modula-2 programs and such always give reducible flow graphs which simplifies the implementation of certain data flow analysis algorithms, particularly those involving some sort of interval reduction. My little example from the other day was a particulalarly simple version of what Rosen calls "high-level data flow analysis." By "high-level," he meant that the routine's flow graph is never constructed; instead, we do data flow analysis over the nested statements of the routine. My example was "particularly simple" because I didn't actually do any data flow analysis. We never looked at the data at all. >The ease of contruction of flowgraphs is one of the points where >Modula-2 can be snotty and superior in the company of other languages >;-) ;-). Note that this ease was put to good use in optimising BLISS >compilers (BLISS also has reducable flowgraphs) [Wulf et al. "the design >of an optimising compiler" American Elsevier New York 1975]. Right. The BLISS compiler also used Rosen's ideas for their data flow analysis. In contrast, a typical Fortran compiler might generate an intermediate form of the program (looking something like assembly perhaps) and then require the optimizer to discover the flow graph from this low level form (not that it's particularly difficult either). I particularly like the point about M 2 being snotty and superior... It *is* easy to build the flow graph, which simplifies optimization; but Wirth is pretty down on optimizing compilers, so ...? -- Preston Briggs looking for the great leap forward preston@titan.rice.edu
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/30/90)
Hello Martin:
You are correct concerning a procedure function without a return statement.
JPI M2 1.17 issued a compile-time error. JPI M2 2.00 issues a run-time error.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgPeter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/30/90)
Hello David:
In a msg dated 26 Jul 90 01:12:39, David Hinds said:
**********************BEGIN QUOTE*****************************
From: dhinds@portia.Stanford.EDU (David Hinds)
Date: 24 Jul 90 06:05:19 GMT
Organization: AIR, Stanford University
Message-ID: <1990Jul24.060519.23417@portia.Stanford.EDU>
Newsgroups: comp.lang.modula2
I would be very surprised to see a compiler that flagged the
above
routine as an error. I don't think that leaving the possibility
of
reaching the end of a procedure without a RETURN statement
violates the
syntax of M2 - am I wrong? If I'm right, then there is no way
for the
compiler, in the general case, to determine if the illegal exit
might
ever be executed. Sure, it could test for some trivial cases
like the
one in the example, but it seems pointless. The runtime trap
can catch
infinitely more cases of illegal exits than the compiler ever
could. I
guess the compiler could easily enough make sure that a
procedure has
at least one RETURN statement that could be reached, but beyond
that,
the problem is insurmountable. A compiler could require that all
execution
paths end in RETURN statements, but that is still a non-trivial
extension
to the language syntax.
***********************END QUOTE******************************
JPI TopSpeed Modula-2 1.17 issued a compile-time error; so it is possible.
JPI TopSpeed Modula-2 2.00 issues a run-time error.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgPeter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/30/90)
Hello Dominque:
What do I think? I think the first form of defensive programming outside of the programmer is compile-time errors followed by run-time errors.
What gets me is that JPI M2 1.17 issued a compile-time error, but JPI M2 2.00 issues a run-time error; bad switch in my opinion.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgPeter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/30/90)
ello:
Thank you for your response.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgErnie.Bokkelkamp@p22.f1.n491.z5.fidonet.org (Ernie Bokkelkamp) (08/05/90)
On 30 Jul 1990 07:50, Peter M. Perchansky (1:273/101@Fidonet) wrote: PP> You are correct concerning a procedure function without a PP>return statement. PP> PP> JPI M2 1.17 issued a compile-time error. JPI M2 2.00 issues PP>a run-time error. I have been following the messages about this subject and until this morning I did not see the real impact of this "new feature". I have been trying to find an error for 5 days in a small demo program converted from C to Modula-2 which runs under MS-Windows. I have been having problems with the Windows interface so I have concentrated on that area. The fault reported in ERRORINF.$$$ is "No return value for procedure" and that is all I get, the addresses are no help due to the program running under windows. Debugging with VID can't be done, the Windows debug version does not report anything, etc. I found the problem this morning, I forgot a RETURN! Cheers Ernie -- uucp: uunet!m2xenix!puddle!5!491!1.22!Ernie.Bokkelkamp Internet: Ernie.Bokkelkamp@p22.f1.n491.z5.fidonet.org
defaria@hpclapd.HP.COM (Andy DeFaria) (08/07/90)
>/ hpclapd:comp.lang.modula2 / Ernie.Bokkelkamp@p22.f1.n491.z5.fidonet.org (Ernie Bokkelkamp) / 9:07 am Aug 5, 1990 / >On 30 Jul 1990 07:50, Peter M. Perchansky (1:273/101@Fidonet) wrote: > > PP> You are correct concerning a procedure function without a > PP>return statement. > PP> > PP> JPI M2 1.17 issued a compile-time error. JPI M2 2.00 issues > PP>a run-time error. > >I have been following the messages about this subject and until this morning I did not see the real impact of this "new feature". > >I have been trying to find an error for 5 days in a small demo program converted from C to Modula-2 which runs under MS-Windows. I have been having problems with the Windows interface so I have concentrated on that area. The fault reported in ERRORINF.$$$ is "No return value for procedure" and that is all I get, the addresses are no help due to the program running under windows. >Debugging with VID can't be done, the Windows debug version does not report anything, etc. > >I found the problem this morning, I forgot a RETURN! > Sorry, couldn't resist doing this one! One look at the posting above and you will note that you forgot a lot of RETURN's - CARRIAGE RETURNS! Please, many people only have dumb 80 column terminals, so hit carriage return when you get close to column 80!
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (08/08/90)
Hello Ernie:
One of the main reasons why most Modula-2 implementations shines over other language implementations is Modula-2's strong typing.
Most errors are caught during compilation (which takes only seconds or minutes) as opposed to during run-time (which can takes months of testing before poping up).
JPI stated that they did not have enough time to implement a compile-time error for not having a return statement in a procedure (function) defined as having a return value in JPI M2 2.00 release 1.04.
I recently received release 1.05b, and they still did not implement this feature - even though it is present in JPI M2 1.17.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgErnie.Bokkelkamp@p22.f1.n491.z5.fidonet.org (Ernie Bokkelkamp) (08/13/90)
On 08 Aug 1990 07:47, Peter M. Perchansky (1:273/101@Fidonet) wrote:
Hello Peter,
PP> One of the main reasons why most Modula-2 implementations
PP>shines over other language implementations is Modula-2's strong
PP>typing.
Which isn't much help to me at the momemt ;-) The MS-Windows support in TopSpeed allows you to call Windows routines written in Microsoft C from modula-2. There are many tricks required to fool the compiler and therefor it can't do much checking.
PP> Most errors are caught during compilation (which takes only
PP>seconds or minutes) as opposed to during run-time (which can
PP>takes months of testing before poping up).
Except when you have to interface to another language like C. Here is a small section of a windows program to show you what a mess it can be:
----------------------------------------
IF hPrevInstance = Windows.HANDLE(0)
THEN
wndclass.style := Windows.CS_HREDRAW + Windows.CS_VREDRAW;
wndclass.lpfnWndProc := FarADR(WndProc);
wndclass.cbClsExtra := 0;
wndclass.cbWndExtra := 0;
wndclass.hInstance := hInstance;
wndclass.hIcon := Windows.LoadIcon(Windows.HANDLE(0),
Windows.IDI_APPLICATION);
wndclass.hCursor := Windows.LoadCursor(Windows.HANDLE(0),
Windows.IDC_ARROW);
wndclass.hbrBackground := Windows.HBRUSH(Windows.GetStockObject(
Windows.WHITE_BRUSH));
wndclass.lpszMenuName := FarNIL;
wndclass.lpszClassName := Windows.LPSTR(FarADR(szAppName));
IF Windows.RegisterClass(Windows.LPWNDCLASS(FarADR(wndclass))) = 0
THEN
RETURN Windows.FALSE;
END;
END;
hWnd := Windows.CreateWindow(
FarADR(szAppName), (* window class name *)
FarADR("Get System Metrics"), (* window text *)
Windows.WS_TILEDWINDOW (* window style *)
+ Windows.WS_HSCROLL + Windows.WS_VSCROLL,
Windows.CW_USEDEFAULT, (* initial x position *)
0, (* initial y position *)
Windows.CW_USEDEFAULT, (* initial x size *)
0, (* initial y size *)
Windows.HANDLE(0), (* parent window handle *)
Windows.HANDLE(0), (* window menu handle *)
hInstance, (* program instance handle *)
FarNIL); (* create parameters *)
IF Windows.ShowWindow(hWnd,nCmdShow) # 0 THEN END;
-----------------------------------------------------
I want to use the windows user interface because it's is superior to any other user interface I have seen. Also, I do not want to program in C as it's the worst language to read. (No flames, personal opinion) But the extra effort to write windows programs in modula-2 is weakening the advantages of modula-2.
I have found a way to improve the readability a bit by using aliases for all windows calls. I have written a file which has to be incorporated in every definition module which uses the windows library. Unfortunately I can not tell the compiler to include the file during the compilation.
PP> I recently received release 1.05b, and they still did not
PP>implement this feature - even though it is present in JPI M2
PP>1.17.
I should have my update within the next few weeks. Did you receive new manuals and new software ?
Cheers
Ernie
--
uucp: uunet!m2xenix!puddle!5!491!1.22!Ernie.Bokkelkamp
Internet: Ernie.Bokkelkamp@p22.f1.n491.z5.fidonet.orgErnie.Bokkelkamp@p22.f1.n491.z5.fidonet.org (Ernie Bokkelkamp) (08/15/90)
On 12 Aug 1990 06:16, Andy DeFaria (1:105/42) wrote: AD>One look at the posting above and you will note that you AD>forgot a lot of AD>RETURN's - CARRIAGE RETURNS! Please, many people only have AD>dumb 80 column AD>terminals, so hit carriage return when you get close to column AD>80! AD>N I will take it up with the author of the message editor I use. It should insert the CR's. The problem is not that I forgot, my messages originate in Fidonet, somewhere the conversion to USENET does not work that nicely. Cheers Ernie -- uucp: uunet!m2xenix!puddle!5!491!1.22!Ernie.Bokkelkamp Internet: Ernie.Bokkelkamp@p22.f1.n491.z5.fidonet.org
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (08/16/90)
According to JPI, new manuals will not go out to the public (ie. customers) until they are completed. Two users on JPAM, myself included, have found two errors to date in release 1.05b that will not be fixed until (at least) 1.06. If you are using Solid Software's Btree toolkit, you may get errors or warning messages when compiling using 1.05b. -- uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.org