cargo@TARDIS.CRAY.COM (David S. Cargo) (02/07/90)
I was looking at the code for RSG (part of the Icon Program Library),
noticing how one part of the code takes advantage of the order of a
list of procedure variables to successively try evaluating a line of
input until one of the procedures succeeds. My first reaction was
that this reminded me of searching an object hierarchy looking for a
handler for a particular type of message. If a particular object
can't handle the message, it fails and lets the object next higher
in the hierarchy have a crack at it. It sort of reminded me of
message passing, but with a distinctively Icon flavor to it.
My real question is that I can't figure out how to decide what the
symantics of the operation really are. Normally I would expect to
say the !plist comes as element generation, which should succeed
when the first element is generated. But then it is followed by
a parameter list and surrounded by parentheses. This seems to
combine to make it an alternation expression equivelent to:
(define | generate | grammar | source | comment | prompter | error)(line)
plist := [define,generate,grammar,source,comment,prompter,error]
:
:
while in := pop(ifile) do { # process all files
repeat {
writes(\prompt)
line := read(in) | break
while line[-1] == "\\" do line := line[1:-1] || read(in) | break
(!plist)(line)
# the line above is the interesting one!
}
close(in)
}
I can't seem to find anything in the Icon book that spells out what is really
happening here. It looked at first like !plist wasn't in a context that required
generation of all the list elements, but clearly that is not the case.
The confused snail, o o
\_____/
/-o-o-\ _______
DDDD SSSS CCCC / ^ \ /\\\\\\\\
D D S C \ \___/ / /\ ___ \
D D SSS C \_ _/ /\ /\\\\ \
D D S C \ \__/\ /\ @_/ /
DDDDavid SSSS. CCCCargo \____\____\______/ cargo@tardis.cray.comralph@CS.ARIZONA.EDU ("Ralph Griswold") (02/08/90)
The procedures are generated by !plist as you surmised. The first one is then applied to the argument list, resulting in a procedure call. If that call fails, !plist is resumed to produce another procedure. Think of a procedure call as e0(e1, e2, ..., en) The order of evaluation is e0, e1, e2, ..., en. If all succeed, the value of e0 is applied to the values of e1, e2, ..., en. If the resulting procedure call fails, en, ..., e2, e1, e0 are resumed in that order (assuming they suspended). If any produces a new result, evaluation starts to the right again. In the case you cite, only e0 is a generator, so failure of the procedure call causes e0 to produce another procedure, which is then applied to the arguments. If any of the procedure calls fails, the process stops, since there is nothing to drive further generation. The effect is to apply the procedures in plist until one succeeds. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@cs.arizona.edu uunet!arizona!ralph