Prolog for Visual Studio .NET 
Author Message
 Prolog for Visual Studio .NET

Is anyone implementing (Standard) Prolog for Microsoft's .NET architecture?

Apparently it is based around a VM, facilitates mixed-language programming,
and has a common, open IDE (I believe there's an open source python
implementation under way).

Paul Singleton



Sat, 10 May 2003 03:00:00 GMT  
 Prolog for Visual Studio .NET

Quote:

>Is anyone implementing (Standard) Prolog for Microsoft's .NET architecture?
>Apparently it is based around a VM, facilitates mixed-language programming,
>and has a common, open IDE (I believe there's an open source Python
>implementation under way).

Not aware of Prolog, but the Mercury group has done some work on targeting
the .NET platform. More details at
        http://www.cs.mu.oz.au/research/mercury/information/dotnet/mercury_an...
Also, I think there was some work on Scheme on top of .NET.

Quote:
>Paul Singleton

Cheers,

Michael Winikoff



Sun, 11 May 2003 11:23:19 GMT  
 Prolog for Visual Studio .NET

Quote:

>Is anyone implementing (Standard) Prolog for Microsoft's .NET architecture?

Not that I know of.

You are probably aware that we're implementing Mercury for .NET
(see <http://www.cs.mu.oz.au/mercury/dotnet.html>).

Quote:
>Apparently it is based around a VM, facilitates mixed-language programming,
>and has a common, open IDE (I believe there's an open source Python
>implementation under way).

Calling the Visual Studio IDE "open" is definitely misleading.
The APIs for programming the IDE are proprietrary trade secrets.
Third party companies can get access to those APIs, but only after
signing a (probably fairly onerous) contract and paying a huge fee.
Academic institutions can also get access to the APIs, but only after
signing an onerous contract that includes many restrictions.

I don't know if the Python folks have started working on Visual Studio
integration (as opposed to just having a compiler that targets .NET) yet,
but if/when they do, the resulting code will not all be open source,
at least not unless Microsoft make some major policy changes with
regard to Visual Studio integration.

--

                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



Sun, 11 May 2003 11:44:14 GMT  
 Prolog for Visual Studio .NET

Quote:
>Also, I think there was some work on Scheme on top of .NET.

Yes, the compiler is called the "HotDog" Scheme compiler.
See <http://www.cs.nwu.edu/~surana>.

I suppose there may be a Prolog implementation in Scheme;
if so, you may be able to run Prolog on top of Scheme on top of .NET.
Just don't expect it to run fast ;-)

But I think HotDog Scheme doesn't support call/cc, which Prolog
implementations in Scheme might use, so even if you have a Prolog
implementation in Scheme it may not be possible to run it on HotDog
Scheme.

--

                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



Sun, 11 May 2003 12:32:53 GMT  
 Prolog for Visual Studio .NET

Quote:

> You are probably aware that we're implementing Mercury for .NET
> (see <http://www.cs.mu.oz.au/mercury/dotnet.html>).

Well I wasn't but I am now - thanks.

Last time I glanced at Mercury, its typing system didn't ("yet") embrace
variables in data structures, which seemed to prevent me porting quite
a bit of my existing Prolog code, and also to preclude some programming
techniques and idioms which I use and value.

I don't mind some rewriting (e.g. replacing cuts with ->) if it tidies up
my code, and I (strive to) avoid side-effects anyway, and I'm interested
in writing in the common Mercury/Prolog subset where this doesn't involve
uncomfortable compromises, but I'm keen to know:

 * how much of Prolog's expressiveness does Mercury *necessarily* forgo?

 * what's your timescale/roadmap for making Mercury less Prolog-unlike?

 * does your committment to the .NET platform compromise such developments?

Paul Singleton



Mon, 19 May 2003 03:00:00 GMT  
 Prolog for Visual Studio .NET
I have been looking at the web site:

  http://mercury.sourceforge.net/dotnet.php3

But I don't see and "downloads of the day" that look like
they support .NET

I understand that a beta with .NET support is likely to be released in
December; is it a good idea to just wait?

Thanks,
Mark



Mon, 19 May 2003 03:00:00 GMT  
 Prolog for Visual Studio .NET

Quote:


>> You are probably aware that we're implementing Mercury for .NET
>> (see <http://www.cs.mu.oz.au/mercury/dotnet.html>).

>Well I wasn't but I am now - thanks.

>Last time I glanced at Mercury, its typing system didn't ("yet") embrace
>variables in data structures, which seemed to prevent me porting quite
>a bit of my existing Prolog code, and also to preclude some programming
>techniques and idioms which I use and value.

There's two approaches to doing that kind of thing in Mercury.
One is to support partially instantiated data structures in our
static mode system.  We still plan to do this ("before version 1.0"),
but unfortunately it has still not yet been done.  We don't have a
clear timetable as to when it will be done.

The other approach is to use dynamic modes and a more Prolog-like
implementation technique.  The Mercury implementation has had support
for for *optional* dynamic modes since about September 1997.
Unfortunately I still haven't gotten around to documenting that
support.  However, there are some examples of its use in the Mercury
extras distribution (in the `extras/trailed_update' and the
`extras/clpr' directories).  I hope to add documentation for this RSN.

Some Prolog idioms that use partially instantiated data structures,
for example constraint programming, will need to use dynamic modes
rather than than static modes.

Quote:
>I don't mind some rewriting (e.g. replacing cuts with ->) if it tidies up
>my code, and I (strive to) avoid side-effects anyway, and I'm interested
>in writing in the common Mercury/Prolog subset where this doesn't involve
>uncomfortable compromises, but I'm keen to know:

> * how much of Prolog's expressiveness does Mercury *necessarily* forgo?

[I'll answer that later when I have more time.]

Quote:
> * what's your timescale/roadmap for making Mercury less Prolog-unlike?

See above.

There's also a group (mostly at Monash University) who are developing
a language called HAL.  They are building a HAL implementation which
compiles to Mercury.  You may be interested in HAL since HAL is more
Prolog-like than Mercury.  HAL is strongly typed but dynamically
moded.  It is designed for implementing and using constraint solvers.

Quote:
> * does your committment to the .NET platform compromise such developments?

No.

The new back-end that we've implemented for the .NET platform doesn't
yet support trailing (which is required for dynamic modes), but that
will not be particularly difficult to implement, it's just something
that we haven't gotten around to yet.

--

                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



Tue, 20 May 2003 12:02:37 GMT  
 Prolog for Visual Studio .NET

Quote:

>I have been looking at the web site:

>  http://mercury.sourceforge.net/dotnet.php3

>But I don't see and "downloads of the day" that look like
>they support .NET

The recent snapshot releases on the web site include a version of the
compiler that generates MS IL code for .NET; you can enable this using
the `--target il' option.

The generated IL code can be assembled with Microsoft's IL assembler.
You can't yet run it, since we don't yet provide an appropriate
version of the Mercury standard library to link with.

Quote:
>I understand that a beta with .NET support is likely to be released in
>December; is it a good idea to just wait?

Yes.

--

                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



Tue, 20 May 2003 12:09:52 GMT  
 Prolog for Visual Studio .NET

Quote:
> * how much of Prolog's expressiveness does Mercury *necessarily* forgo?

and I promised

Quote:
>[I'll answer that later when I have more time.]

but now that I come to answer the question, I'm not really sure that I
can give a good answer.  "How much?" is a difficult question -- it's
hard to quantify these things!  Also "*necessarily*" just raises
the question "necessary given what assumptions?"

But I'll give it a shot.

There's two main ways in which you might consider Mercury to be less
expressive than Prolog.  One is that Mercury requires certain
declarations which Prolog does not.  The other is that Mercury's
static analysis systems (types, modes, etc.) forbid certain things
which are possible in Prolog.

Let's consider the first of these.  Mercury allows type, mode, and
determinism inference inference within a module.  So in most cases you
can leave off the declarations for procedures that are define locally
rather than being exported for use by other modules.
(There are some cases in which Mercury's type, mode, and determinism
inference won't infer things which are possible if you include
declarations.  For example in Mercury you can declare that a predicate
takes as input a non-empty list and you can get the type/mode system
to enforce that, but inference won't try to infer such declarations,
instead just inferring that the predicate takes a list as input.
You may also need to include type declarations to resolve amiguous
overloading.  However, in most cases explicit declarations for
local procedures aren't required.)

It would be possible to also support inference across modules.
Making this work in the presence of mutually dependent interfaces
would be quite tricky, but is probably doable, and handling it for
modules that are not mutually dependent would not be particularly
hard.  However, we don't really have much interest in doing that,
since failing to declare the types and modes of your interfaces is bad
software engineering practice -- it makes programs much harder to
maintain.

Mercury also requires you to explicitly declare all types and data
constructors used (or to import such declarations from other modules).
It might be possible to eliminate this requirement (see recent
discussion on comp.lang.functional), and have type inference infer the
type definitions too, not just the predicate declarations, but this
would certainly make inference more difficult.  Again, we don't have
much interest in doing this, since documenting the types that your
application uses is in our opinion good software engineering practice
anyway (even for dynamically typed languages like Prolog, where you
have to use comments rather than type declarations).

Mercury's module system requires a few more declarations for a hello
world program than Prolog.  This is not strictly necessary.  We could
for example provide some more concise defaults, for use in cases where
you just have a bit of throw-away code that you want to quickly test.
We've discussed this a bit within the Mercury group, and at least some
of the members (myself included) are in favour of such a change.
As well as language changes, there's also room for improvement in
the implementation in this respect, e.g. better turn-around time for
interactive queries in the de{*filter*}.  We've just had a student start
work on a project aimed at reviving our efforts to build a bytecode
interpreter for Mercury, so there's a good chance of improvements in
this area.  I'd also like to see a Prolog-like or Hugs-like interactive
shell.

The second major issue was the restrictions imposed by the type, mode,
determinism, and purity systems.  Unfortunately I'm again out of time,
but let me just note briefly that Mercury supports optional dynamic
typing, and optional dynamic modes; determinism too can be checked
dynamically using explicit checks if need be; and Mercury now does in
fact even allow impure code, so long as you explicitly annotate things
`impure' at every point where you define or use impure procedures.
So there's very little in the way of hard restrictions, it's just that
in cases where you need to make use of dynamic checking you may need
to be a bit more explicit about it, and so the code may not be quite
as concise as in Prolog.

However, in return for that, you get numerous advantages.  In many
respects, Mercury is much *more* expressive than Prolog.  The
expressiveness comparison is certainly not just a one-sided one.
And in addition, you get much better compile-time checking and in most
cases much more efficient code.  So if you're willing to change your
programming style a bit, then Mercury may have a lot to offer.

--

                                    |  of excellence is a lethal habit"
WWW: < http://www.*-*-*.com/ ~fjh>  |     -- the last words of T. S. Garp.



Wed, 21 May 2003 03:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Visual Studio .NET Comparison (?)

2. Clarion and Visual Studio .NET

3. Help making CIN *.lsb file with Visual Studio .NET

4. NI-VISA and Visual Studio .NET

5. Compilling CINs in Visual Studio .Net.

6. Do Not Install Visual Studio 6.0 with Net Express 2.0

7. Salford Software Event Invitation - Numerical co mputing - Bringing Fortran to .NET with Visual Studio

8. Powerstation 4.0 and Visual Studio .NET

9. fortran and visual studio.net

10. Visual Studio.net

11. Lahey/Fujitsu Fortran Technology Preview for Microsoft Visual Studio .NET

12. Tcl/Tk 8.4.0.1b1 libs and Microsoft Visual Studio .NET

 

 
Powered by phpBB® Forum Software