[DotGNU]Multi-paradigm programming

[Rhys Weatherley]

Jens Müller wrote:

> Rhys Weatherley <address@hidden> writes:
>
> > The CLR already has some features that support
> > multi-paradigm programming.  Logic and functional
> > languages already run on the platform, and can
> > interface with the regular imperative languages.
>
> Interface in a "regular imperative way"?

There has to be some mapping of semantics of course.
The program typically repacks the parameters and makes
a call using the foreign language's calling conventions.

But CLR and the Common Type System (CTS) does make
it easier than in other systems, because the object system
is predictable.  No more guesswork as to what the calling
conventions are.  Unless the language implementor has
done something monumentally stupid, the conventions
are uniform.

Non-imperative languages are used to dealing with
imperative interfaces.  Mercury has interfaces to C,
for example.  Prolog, Scheme, Python, etc, all have
"escape" mechanisms to call out to foreign libraries.

I'll assume that you are referring to making the foreign
API act "properly" in the paradigm.  I'm not really sure
how useful that would be.  Consider the following:

- A Prolog clause creates a window on the screen,
  by calling a non-Prolog method through CTS interfaces.
- Some processing is performed.
- A fail occurs, causing the program to backtrack
  past where the window was created.

Should it remove the window from screen as part
of the backtrack?  Or leave it where it is as an
environmental side effect?

While it may be nifty to be able to undo the non-Prolog
behaviour during backtracking, most Prolog implementors
and programmers would agree that the second option
is the preferred one.  Removing a window during
backtracking is relatively harmless, but how do you
backtrack modifications to a file on the hard drive?

The most annoying issue that language implementors
have had to deal with in the past is how to interface to
things outside their language, because rewriting the
whole universe in the new language is not an option.
CLR/CTS makes this a lot easier than the JVM.

I recommend the papers on the Mercury site for
discussions of language interfacing across paradigm
boundaries.

Cheers,

Rhys.