From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,29fe9a340e0d180d X-Google-Attributes: gid103376,public From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: Depending on passing mechanism Date: 1997/10/20 Message-ID: <62f36c$3r5@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 281932411 References: <622b4t$nhe$1@gonzo.sun3.iaf.nl> <62ckao$827@mulga.cs.mu.OZ.AU> Organization: Comp Sci, University of Melbourne Newsgroups: comp.lang.ada Date: 1997-10-20T00:00:00+00:00 List-Id: Brian Rogoff writes: >Fergus Henderson wrote: >> How close do you have to get to be "comparable"? > >No "distributed overhead", by which I mean a program not using "unique >modes" is not any worse off than it would be if there were no unique modes >at all, modulo increased compile time if it isn't too much. That is indeed the case. It is just a compile-time analysis that rejects certain programs. There's no run-time overhead. >Mercury is a logic programming language; would you use it for applications >which require lots of in place array manipulation (numerical linear >algebra, image proceesing, raster graphics, ...)? I'll read some of your >papers; I just want to get a sense of whether Mercury is a very general >purpose compiled language (like Ada or C++) or if it is mostly for >symbolic processing. Mercury is intended to be a general purpose compiled language, though probably not _quite_ as general as Ada and C++. Mercury is a bit higher-level than Ada or C++ -- for example, it has garbage collection, and (like Java) there is no stack allocation. Mercury doesn't go to so much effort in supporting low-level code -- for example, it has no equivalent to Ada's record representation specs. But (looking only at the languages, and ignoring issues like availability of compilers, libraries, etc.) Mercury should be a reasonable choice for most of the things where say Java is a reasonable choice. Regarding in place update, well, that is exactly what unique modes are used for in Mercury. Since Mercury is a single-assignment language, there is no direct equivalent to Ada's "inout" mode. Instead, you use a pair of arguments, one with mode "in" and the other with mode "out". If you want in place update, then you use "destructive_in" and "unique_out" instead of "in" and "out". Mercury was designed to make it possible to write code that needs lots of in place update. As to whether it is _easier_ to write that sort of code in a language like Mercury (which is quite amenable to formal methods) or in a language which has more direct support for updates with side effects (which can consequently make it a bit more difficult to reason about programs), I think it is still an open question. There are probably lots of languages which currently have better library support for things like numerical linear algebra, image processing, etc., starting with Fortran. But certainly it is quite _possible_ to write that sort of thing in Mercury. And our initial experiences with this have been pretty positive. For example, we have an OpenGL interface, and we have written some programs using this; from memory, I think profiling showed that most of the time was spent inside the OpenGL primitives, so we are efficient enough for this application, at least. Anyway, enough advertising for one day ;-) -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.