Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
Subject: Re: Strange wierdness in E-language!
From: mneylon@jupiter.cse.utoledo.edu (Michael Neylon)
Date: 25 Jan 93 20:57:20 EST

MSAASTAMOINE@FINABO.ABO.FI (Mika Saastamoinen Tkkk) writes:
: 1st of all, there's something strange about the IF-THEN-ELSE statement: the
: following statement is supposed to plot a pixel on screen if its coordinates
: (sx,sy) are within given bounds (LFEDGE,RGEDGE,TOEDGE,BOEDGE) (ie. it's a sort
: of primitive clipping thingy):
: 
: IF ((sx>LFEDGE AND sx<RGEDGE) AND (sy>TOEDGE AND sy<BOEDGE)) THEN Plot(sx,sy,2)
: 
: Now then, guess what that did? It plots the pixel no matter what the coordina-
: tes are! And yes, I did check those boundary values, which were defined in 
: CONST statements, and they were correct! The funny thing is that when I conver-
: ted my test program to C, the above if-statement worked correctly, ie. clipped 
: the pixels within the boundaries! Now is this strange or what?

I would say that the lack of precedence is screwing this up.  You need more
parens (unfortunately)...try the following...

IF ((sx>LFEDGE) AND (sx<RGEDGE) AND (sy>TOEDGE) AND (sy<BOEDGe)) THEN blah...

(Note that I have removed a few parens as well ;).

: 
: Another thing was this: 
: 	This statement works: 		      IF tz<0 THEN...
: 	This statement crashed my machine(!): IF (tz<0 AND tz>-300) THEN...
: The 'tz' was used in a formula like this inside the IF-block: 'sx:=tx/tz' and
: it caused the guru..ehm... software failure #80000005 (I think)... Wierd?
: Again, the latter if-statement worked correctly in the C-version and did NOT
: cause any gurus...
: 

Again, lack of precedence screwed this up....The compile sees this as...

IF (tz<0 AND tz>-300) THEN ...
    ^  ^  ^   ^   ^
    1  2  3   4   5

    1. tz.  No prob.
    2. tz is less than 0, fine no prob.  Let this return 1.
    3. The result of (tz<0) AND the next value (bitwise op)
    4. Now if tz is less than 0, then a bitwise operation will probably 
	crash the computer.
    5. It then takes the result of the bitwise op and tests it against  >-300.

A better arrangment will be

IF ((tz<0) AND (tz>-300)) THEN ...


: A third thing concerns the SELECT-ENDSELECT-statement. Consider this:
: 
: 	blablabla...
: 	...class:=WaitIMessage(w)...
: 	SELECT class
: 		CASE IDCMP_RAWKEY
: 			code:=GetCode()
: 			SELECT code
: 				CASE $45 /* esc */
: 					blabla...
: 				CASE $4d /* cursor down */
: 					blabla...
: 				CASE ...
: 				    etc...
: 			ENDSELECT
: 		CASE IDCMP_INTUITICKS
: 			blablabla
: 	ENDSELECT
: 	blablabla...
: 
: Now, the wierd thing about this is that the program's execution never got
: to the IDCMP_INTUITICKS-part (yes, I did have the IDCMP_INTUITICKS-flag in
: the OpenW()-function's parameters!)!!! Also, it never got to IDCMP_RAWKEY's
: cases beyond the $4d (cursor down)!!! When I changed the order of the rawkey-
: cases, it still didn't get past the first two! Ie. in the above example,
: the program only reacted to the esc- and cursordown-keys (and yes, I did have
: all the rawkey-codes correctly!) The above routine worked only when I dumped
: the SELECTs and used IF-ELSEIF-ENDIF instead:
: 
: 	...
: 	IF class=IDCMP_RAWKEY
: 		...
: 		IF code=$45 ...
: 		ELSEIF code=$4d...
: 		ELSEIF code...
: 		ENDIF
: 	ELSEIF class=IDCMP_INTUITICKS
: 	ELSEIF class...
: 	ENDIF
: 	...

I have a feeling that E does not quite handle nested SELECT-CASE statements
well.  Now it also seems that the above IF structure is very messy, so I
would recommend the following....

	SELECT class
		CASE IDCMP_RAWKEY
			HandleRawKey()
		CASE IDCMP_INTUITICKS
			HandleTicks()
	ENDSELECT

	...

	PROC HandleRawKey()
		...
	ENDPROC

	and etc..

This should inprove your performance, and can make editing much easier (
ie, I can easily rewrite the Rawkey handlers).

: E looks like a promising language, but I think I'll still stick with C, since 
: I can at least understand how it works... Also, as many others, I too don't 
: like the one-source-file-philosophy of E, nor do I like the (upper)case-
: sensitivity of it. Other than that, it's quite easy to program the Amiga with 
: E, provided that the above mentioned wierdnesses are inside my head (and my 
: Amiga)... ;)


As I wrote someone else, the above faults in E are made up for speed in
the compiler.  For someone just begining in Intuition programming, this
is a great language to learn in, and to do a minor adjustment of the 
interface, it only requires a small change in the code, and a few SECONDS
of compile time (on a unaccel. 500!!!)


-- 
Michael Neylon   aka Masem the Great and Almighty Thermodynamics GOD!
      //         | Senior, Chemical Engineering, Univ. of Toledo
  \\ // Only the |   Summer Intern, NASA Lewis Research Center
\  \X/   AMIGA!  |         mneylon@jupiter.cse.utoledo.edu           /
Newsgroups: comp.sys.amiga.programmer