gert@prls.UUCP (04/29/87)
In article <8704250326.AA03572@ucbvax.Berkeley.EDU> CS117205@YUSOL.BITNET writes: >I have a set of procedure functions which return vector records (specifically >state information data structures). Well, I stick my definition module >which contained the aforementioned procedure functions, through the compiler, >and guess what I get? A lovely little error 88 in those procedure functions. >I look up in the manual and it says that an error 88 is "function type is >not scalar or basic type". Why does TDI assume that I will never need to pass >a descriptor between modules? That really infuriates me, especially after >what I spent for the original version and then the second upgrade. The above limitation cannot be blamed on TDI. The Modula-2 original language definition (in Wirths book) specifies that the result of a function procedure cannot be a structured type (pg. 52 in my book). Yes, this is an unfortunate limitation, done to make a more simple implementation possible, no doubt. It is easily circumvented by making your result be returned as a var parameter of a procedure instead of as a function, or by returning a pointer to the structure. > The other thing is sets. Why does Modula-2, limit me to only 128 >elements in a large set? What if I was creating some routines which >required set elements greater than that number (for example the ASCII >character set)? From the TDI manuals (in both version 1 and 2), I quote : the maximum nr. of elements in a set is 65.536 (the largest set hence requires 8 kBytes of storage). Set expressions used as parameters are limited to 32 element sets. There are however some implementation errors with sets that I heard about, I think especially with setconstant compilation. These bugs are supposed to be fixed in version 3. In a recent other article, someone was complaining about a 'REVERSE ADDRESS' error occurring in the linker. This is indeed a nasty bug, especially since it occurs in the linker which makes identification of the cause difficult. By experimenting, I found out that this bug is (a.o.?) triggered by a 'large' CASE statement in the source, whose codesize causes overflow of the codebuffer for a procedure (undetected in the compiler). The linker then crashes, displaying address error. So, if your program triggers this bug, replace case statements by if- then-else sequences (for which overflow is detected) or split the procedure that contains them into multiple smaller ones. The problem in my case occurred with a case statement of 26 (or more) alternatives, each alternative consisting of 5 procedure calls, so approx. 130 statements... Just thought that my favorite programming environment on the ST deserves some defense. Yes, it unfortunately has bugs, but I manage to live with them until solved in the next release. I just don't like the pricing policy, which causes updates to be almost half the price of a new version. This constitutes an invitation to commit a crime. Gert Slavenburg