[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

statements as zero-value forms (expressions vs. statements)

  Is a statement just a form that produces zero values?
  What kinds of values mismatches do you want the compiler to tell you
  How do statements help with that?

In the general case, each expression of a language produces zero or
more values (P), and is used in a context in which zero or more values
are expected (E).

#P < #E: 
One might find it nice to have the compiler tell you that the types of
P don't satisfy E (e.g., if the number of values produced, #P, is less
than that expected, #E).  I can't think of any reason that one
wouldn't want this -- it seems that no expressive power is lost by
having the compiler check this.

I'm not sure why it would be useful for this task (or easier on the
compiler writer) to have a kind of form known to produce exactly zero
values.  For example, even though C has only zero-value and one-value
forms, it treats zero values as a kind of type to be checked (void).
Shouldn't that be sufficient to tell you if you are supplying too few

#E < #P:
It is less clear that you want to be told whenever extra values are
being ignored.  Suppose you do want such warnings. (Why? When,
exactly?)  Suppose further that the case of zero values is somehow
(e.g., in a language without multiple values).  Finally, suppose that
explicit declarations that you know that values are being ignored are
too onerous.  Then maybe statements make sense.

Am I oversimplifying?  

For example, Common Lisp introduces the concept of a "primary value"
(in some contexts where #E is 1, an empty P is equivalent to NIL) -
which gives up the ability to make the too-few-values check for the
most common and important case: variable and argument
binding/assignment.  Heck if I know why.  But the point is that #E=1
is treated special: maybe there are other places it should be treated
special, and that leads to statements in a language?

Similarly, Icon seems to treat the 1 and 0 cases specially (success
and failure).

By the way, note that there are LOTS of ways of avoiding the 'if (x=0)
....' problem without influencing our statement vs expression
question (summarizing from those already mentioned):
  * Provide a clear syntax for assignment, such as 'x := 0' or 
    '(setq x 0)', or '{set x = 0}' or ....
  * Having a disjoint boolean type, though this still allows the rather
    mistake of assigning a boolean.
  * Having the assignment operator produce zero values, though this
    makes it harder to chain assignments (x = y = z = 3) unless the
    whole thing is recognized as a single operation (as someone
    mentioned for Perl).