> Can I basically define functions multiple times... this is (IMO) the
> clearest way to define recursive functions.
Yes, you can define functions multiple times.
There are two ways of defining each instance of a function:
a simple function, or a meta.
When you define a simple function, Pliant will use the arguments type to
check weather the function can be applyed (so this is the very classical
type based unfication mecanism). It also provides a clever casting mecanism
so that if several can be applyed with different castings, it will select the
'best' one (the one that call the less casting functions on each argumennt)
if there is one, or send an ambigious compile time error if none is the best
one.
When you define a meta, the code of the function will decide at compile
time weather the function applyes, so you have more flexibility (you have
all unification mecanism power and even more) but the code is much bigger.
Now the set of definitions of a function may mix simple and meta definitions,
and you can even add some 'strong_definition' or 'weak_definition' attributes
to some of the definitions in order to avoid ambiguities when several
definition can apply.
> Does Pliant, either in basic form or via the meta system, allow for
> something like functional/declarative languages multi-lined or-clauses.
No, but it could be added as a module (same as a library).
Do you expect to use a Prolog like clauses definition mecanism that would
work on classical programs (unification is used only on the left part
of each clause), or do you expect to use unification as the basic computing
macanism (just like in Prolog) ?
I will now elaborate this question in the end of this answer:
In the first case, you just want an additinal notation for Pliant functions,
whereas in the second case, you want a full logical programming engine.
So, in the first case, we could define 'clause' Pliant meta that would allow
such a definition:
clause fact Int -> Int
0 -> 1
n -> fact(n-1) * n
Please notice that this is a strong reason for using Pliant default syntax
rather than a C or C++ cloned ones because you see here that Pliant default
syntax is general enough (orthogonal for technical readers) so that you can
use it efficiently for logical programming also. On the other hand, one
common problem with C or C++, if you define a logical programming library,
is that the C or C++ syntax will not work for logical parts, so at the end
you'll have two very different syntaxes for a single application (the same
also apply for SQL statements which are also logical programming).
Now the key difference in the second case is that in Prolog, arguments
unification appends at run time, whereas with Pliant, just like with all
procedural languages, it appends at compile time.
In other words, in Prolog, unification is the computing mecanism, not the
compiling mecanism.
So, if we want a Prolog engine within Pliant we have to:
- define the data type used to strore Prolog expressions (basicaly the
same as Arrow data type with no reference count)
- build a garbadge collector for this data type
- build an unification mecanism for this data type
None of these is hard, and none of this requires to change anything in
Pliant: it only needs a few extra Pliant modules.
What's generaly not known is that:
- there are many possible unification mecanisms. The one introduced in
Prolog is only a simplest one, but you may have more powerfull, more
abstract and more complex ones.
- a garbadge collector is not optimal for deciding when to free Prolog
expressions, because some will never be used due to Prolog rules on
the clauses set exploration, so some expressions that we know that
will never be used any more are not freed.
As a summary, Pliant core is a compiling engine, whereas Prolog is a
computing engine. So, you may well define the Prolog like computing engine
within Pliant, but the Prolog success made many people think that there is
a single possible one whereas there are many possibles and interresting ones,
and each of them is very well suited (because it's expression power is very
high) ... for a very narrow set of applications, so there are typical
extensions that will be added to Pliant over time, and will be written as
external modules (possibly available from a central site) because they are
not interresting for the mainstream.
|