From: neilg@cs.hw.ac.uk (Neil MG Gall)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
Subject: Re: Strange wierdness in E-language!
Date: 28 Jan 93 13:24:57 GMT
Organization: Department of Computing and Electrical Engineering, Heriot-Watt University, Edinburgh

In article <1993Jan25.160550.9255@abo.fi>, MSAASTAMOINE@FINABO.ABO.FI (Mika Saastamoinen Tkkk) writes:

** 
** 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?

Not really.  All expression evaluation in E is done left-to-right: THERE
IS NO OPERATOR PRECEDENCE.  So your expression actually is evaluated as:

	IF ((((sx>LFEDGE) AND sx)<REDGE) AND sy)>TOEDGE) ...

which is obviously a load of cack.  What you want is

	IF (sx>LFEDGE) AND (sx<RGEDDE) AND etc...

* Another thing was this: 
** 	This statement works: 		      IF tz<0 THEN...
** 	This statement crashed my machine(!): IF (tz<0 AND tz>-300) THEN...

Same problem.  Crashing might have been due to tz>-300 -  try tz>(-300)
Sorry - I can't help you with the SELECT..ENDSELECT problem.

** 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.

I downloaded E this week, and spent Monday evening perusing the documentation,
and trying out a few examples.  I *WON'T* be using E (at least until a better
version comes out) for the following reasons:

	* NO OPERATOR PRECEDENCE
	  this leads to really messy expressions, as well as confusing
	  people - look at the example above

	* NOT STRONGLY TYPED
	  weak typing in a procedural language is plain confusing, and
	  anyone who's used C++ will know that strong typing finds a large
	  proportion of programming errors at compile time

	* ONLY ONE SOURCE FILE
	  so useless for programs bigger than about 10Kb
	  
	* NO COMPILATION TO OBJECT FILES
	  how are you supposed to link code written in E with code written
	  in C ?  If E created .o files, then you could get the linker to
	  generate overlays, etc too.

	* SHITE PARSER
	  the parser should **NOT** decide what an identifier means by
	  the case of its letters - come on, get out of the stone age.
	  Along with this comment I should say, case sensitivity is fine,
	  but reserved words should be lower case.

	* I HATE THE WORD PROC
	  never liked BBC Basic.  Are the keywords PROC..ENDPROC really
	  needed ?  what's wrong with: function_name()...end;

Apart from these, there are some really neat features of E, like the
AmigaDOS integration, exception handling etc.  If an OOP version becomes
available, with operator precedence, strong typing, more than one source
file, a good parser, compilation to object files, and *proper* object
orientedness (word?) (ie: friend classes, operator overloading, multiple
inheritance etc) then I would program some of the more boring parts of
my programs in it (the tricky bits I would stick to C for, at least until
I was sure that E was up to the job).

All in all, I was sort of glad that E wasn't up to scratch - you don't
pay 120 quid to upgrade to SAS/C 6 for it to be made obsolote by a PD
package, do you !?!

I heard someone say "Can't wait til GadToolsBox can output E code".  If
E was more professional, GadToolsBox wouldn't need to.  You just compile
the C code, and link with E program.

+-----------------------------------------------+------------------------+
|  Blessed are they who Go Around in Circles,   |     Neil M.G. Gall     |
|      for they shall be known as Wheels.       |   neilg@uk.ac.hw.cee   |
+-----------------------------------------------+------------------------+