Jorge Marques Pelizzoni wrote:
Hi, there!
But ok. Now, the scary thing is when the following is fed:
declare
X = l(f:1)
local F in
case X of l(F:V) then {Browse F#V} end
end
where F is clearly introduced, but unbound, and the interpreter crashes
with lots of curses (Mozart 1.3.2, Fedora).
Well, it's true that the emulator does not react in the most graceful
manner there. That's a bug, if only in error reporting :o)
I did not say that was a bug, though I can't imagine this behaviour was
designed purposefully.
Anyway, the
case statement simply does not work the way you want it to.
That's clear. It won't do what I want, and it does not do what I'd
expect in this particular situation, given that case does not work the
way I'd like it to work.
If you use a
variable as a feature name, it should be already bound to some atom or
integer. At most, if the variable is free, what might be expected as
correct behaviour is either a more informative error message or that the
case statement should block until the variable gets bound.
Yes, one of these should happen. Perhaps suspension would be better than
an error message; using an unbound variable for a label or feature in a
pattern does not really seem to me to be worth classifying as an error.
I for one cannot see the point of the extension you propose nor know of
of any other language supporting this.
Well, why not Oz? Seriously, you may of course encode any message by
using a fixed set of labels and fields, and having only the values
variable, or even unspecified; then you can design pattern matching for
capturing just the values. But for prototyping, I found it convenient
to be able to ignore the wrapper (the label/features of a record) of a
message and get just the content (values; so the pattern _(_:V) might be
useful, for example), or be able to print out the wrapper
(label/features) and ignore the values (so the pattern L(F:_) would be
useful). Surely, this can be done with procedures from the Record
module. Just wishful thinking.
In special, a pattern like
l(F:V ...) would be intrinsically non-deterministic, don't you think?
Perhaps you should first explain what 'intrinsically non-deterministic'
means to you.
Thanks for the comments.
vQ
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
