This is to note issues that come to mind wrt converting from
Pascal to other languages.


(1) VAR arguments (ie call by reference rather than by value). This only
arises in the TeX source in support of file access, and that is an area
liable to require radical overheal in any event.

(2) EXIT returns from the current procedure. This is an issue in that in
Lisp RETURN just exists from the current block. I may use the Common Lisp
style RETURN-FROM to cope with this. An alternative approach that is beyond
vanilla Standard Lisp but which would work with both CSL and PSL would
be to use CATCH and THROW. In that case it would seem desitable to optimise
out cases where there were not any nested PROG blocks and so a simple
RETURN could be used. My best bet is to generate block/return-from code and
then have a further pass that in the PSL case maps that onto catch/throw.
Ahahah - when I scan tex.p I observe that there are no instances of EXIT and
so the concern here does not arise! Whew.

(3) A Pascal function specifies its return value by assigning to a pseudo
variable named as the function is. Such assignments can be performed anywhere
within the function. So any function will need to map onto
   (de foo (args)
      (block foo (prog (foo)
         ...
         (setq foo RETURNVALUE)
         ...
         (return!-from foo foo) % exit!
         ...
Common Lisp would have made the block with tag FOO implicit in the
definition of the function. But note that because in tex.p there are no
early exist from procedures I can use a simpler form:
   (de foo (args)
      (prog (foo)
         ...
         (setq foo RETURNVALUE)
         ...
         % End of main procedure body here
         (return foo)))

(4) The TeX source has (a very few) labels that are jumped to in a non-local
manner. For instance the procedure JUMPOUT has as its body just "GOTO 9998"
where the label is set in the set of statements at the end of the code. I
think that the GOTO statements and label settings involved will need to
be detected and mapped onto CATCH/THROW for Lisp (or setjmp/longjmp for C!).
This can be helped because there is a top-level declaration of the
labels involved at the head of the program.

(5) Records are an issue. I will need to capture the record declarations
so if I have one that declares a record of type A with fields B and C I
should create
   symbolic inline procedure A_get_B x
      getv(x, 0);
   symbolic inline procedure A_set_B(x, v)
      putv(x, 0, v);
Or perhaps since I am translating into Lisp the record should map onto
a list, using car, cadr etc as accessors.
Then when I am processing code I will need to track which variables have
types that are records, and sometimes map "a.B" onto A_GET_B(a) etc.
The treatment of record declarations is liable to be rather easy. The
processing of field acccess will depend on autgemting my translation
step to carry some amount of type information, and once that is done
it also becomes straightforward.
Well variant records will need further care. As far as I can see the Pascal
for TeX does not use variant types (only variant records). It also does not
seem to use the "with" construction, so all access to components of records
will be directly and clearly visible. Furthermore the variant records that
it uses are free unions (ie no tag field is used, so the behaviour is basically
just like and as insecure as C unions). The examples used are
      twohalves = halfword, (halfword | byte, byte)
and   memoryword = integer | real | twohalves | fourquarters
and these rely on twohalves and fourquarters being packed records. It is
jolly clear what the intent of these is! Arranging translation that is
based on some generic scheme rather than an utterly hacky detection of
these as special cases is potentially a bit delicate. so I MAY end up
with specialist hand-crafted treatment!

(6) Type-punning via variant records. I believe that when TeX uses the
variant record "memoryword" and will keep an integer, a 32-bit float,
two halfwords or 4 bytes in it. And that it expects those all to alias at
least via saved files that dump system state where all those variants
should end up dumped as just 4 bytes...
OK so let me comment further. The array mem[] is an array of memorywords.
Its contents get written out using the code
                  For k:=p To q+1 Do
                    Begin
                      fmtfile^ := mem[k];
                      put(fmtfile);
                    End;
and for fmtfiles to agree with ones generated by TeX that expects each
word to be written as just 4 bytes. That means that the format file does not
contain localised information about the types present in mem[]. On a
subsequent run the mem[] array is re-loaded with code that mirrors that which
wrote it out. So at that stage its contents are "32-bit values" and one can
not tell what will later be used as an integer and what as a float.

I think that all means that I will need to handle unions like that as
integers within my Lisp code. I can use shifts and masks to access
halfwords and bytes, but injecting and projecting single precision floating
point is going to be ugly (to say the least). I will take the attitude that
I will not need to consider Sub-normal numbers, Infinities or NaNs and that
performance will be unimportant, so I will just go ahead and cope.

All this is really elaborating on what I have already said about the use of
a free union for memoryword.

(7) An identifier present within an expression could denote call to
a function that does not take any arguments, or it could be reference
to a variable. Context information needs to resolve this.



@end of file@
 
