in, out, and outn as built-in procedures

[t***@engmail.uwaterloo.ca]

For a4q2 and a4q3, can we implement in, out, and outn as built-in procedures?
i.e. may we simply consider the in, out, and outn keywords to be names of
built-in procedures which can be used in precisely all the ways in which
procedure names may be used in procedure calls? I think this would be much
more intuitive and versatile than considering them to be special statements
that happen to look like procedure calls, which is how the SL spec currently
treats them.

For example, in this implementation the sensible code that Ron Chan showed
would be allowed ("a[4] <- in();", "for (x <- in(); !y; z <- z + 1)"), among
other things ("int a; a <- in() + 4;", "void blah(char a) begin ... end; ...
begin blah(in()); end;", etc.). The grammar would also, of course, be simpler,
though the correct number of parameters to these three built-in functions
would then be best left to the semantic analysis stage, just as with other
procedure calls.

Also, if this isn't a reasonable design, then why were in, out, and outn
changed to look like procedure calls in the first place? If it's unreasonable
to treat them like procedures, then shouldn't it be unreasonable to make them
look like procedures?

----------------------------------------
This mail sent through www.mywaterloo.ca

[Nguyen Nguyen]

It would be perfectly reasonable to treat in, out and outn as built-in
procedures. In fact, I believe this is the way they were usually handled
in previous terms.

However, the assignments and the SL specification change every term.
This term, in, out and outn are statements. You are of course free to
implement them any way you like. Just don't be surprised if you don't
receive full marks. I haven't seen the test cases, but I expect they will
be testing that your grammar follows the current SL specification.

Even though in, out and outn are statements, the fact that they look like
procedures is not counter-intuitive. You could argue that from the
high-level view of a user (programmer), there isn't much difference
between a special statement and a built-in procedure (one he/she doesn't have
to write). These statements look they way they do to simply indicate to
the programmer what they do.

Nguyen

Post by t***@engmail.uwaterloo.ca
For a4q2 and a4q3, can we implement in, out, and outn as built-in procedures?
i.e. may we simply consider the in, out, and outn keywords to be names of
built-in procedures which can be used in precisely all the ways in which
procedure names may be used in procedure calls? I think this would be much
more intuitive and versatile than considering them to be special statements
that happen to look like procedure calls, which is how the SL spec currently
treats them.
For example, in this implementation the sensible code that Ron Chan showed
would be allowed ("a[4] <- in();", "for (x <- in(); !y; z <- z + 1)"), among
other things ("int a; a <- in() + 4;", "void blah(char a) begin ... end; ...
begin blah(in()); end;", etc.). The grammar would also, of course, be simpler,
though the correct number of parameters to these three built-in functions
would then be best left to the semantic analysis stage, just as with other
procedure calls.
Also, if this isn't a reasonable design, then why were in, out, and outn
changed to look like procedure calls in the first place? If it's unreasonable
to treat them like procedures, then shouldn't it be unreasonable to make them
look like procedures?
----------------------------------------
This mail sent through www.mywaterloo.ca