Henning Thielemann <iakd0@[EMAIL PROTECTED]
> wrote in message
news:<Pine.A42.3.96.1030902183842.56002B-100000@[EMAIL PROTECTED]
>...
> Here is another philosophic consideration of Modula 3 syntax: :-)
>
> TYPE
> MinArgs = RECORD x, y: INTEGER END;
> MinProc = PROCEDURE MinArgs OF INTEGER;
> (* or just *)
> MinProcI = PROCEDURE RECORD x, y: INTEGER END OF INTEGER;
> (* the same signature in ARRAY form *)
> MinArr = ARRAY INTEGER OF ARRAY INTEGER OF INTEGER;
>
> Nice, isn't it?
Some seven years ago I played around with a threaded interpreter
written in Modula-3 for Modula-3. To make a Modula-3 type, variable
or procedure available in the interpreter runtime, each had to be
enclosed in its own wrapper procedure.
UW's Spin project included a new generic procedure type PROCANY, but
only to test a generic procedure for its inclusion in a value of type
INTERFACE_UNIT or MODULE_UNIT. What I wanted to do was have some form
of APPLY procedure to a value of a PROCANY type, but I wasn't able to
figure out a clean way of doing it.
Where as most procedures are implemented in object code by placing the
operands on some form of internal stack followed by calling the
subroutine defined by the procedure, it seemed inefficient to have to
define another run-time stack for implementing procedures to be made
available on the interpreter. Executing such a procedure required
peeling off the operands from such a stack and placing them in some
form of record structure unique to each procedure, and then calling
the procedure itself which then places the same operands on another
inaccessable internal operand stack .... I wasn't able to figure out
a clean way of doing that either, though I did offer some proposals in
this group.
However, this whole argument may be moot. Procedure-valued types and
expressions are considered security and possible type safety risks.
Microsoft's C# language replaces them with a DELEGATE construct that
is supposed to address these issues, though I currently am not savvy
enough to figure out how. --leeo
|
