world as value

[Adrian Hey]

On Tue 29 Jun, Marco Kesseler wrote:
> That is one of the reasons why I would be so pleased if it were possible
> to call Clean from C easily: it would (or should) NOT be a 'semantic' problem.

I can understand why you want to do this. C with pure functions when needed
would be quite attractive to me too, rather than explicit messing about with
heaps and pointers. As for calling Clean or Haskell from C or calling C from
Clean or Haskell, I have never tried either, but I anticipate that in practice
it is potentially frought with problems (which aren't necessarily unsolvable,
but need careful thought).

I suppose this is what the "Calling Heavean from Hell etc" paper which Simon
Peyton Jones mentioned was all about.  

> In contrast, calling C from Clean remains troublesome, because it is
> hard to ensure that a C routine is truely a pure function.

Yes, I suppose one solution to this would be to make the function take *World
as an input to explain it's impure behaviour, but you probably wouldn't want
to do this if you knew that the C routine was an 'imperative pure function'.
 
> >    Cross language optimisation would be a nightmare too.
> 
> Maybe, but I really wonder whether this will turn out to be such
> a big issue.

Probably not if you do your own optimisation in writing your program, but I
certainly think it reduces the scope for compiler optimisations.

> If not, two approaches already come to mind.
> - Haskell translates to C, so perhaps the C compiler can do the
>   cross-language optimisations.

Only at a very low level I think. What I would call code optimisation rather
than optimisation by proof and program transformation.

> - certain mixtures of functional code and C might be translated into
>   a functional expression that explicitly passes state, or uses monads
>   This can then be optimised by the functional compiler.

Strangely enough, it was attempting to do just this that got me interested
in functional programming in the first place. I wanted to prove thing about
Pascal programs and found that this was easiest by transforming loops into
recursive functions with explicit state passing. What's more the resulting
functions were considerably simpler than the Pascal code. At the time I
naively thought I was the only person in the world doing this, but then I
discovered functional programming languages. Excuse the annecdote, I think
the point I'm trying to make is that code that can be transformed this way
is probably better written in a functional programming language in the first
place. A good compiler should, in principle (if not yet in practice), be able
to use uniqueness analysis and tail call optimisation to generate code every
bit as efficient as the Pascal (or C) equivalent using loops and mutable
variables. I think this what the Clean compiler is supposed to be good at.

> - would it be a big problem for a C programmer to use (or convert
>   to) data structures that can readily be offered to Clean?

I suppose someone from the Clean team could answer this question better
that me. Clean already has some sort of interface for calling C, so this
issue has probably already been addressed somehow, but I have never used
it so I don't know. All I would say is that allowing C code to mess with
the Clean heap seems extremely perilous, but perhaps there's a way of
exchanging data that doesn't give C access to the Clean heap.

                     ------------------------

I suppose I'm not a big fan of the idea of mixed language programming in
general (although I often mix C and assembler). Just so long as your only
dealing with stacks and a well defined procedure call standard it isn't
too much of a problem, but that's because imperative languages generally
have the same or very similar run time systems. Functional programming
languages (especially lazy ones) are completely different, based on graph
reduction and garbage collected heaps. What's more, the heap is fragile
and if an errant foriegn language routine is allowed access to it, could
easily crash the program unless extreme caution is exercised. I can't think
of a way of providing a flexible interface between C and Clean which would
at the same time be safe (for the Clean heap), short of copying data
structures to/from the Clean heap from/to memory reserved for C.


Might I ask why you want to call Clean from C? (instead of using pure Clean)
I don't know what kind of programs you're trying to write. Is it an
efficiency issue? or lack of concurrency?

Regards
-- 
Adrian Hey