Visual Prolog's type system 
Author Message
 Visual Prolog's type system

Is the type system of Visual Prolog the same as the type system that
was in Turbo Prolog 1.0?

If not, what are the differences?

--

WWW: < http://www.*-*-*.com/ ~fjh>   |  of excellence is a lethal habit"



Fri, 02 Oct 1998 03:00:00 GMT  
 Visual Prolog's type system

Quote:

>Is the type system of Visual Prolog the same as the type system that
>was in Turbo Prolog 1.0?

>If not, what are the differences?

yes, and how does that type system differ to that of mercury?

Quote:
>--

>WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"


--
        Dr. Tim Menzies                   |  

/     \ http://www.sd.monash.edu.au/~timm | future.
\_,-._/ Dept. Software Development,       | -- Inscription on the base of
     v  Monash University, Caulfield East,|    Paris's monument to Leon
        Melbourne, Australia, 3145.       |    Gambetta
        +61-3-9903-1033(ph) 9903-1077(fax)|


Fri, 02 Oct 1998 03:00:00 GMT  
 Visual Prolog's type system
: Is the type system of Visual Prolog the same as the type system that
: was in Turbo Prolog 1.0?

: If not, what are the differences?

PDC sales people in US told me that it was compatible with Turbo Prolog
2.0 which has the same type system as Turbo Prolog 1.0.

Richard
--
---------------------



Sat, 03 Oct 1998 03:00:00 GMT  
 Visual Prolog's type system
Visual Prolog Technical Support
Service Request number: 12694

Quote:

> Is the type system of Visual Prolog the same as the type system that
> was in Turbo Prolog 1.0?

> If not, what are the differences?
> The type system has become a lot more advanced since Turbo Prolog

1) When writing predicate definitions it is now possible to place a
   comment after each domain name. New types (to ease GUI programming)
   have been added.
2) Multiple internal (named) databases
3) Previous versions of PDC Prolog have used GLOBAL PREDICATE
   definitions to define the interface between object modules.
   In Visual Prolog the same technique (flow pattern descriptors)
   to be applied to local predicates thus generating a compile time
   error if an input parameter is used as output etc.
   are now supported.

Regards

Jonathan Lerwill

PS: We have a specal offer at the moment, A "Trial" version,
actually a fully functioning Visual Prolog Standard (DOS/WINDOWS)
version, for DKR 750,- plus postage.



Mon, 05 Oct 1998 03:00:00 GMT  
 Visual Prolog's type system
<<
Is the type system of Visual Prolog the same as the type
system that
was in Turbo Prolog 1.0?

If not, what are the differences?

It is the same type system as Turbo Prolog 1.0, 2.0, 3.1 and
3.2.
You can make your old Turbo Prolog Code running under
Windows/95/NT/Os/2. Under Ms Windows it makes DLL and
Executables,
Nice tools, makes GPF-free code, no worries.
Serg,
Australia,
Sydeny.



Mon, 05 Oct 1998 03:00:00 GMT  
 Visual Prolog's type system

Quote:


>>Is the type system of Visual Prolog the same as the type system that
>>was in Turbo Prolog 1.0?

>>If not, what are the differences?

>yes, and how does that type system differ to that of mercury?

There are two major differences, as well as several minor ones.
The major (IMHO) differences are

        - Mercury's type system supports parametric polymorphism
          whereas Turbo Prolog's does not.  (Turbo Prolog does
          have one polymorphic data type -- lists are treated
          as a special case -- but it doesn't allow any user-defined
          polymorphic data types or predicates.)

        - Mercury's type system supports higher-order predicates,
          whereas Turbo Prolog's does not.  

These differences make Mercury's type system much more expressive
than Turbo Prolog's.  (Major difference number three will be
announced with the next release of Mercury, but I think I'll
keep that quiet for now ;-)

The minor differences are

        - Turbo Prolog allows a predicate to have more than one
          type declaration.  This mitigates somewhat the lack of
          true parametric polymorphism in Turbo Prolog.
          Mercury doesn't allow this sort of overloading (it wouldn't
          be hard to add, but I haven't found a need for it).
          Mercury does allow overloading of two different predicates
          with the same name and arity, but they must be in different
          modules.  (Mercury version 0.5 requires explicit module
          qualifiers in this situation, but the next release will
          perform overload resolution using type inference to figure
          out which one to call.)  I don't think Turbo Prolog allows
          this.

        - Mercury supports a "universal" data type called `univ';
          anything can be converted to type univ and back.
          If you attempt to convert a univ back to a different type
          than the one it was created from, the conversion will fail.
          This is a bit like a safe equivalent to C's `void *';
          it provides an "escape" for those rare occaisions on which
          you need to create heterogenous data structures.

        - Turbo Prolog supports a `symbol' data-type, which is
          interchangeable with strings but has different performance
          characteristics -- because symbols are stored in a symbol
          table, creation of symbols is slower, but equality tests
          can be a simple comparison.  (In Mercury, programmers
          tend to use enumerations instead, if the set of symbols
          in a type is known in advance.  Enumerations in Mercury
          are represented as integers 0, 1, 2, ..., so they are more
          efficient than symbols would be.  You could use enumerations
          in Turbo Prolog too, although I don't know how the Turbo
          Prolog compiler represents enumerations.)

        - Turbo Prolog allows implicit conversions from real to
          integer and vice versa (conversion from real to integer
          is done by truncation).

        - Although both Mercury and Turbo Prolog support defining
          one type as equal to another, the semantics are different.
          In Mercury, the two types are fully interchangable (just as
          with typedef in C).  In Turbo Prolog, if two different types,
          say apples and oranges, are defined as equal to integer,
          Turbo Prolog will ensure that you don't mix apples and
          oranges.  But it is only possible to define a type to be
          equivalent to one of the basic types (integer, char, real,
          string, or symbol).

          To get distinct types in Mercury, you have to define the
          types using an explicit functor to distinguish between them,
          e.g.
                :- type apple ---> apple(int).
                :- type orange --->
                orange(int).
          The latest development version of the Mercury compiler avoids
          any runtime overhead for such functors: types apple and
          orange are represented in exactly the same way as type int.

Of course, there are a bunch of other very important differences -- for
example, Mercury is a pure logic programming language with no implicit
side-effects, Turbo Prolog has automatic mode inference of local
predicates,  Mercury supports DCGs, Mercury allows if-then-elses (have
they added this to Turbo Prolog yet?), Mercury's determinism system is
a lot more flexible and expressive than Turbo Prologs `nondeterm'
declaration, and Visual Prolog is a lot more useful for Windows
programming, just to name the ones I can think of off the top of my
head.

Disclaimer: my knowledge of Turbo Prolog is not nearly as good
as my knowledge of Mercury! ;-)

--

WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"



Tue, 06 Oct 1998 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Difference between a type system and a type constraint system

2. Difference between a type system and a type constraint system

3. Announcing: Date and Time Functions Library (DLL's) for Visual Prolog

4. Visual Prolog - it's here!!!!

5. Miranda's Type System

6. Biff's-own-guide to type systems?

7. An Attempt to Formalise Dylan's Type System (Part 2)

8. An Attempt to Formalise Dylan's Type System (Part 1)

9. Dylan's type system

10. Dylan's type system

11. type systems and #f and '()

12. In defense of Prolog's dynamic typing

 

 
Powered by phpBB® Forum Software