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: Brian Rogoff Subject: Re: Depending on passing mechanism Date: 1997/10/19 Message-ID: #1/1 X-Deja-AN: 282599920 References: <622b4t$nhe$1@gonzo.sun3.iaf.nl> <62ckao$827@mulga.cs.mu.OZ.AU> X-Trace: 877294382 29032 bpr 206.184.139.132 Newsgroups: comp.lang.ada Date: 1997-10-19T00:00:00+00:00 List-Id: On 19 Oct 1997, Fergus Henderson wrote: > Brian Rogoff writes: > >I'll have to find the ref where I thought I read about this. In any case, > >simply having a strong static type system does not guarantee no runtime > >overhead; you suggested the Haskell approach as a valid one. While Haskell > >code looks nice on paper the current compiler implementations are far from > >producing comparable code to gcc for similar problems. > > The differences in efficiency are mostly due to unrelated factors: > - laziness > - different coding styles > Haskell code often allocates lots of garbage, > makes significant use of higher-order functions, > etc. By laziness, I assume Fergus here means that Haskell uses lazy evaluation, (expressions are not evaluated until their values are needed) not that Haskell compiler writers are a lazy bunch :-). > But a language which does have some support for unique types > and which generates code which is often comparable with gcc, > assuming similar coding styles in the source code, is Mercury > . OK, reading about Mercury was on my "to do" list, I guess now is the time. > 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. 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. > >What I would like > >to be convinced is > > > >(1) An actual pseudo-Ada syntax for "unique" types in Ada. Starting from > > there I could see exactly how your proposal would interact with the > > the current Ada. > > Well, I'd go for unique modes, rather than unique types. > In addition to "in", "out", and "inout", add > "unique_in", "destructive_in", "unique_out", and "unique_inout", > with semantics similar to the unique modes in Mercury. Yes, that makes much more sense, especially considering (negatively) Ada's limited types. > Some work would be required to specify the semantics precisely... What I worry about is that there might be odd feature interactions. The devil is in the details I suppose. -- Brian