Re: Semantics of Multiple Values

Hi.

I thought since you said you don't know about Prolog, I'd say something about
it and unification, since it's interesting. Feel free to ignore this, though.

Prolog is a logic programming language, and as such, doesn't have functions
per-se.  Instead, it has predicates, which are either true or false. So, for
example:

plus(0, 0, 0).
plus(0, 1, 1).
plus(1, 0, 1).

Are three predicates that are true. The first one means 0 + 0 = 0, the
second means 0 + 1 = 1, and the third means 1 + 0 = 1 (at least, it could
mean that. It could mean many things, really).

Now, with Prolog programs, you can define what's true for constants, like
above, but that doesn't get very interesting. More interesting is defining
what's true for variables. So for example, you can define Pythagorean
triples like so:

ptriple(X, Y, Z) :-
  X2 is X*X,
  Y2 is Y*Y
  Z2 is Z*Z
  Z2 is X2 + Y2.

Now, when you write

ptriple(3, 4, 5)?

Prolog unifies X2 with X*X and so on, and finally it checks that
X*X + Y*Y = Z*Z, and finds it's true, so it prints "yes" or something like
that.

However, unification is more powerful than that. With unification, you can
specify variables in your ptriple "call" and Prolog will search for values
that make it true (assuming ptriple is written correctly, which it is). So,
you can do:

ptriple(3, 4, Z).

And it will determine values of Z for which ptriple is true. Similarly, you
can do

ptriple(3, Y, 5).

And it will determine values of Y for which ptriple is true. This is quite a
bit different from all the procedural and functional languages that I
personally know, because in all of those, you have to specify which arguments
are in-parameters and which are out-parameters beforehand, but with Prolog,
if you write your predicates properly, any variable can be an in or out
parameter.

Having similar functionality in Ruby would be interesting. I don't know if
it's feasible, since unification algorithms aren't particularly easy to write,
and I don't know if it would fit with the other aspects of the language. The
proposed unification seems like a subset of the full functionality of
unification anyway, though, so that might be feasible.

The other proposition here is pattern matching, which is also in existing
programming languages. Haskell has pattern matching. For example,
lists can be built like so:

a : list

Where a is an element, list is a list, and ':' is the cons operator. However
when writing list processing routines, you don't need to take a list and
call head and such. What you can do is:

f (x:xs) = ...

And because of Haskell's pattern matching, if you pass something that is a
cons of an item and a list, the item gets assigned to x, and the rest of the
list gets assigned to xs. You can also do more complicated things where you
assign the whole list to a variable, but still assign heads and tails to other
variables and so on.  I don't know if Matz would want to take the time to
implement such functionality, but it can be done.

Anyhow, that's it for my language theoretic tangent of the day. If any of this
was interesting, I might suggest learning a little about Prolog or Haskell.
The Art of Prolog is purportedly good (I have it, but haven't gotten around to
reading it yet), and there are several pretty good Haskell tutorials on the
internet.

Have a nice day.

- Dan