bmcgough@uxh.cso.uiuc.edu (06/04/89)
Can someone tell me why the following is illegal ( or at least gives me an error in PD Atari ST Modula Compiler ) VAR p: LONGINT; BEGIN FOR p := 0 TO 100 DO (...) END END.
zmacu06@doc.ic.ac.uk (F S Taylor) (06/06/89)
In article <12900003@uxh.cso.uiuc.edu> bmcgough@uxh.cso.uiuc.edu writes: > Can someone tell me why the following is illegal > ( or at least gives me an error in PD Atari ST > Modula Compiler ) > > VAR p: LONGINT; > > BEGIN > FOR p := 0 TO 100 DO > (...) > END > END. > I have tried it on our SUN3/280 (running Mocka - Modula-2 Karlsruhe (I think)) and it seemed to work, the FOR loop bit that is. I trust you have a MODULE line at the top of the program like this:- MODULE name; I also noted that the END. is also missing the MODULE name. It should be like this :- END name. The code I tried was - MODULE test; FROM InOut IMPORT WriteString, WriteLn; VAR n: LONGINT; BEGIN FOR n := 1 TO 100 DO WriteString( "Hi there."); WriteLn() END END test. Apart from these syntactic points above I can't think why it wouldn't compile a FOR loop using LONGINTs as the control type. It is difficult to help further without the exact error and code. Frank. -- | Frank Taylor | Engineers often ponder upon the problem... | | DoC 1 | Why do the girls with the most streamlined shape offer | | Imperial College | the most resistance? anon. | |--------------------+--------+-----------------------------------------------| | JANET: zmacu06@doc.ic.ac.uk | All rights unreserved. |
neitzel@infbs.UUCP (Martin Neitzel) (06/09/89)
The compiler is correct. Only according to THE BOOK, of course :-) Frans van Otten mentioned a week ago that PIM3 introduces LONGINT and LONGREAL as standard types, but ignores them in the rest of the report. There are no operators for them, they are not compatible or assignment compatible to anything, and you don't have any denotations for LONG...-literals. [Not in PIM4, either.] Martin
alan@oz.nm.paradyne.com (Alan Lovejoy) (06/14/89)
In article <1249@infbs.UUCP> neitzel@infbs.UUCP (Martin Neitzel) writes: >The compiler is correct. Only according to THE BOOK, of course :-) > >Frans van Otten mentioned a week ago that PIM3 introduces LONGINT and >LONGREAL as standard types, but ignores them in the rest of the >report. There are no operators for them, they are not compatible or >assignment compatible to anything, and you don't have any denotations >for LONG...-literals. > >[Not in PIM4, either.] There are only two possible interpretations of these facts: 1) Values of type LONGINT or LONGREAL are essentially like values of type WORD: you can't operate on them. Unlike WORDs, they of course are not compatible with actual parameters whose types are not exactly the same. This interpretation is probably NOT what was intended. 2) Wirth intended that everything PIM2 says about INTEGERs and REALs should also apply to LONGINTs and LONGREALs. INTEGER and REAL should be treated as "subranges" of LONGINT and LONGREAL, respectively. Hence, INTEGER and LONGINT, and REAL and LONGREAL, are completely compatible with the exception of VAR parameters. An implementation would not be required to use different storage sizes for the "LONG-" and "short" types. Storage size could depend upon the subrange limits in a way that is transparent to the programmer (e.g, all parameters could be passed using the maximum storage size, regardless of subrange limits). This second interpretation is supported by the following considerations: a) The only other interpretation is almost certainly not what was intended. b) Since no functionality for these LONG types is specified, the most natural interpretation is that they should have the same functionality as the "short" types. c) Conceptually, the "short" types are subranges of the LONG types. Subranges are highly (but not completely) compatible with the base type and with each other. The only clear incompatibility involves actual and formal VAR parameters, which must have EXACTLY the same type. d) The compatibility/conversion rules between the "short" and LONG types were not specified. Compatibility and conversion rules between subranges and base types ARE specified, however. Using those as a model does not require introducing new features into the language. Interpreting LONGs as completely separate types DOES require new features. e) The language does NOT require that a subrange have the same storage size as the base type. But even if an implemenation used only a byte of storage for CARDINAL[0..255] but two bytes for CARDINAL[0..65535], it would still be required that the two types be fully compatible in all cases except VAR parameters. f) This interpretation results in the most natural, useful and usable implementation. Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. ______________________________Down with Li Peng!________________________________ Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.