case statement semantic in kernel language
Peter Van Roy
pvr at info.ucl.ac.be
Sun Jan 2 23:44:29 CET 2005
Dear Marko,
I think you are confusing the 'full' case statement with the 'kernel'
case statement.
The 'kernel' case statement matches only a single record; its semantics
is given on
page 67. The 'full' case statement can have nested records (like in
exercise 6 on
page 108); on pages 82-83 it is explained how to translate full case
statements into
kernel case statements.
The definition of 'determined' is given in several places. Briefly, a
variable is
determined if it is bound to a number, procedure, or record. A formal
definition
is given on page 791. From this definition it is clear that the
record's arguments
can be unbound variables.
So I do think that the kernel language is completely formally defined in
the book,
and certainly in sufficient detail to be implemented independently!
Best regards,
Peter
Marko Zerdin wrote:
> Hello.
>
> First, let me thank Peter and Seif for a great book, and all Oz gurus
> for this most amazing language that you created. Second, I want to
> apologize for posting this question here. It is strictly the book
> question, but I wasn't certain where else to post it.
>
> In CTMCP, I've noticed a puzzling incompleteness of the case statement
> semantic (on page 67) while trying to solve some of the exercises. I'm
> sure I'm missing something somewhere along the way, so I would
> appreciate it if somebody could follow through with my reasoning and
> point to me what's wrong with it.
>
> First, the book says that the activation condition is true if the test
> expression is determined, but doesn't specify what exactly
> "determined" is supposed to mean in this case. Based on the observed
> semantic of the case statement (clearly demonstrated by exercise
> 2.6), the expression does not need to be fully determined for the
> option to be chosen (second case), but knowing only the record label
> and arity is also not enough, which is what would follow from semantic
> description. So what exactly is the activation condition?
>
> Second, according to the semantic on page 67, the alternative to be
> taken is decided solely based on both expressions' record label and
> arity, which is quite obviously not at all what is actually happening.
> Let us assume that the label and arity both match, and therefore the
> alternative is chosen. The interpreter is supposed to create a new
> environment now, binding the values of all features in both records. A
> few fundamental questions remain unanswered: What happens at the point
> of creation of the new environment if one of the bindings fails? As an
> alternative answer to the previous question, how exactly and when are
> the bindings performed, and how exactly do they influence the
> alternative selections process? The alternative is surely not
> determined solely based on record label and arity, so how exactly is
> it determined?
>
> I understood from the book that the kernel language definition is
> supposed to be complete and should be simple enough to be implemented
> independently for pedagogical purposes. However, I'm quite certain
> that no such implementation could be done based solely on the
> information that can be found in the book. Therefore, I would really
> appreciate if you could give a full semantic of the case statement
> upon which a determined and compatible implementation of the kernel
> language could be based.
>
> Kind regards,
>
> Marko Zerdin.
More information about the mozart-users
mailing list