🚀 go-pugleaf

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