Visual Prolog
Rocki Stenger
Jose A. S. Alegria had a few questions about Visual PrologVisual Prolog is not (yet) ISO complient, though we fully supported the
standardization effort.
VIP has static typing, does not support operator definitions, does not
implement dcg-expansion, and in general, since it is a native code
compiler, it does not support the metalingustic constructs that tend to
rely on some capability for decompilation (interpreters, p-code
systems). The multipass compiler uses warren-like abstactions on the way
to emitting standard machine code, the type system and flow analysis
allow the compiler to treat most forms of unification more efficiently,
although 'normal' unification is used where such optimizations are not
possible. Backtraking and other control semantics work as usual. That
one of the supplied example programs is a fairly standard Prolog
interpreter demonstrates that any of the above deemed missing can be
modelled pretty easily.RegardsJonathan Lerwill + Michael Alexander (PDC Atlanta)
sup...@pdc.dk
[...]
>VIP [...] does not implement dcg-expansionIncidentally, ISO Prolog does not include DCGs. So while lack of DCGs
is an incompatiblity with traditional (Edinburgh) Prolog, it's not an
incompatibility with ISO Prolog.The ISO Prolog committee wanted to standardize DCGs, but the problem
was that they couldn't agree on an operational semantics. The
declarative semantics were clear, but they couldn't come to any
agreement on precisely how to treat DCGs containing non-logical code.--
Fergus Henderson "I have always known that the pursuit
WWW: of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 -- the last words of T. S. Garp.
Richard,Could you post pointers to papers or other documentation on Mercury's
type system and implementation? Is Mercury a WAM based
compiler/interpreter? How does it compare to Sicstus in terms of
speed?
Well, they promise ultra fast performance without GC overhead (they
don't need it ?!). This high performance and well behavied memory
system allow them to compete with VC++ in developing "efficient"
Windows apps. Or, so I was told.Regards,Jose A. S. Alegria
Work: Home:
>Could you post pointers to papers or other documentation on Mercury's
>type system and implementation? Is Mercury a WAM based
>compiler/interpreter? How does it compare to Sicstus in terms of
>speed?
Check out the Mercury home page: is not a *Prolog* system. It uses Prolog compatible syntax, but is
a new purely declarative language. The compiler for Mercury that we have
written make use of a new execution algorithm, not the WAM. Our execution
strategy allows for much more aggressive low level optimization, and the
purely declarative nature of Mercury allows for much more aggressive
high level optimization.Our benchmarking shows Mercury to be just under twice as fast as
Aquarius Prolog, and about four times faster than SICStus Prolog.Acutally, the ratio of the speed of the Mercury compiler running under
SICStus Prolog and the Mercury compiler running under Mercury is more
than that - I don't have hard data at hand, but the Mercury version is,
I think, more like 8 times faster.pax
Thomas
Acutally, the ratio of the speed of the Mercury compiler running under
SICStus Prolog and the Mercury compiler running under Mercury is more
than that - I don't have hard data at hand, but the Mercury version is,
I think, more like 8 times faster.
I think Thomas Lindgren is pointing out something I heared around
from a fairly large number of people involved in logic programming.
Basically, giving away expressiveness for speed is _wrong_.
Giving up Prolog for less expressive languages for reasons
of speed, types/modes, proprietary visual tools etc. is _wrong_ too.
Some history might help on this.For many `real' Prologers today Turbo-Prolog is `out' and Mercury `in'.
Novelty and Fregus Henderson's well-targeted postings have definitely
helped Mercury, as well as our fascination with speed on some popular
functional-programs-in-relational-form (tak and friends) benchmarks :-)I should agree that there's a lot of inventive implementation skill and
talent involved in Mercury. I do not know about the latest version of
Turbo-PDC-Visual `Prolog'. Except for the fact of not supporting
meta-programming and having a too limitative type system it also seemed
to be a well implemented language with its own merits. It had a fairly
effective mode inference algorithm, among other things. And it was
really `in', for a while.I think that the two languages have much more in common than what
separates them from Prolog. Basically, they have given away
expressiveness for speed. By the way, the two languages should, at
some point, be compared empirically on speed, program size and size of
standalone executables on both functional style and nondeterministic
programs. Any volunteers having both implementations around? Mercury
on Linux vs. PDC on W95 or NT looks fair enough to me.It is likely that the designers/implementors of the two languages have
(independently?) got attempted to push static compilation techniques to
their limit while giving away, little by little, some of the key
features that make `real' Prolog so appealing: logical variables,
unification, the 5 lines meta-interpreter etc.Not only purity was given away but the fancy parts of impure stuff as
well: if I remember well, only ground facts were allowed in Turbo
Prolog's dynamic data-base. Mercury, being a `purely declarative'
`new language', (despite the fact that it still runs under
SICStus:-), does not have such a beast at all.The few mode and type declarations, usually less than the size of the
clauses themselves :-), are enough to break meta-programming once for
all. The same did happened with Turbo Prolog. A 100-times slower
meta-interpreter for real Prolog gave back `Edinburgh Prolog
functionality', of course :-). A little bit smaller and a lot
slower than in C.Wanting to know `too much' statically is not worth its price when half
of the code will travel on the net (to end up executed in the Java-chip
in your TV set:-) Overall, the main strength of logic programming as a
practical programming tool is expressiveness. A factor of 2-3 in speed
is simply not enough to give it away. Modes and types are helpful to
manage complexity but without inference they are tedious enough not to
be excused for killing out convenient meta-programming.To leave some hope, I would gladly switch to Visual Prolog if it had
type inference and to Mercury if it had at least as much mode inference
as Visual Prolog :-). Combined with a first order representation of
type and mode declarations and a 10 lines meta-interpreter around.Until then, the slim Prolog kernel which successfully survived ISO
standardization looks just too hard to beat. Visual programming is not
an issue as most modern Prologs have at least a Tcl/Tk interface and
Java interfaces are coming. Learning a home brewed visual language
with Prolog syntax when you already know a generic one is not worth
it. I think that Prolog as an embedded logic engine in a multi-paradigm,
net aware environment is still the way to go for the next few years.
Paul Tarau--
Paul Tarau, PhD. Associate professor Phone: (506) 858-4120
Dept. of Computer Science University of Moncton FAX: (506) 858-4541
Moncton N.B. CANADA E1A-3E9 ta...@info.umoncton.ca
You don't get constraints; you _do_ get unification.
The semantics of any Mercury program that the compiler accepts is
precisely the standard semantics of the logic program obtained by
erasing the tyoe and mode declarations.
Constraints are indeed being considered. It's interesting that a PhD
student working on constraint logic programming under me started off by
arguing that it was important to base things on Prolog and that you
could build a Prolog interpreter as fast as some compiled Prologs
(which he achieved, thanks to writing more assembly code than any
sensible person would _want_ to write), but now argues that the Prolog
part is mainly useful for building up the constraint network.
No. However, the language supports program transformation in a rather
different way: it places no _semantic_ barriers in its way, unlike
Prolog. It is
harder to write sound program transformers for Mercury in Mercury
than sound program transformers for Prolog in Prologeasier to write sound program transformers for Mercury in Prolog
than sound program transformers for Prolog in Prolog.
Neither do I.On the other hand, I am sick of having to apologise that Prolog doesn't
have constant-time updatable arrays (or that Prolog dialect XXX which does
has done so at the sacrifice of any connection with logic programming).
I _like_ being able to say "yes you can have efficient I/O without strange
contortions, yes you can have constant time updatable arrays, and yes you
_can_ have logic programs based on a sound execution strategy for Horn
clause programs with a pretty standard semantics, all in the same box."I don't think anyone associated with Mercury would want to argue either
that Mercury should ever replace Prolog or that Mercury is finished.
There are lots of things to come, concurrency (where the absence of
updates to a global variable is a big help), coroutining, exceptions,
program transformation tools, great development environment, ...
There's a reason that the current release is 0.5, not 1.5!(Can I have a Clean-style programming interface for windows? Please?
Pretty please with sugar on? I'm finally getting my head around that,
and it looks like what I've always wanted.)
>I think Thomas Lindgren is pointing out something I heared around
>from a fairly large number of people involved in logic programming.
>Basically, giving away expressiveness for speed is _wrong_.
>Giving up Prolog for less expressive languages for reasons
>of speed, types/modes, proprietary visual tools etc. is _wrong_ too.
>
>Some history might help on this.