The targets for version Plov011 were rather high:

Enable inline PALO code
Enable procedure parameters

but this was all clearly too far fetched. I started out with the inline PALO option. At current, with the current PALO this is rather cumbersome. You cannot just have two keywords (a PALO/END pair) that accepts everything in between. The PALO code needs to be checked. For that, a PALO code checker would be required.
I tried to make one, but it would add more than 200 lines of code to the current source. There were two reasons to skip this option, for the time being:

PALO is too complicated
PALO checking NEEDS to be done since ALTO requires correct source
The PALO checker would need to do full symbol checking
Labels would be very difficult to check

So after considerable thought I decided to skip the option for inline PALO. Instead, there will be intrinsic functions inside Plov such that inline PALO will be unnecessary.

The function parameters are also one bridge too far. At present this would be rather difficult to implement. The major problem is related to the fact that function parameters are optional, so the end of line token playes a key role again. I keep this option for the future. IF it will be implemented the function parameters will be implemented as local variables.

I added quite some code for the PALO checker, even opened a new memorypool to store the PALO codes for easier checking. In the end I concluded that

inline PALO is no necessity
the current PALO is too complex

So there will be a revision to the PALO code. That will be the target for Plov012. Still, I managed to make type checking a lot easier, so the StamentSequence procedure could be simplified. For this, I made a cunning procedure called findType which is explained below.

The old version of StatementSequence was:

PROCEDURE StatementSequence;

BEGIN
   GetSymbol;
   LOOP
      CG ("");
      IF  weHaveLocals AND (FindLocal (token) = TRUE)  THEN
	 IF     thisLocal^.type = Vartype       THEN  Assignment  END
      ELSIF  FindSymbol (token) = TRUE  THEN
	 IF     (thisSymbol^.type = Vartype)    THEN  Assignment
	 ELSIF  thisSymbol^.type = Proctype     THEN  Procedurecall
	 ELSIF  Strings.StrEq (token, "IF")     THEN  isIF
	 ELSIF  Strings.StrEq (token, "LOOP")   THEN  isLOOP
	 ELSIF  Strings.StrEq (token, "RETURN") THEN  isRETURN
	 ELSIF  Strings.StrEq (token, "WHILE")  THEN  isWHILE
	 ELSIF  Strings.StrEq (token, "REPEAT") THEN  isREPEAT
	 ELSIF  Strings.StrEq (token, "EXIT")   THEN  isEXIT
	 ELSIF  Strings.StrEq (token, "END")    THEN  RETURN
	 ELSIF  Strings.StrEq (token, "UNTIL")  THEN  RETURN
	 ELSIF  Strings.StrEq (token, "ELSIF")  THEN  RETURN
	 ELSIF  Strings.StrEq (token, "ELSE")   THEN  RETURN
	 ELSE
	    ErrorMessage (10)		(* Error in StatementSequence   *)
	 END
      ELSE
	 ErrorMessage (9)               (* Undefined symbol     *)
      END
   END
END StatementSequence;

The first four lines after CG ("") are too complex. They were necessitated by the introduction f local variables, which live in their own memorypool. In order to simplify this (symbol checking would be a major task in inline PALO checking) I created the findType procedure:

PROCEDURE findType (name   : Identifier) : SymbolType;

VAR     symPtr          : SymbolPtr;

BEGIN
   IF  weHaveLocals AND (FindLocal (token) = TRUE)  THEN
      symPtr := thisLocal
   ELSIF  FindSymbol (token) = TRUE  THEN
      symPtr := thisSymbol
   ELSE
      RETURN None
   END;
   RETURN symPtr^.type
END findType;

This function takes some of the gobbledygook away from StatementSequence and other procedures that need to perform typechecking of symbols. What it does is:

IF weHaveLocals AND the token seems to be a local one, symPtr points to it
but IF the token is a global symbol, symPtr point to that one
In all other cases, we return a new symboltype: None
When succesfull, the type of the symbol is returned to the calling function

SymbolType      = (Progtype, Proctype, Constype, Vartype, Keytype, None);

The new findType function was succesfully implemented in the new StatementSequence:

PROCEDURE StatementSequence;

BEGIN
   GetSymbol;
   LOOP
      CG ("");
      IF     findType (token) = Vartype 	THEN  Assignment
      ELSIF  findType (token) = Proctype	THEN  Procedurecall
      ELSIF  Strings.StrEq (token, "IF")  	THEN  isIF
      ELSIF  Strings.StrEq (token, "LOOP")	THEN  isLOOP
      ELSIF  Strings.StrEq (token, "RETURN")	THEN  isRETURN
      ELSIF  Strings.StrEq (token, "WHILE")	THEN  isWHILE
      ELSIF  Strings.StrEq (token, "REPEAT")	THEN  isREPEAT
      ELSIF  Strings.StrEq (token, "EXIT")	THEN  isEXIT
      ELSIF  Strings.StrEq (token, "END")	THEN  RETURN
      ELSIF  Strings.StrEq (token, "UNTIL")	THEN  RETURN
      ELSIF  Strings.StrEq (token, "ELSIF")	THEN  RETURN
      ELSIF  Strings.StrEq (token, "ELSE")	THEN  RETURN
      ELSE
	 ErrorMessage (10)		(* Error in StatementSequence	*)
      END
   END
END StatementSequence;

I think this procedure is more in the line of Modula-2. It looks neat, does the job and is easier to understand.

At present, PALO is too complex. It is too 'chatty'. Too clear. It does not comply with one of Wirth's laws:

Make it as simple as possible,
but not any simpler

Some people claim that a guy called OneStone made this rhime, but he is not part of the geniusses in this world. So I prefer to acclaim this proverb to Wirth.

PALO needs to be simplified without loosing it's readibility. More in Plov012 and the PALO/ALTO section.

Plov012 has been created and runs stable. Which shouldn't be too strange since only a few lines of text have been changed. Plov012 puts out PALO-2 codes. For more information, I refer to the Palo/Alto section on this topic. Use the navigator frame to get there.

Page created on 11 September 2008 and

Page equipped with FroogleBuster technology

Make it as simple as possible, but not any simpler

Make it as simple as possible,
but not any simpler