Re: Depending on passing mechanism

[Brian Rogoff <bpr@shell5.ba.best.com>]

On 19 Oct 1997, Fergus Henderson wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> 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
> <http://www.cs.mu.oz.au/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