Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Types in Mathematica

  • To: mathgroup at smc.vnet.net
  • Subject: [mg62854] Re: Types in Mathematica
  • From: "Steven T. Hatton" <hattons at globalsymmetry.com>
  • Date: Tue, 6 Dec 2005 23:10:29 -0500 (EST)
  • References: <200511191053.FAA16418@smc.vnet.net> <dlp2ci$le$1@smc.vnet.net> <200511200950.EAA04496@smc.vnet.net> <dls4vp$mmc$1@smc.vnet.net> <dm1ak3$i1n$1@smc.vnet.net> <dmjrb8$5u6$1@smc.vnet.net> <dmm2tp$nmo$1@smc.vnet.net> <dn376h$33o$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Jon Harrop wrote:

> Steven T. Hatton wrote:
>> I believe most people here will agree that Mathematica is not a strongly
>> typed programming language.
> 
> Actually, one can productively say that Mathematica is a strongly typed
> language because it has only one type (expr).

Is that assertion really meaningful or useful?

>> What would a type system in Mathematica be?
> 
> Anything you want.

What would a _useful_ type system in Mathematica be?

>> What might be gained by having a type system in Mathematica?
> 
> Performance, correctness.
> 
>> What might be lost?
> 
> Simplicity, brevity, clarity.

It might be argued that these could be increased in some circumstance by
having a type system.  Likewise, performance might take a hit from
extensive typechecking.

>> To what extent /does/ Mathematica have a type system?
> 
> Results of the "Compile" function do some run-time type checking (e.g. for
> machine-size real input). Many other built-in functions check the "types"
> of their arguments but that is slightly different to conventional dynamic
> type checking.

When I think about dynamic type checking, I think about determining the
actual type of an object referred to by a variable referring to a basetype
of multiple derived types.  I can imagine circumstances where such a
feature might be useful in Mathematica.  The example of testing to
determine if some object represents a "real number" was intended to suggest
this.  An integer is a real number, as is a rational number.  That is an
"is a" relation in OOP terminology, and thus implies an inheritance
hierarchy.

>> To what extent can a type system be implemented within Mathematica
>> without modifying the language?
> 
> Entirely.
> 
> Because Mathematica is a rewrite system, it is comparatively easy to write
> interpreters and compilers in it (compared to C, for example).

I can certainly imagine writing a C++ parser in Mathematica, but that makes
assumptions about the input.  In particular, that it is written in C++
which already has a type system defined.

> As a type 
> system and, more importantly, a type checker is part of a
> compiler/interpreter, these can be written in Mathematica.

Yes, but see my previous comment.  You would need a means of expressing
types in Mathematica in order to check them.

>> How would a type system in Mathematica be similar to one in another
>> language?
> 
> You could write a type checking function to type check Mathematica
> programs. This could mimic an ML-like type system, for example.

I have wanted to study ML for a long time, but I have to plead virtual
ignorance here.

>> How would a type system in Mathematica differ from one in another
>> language?
> 
> It would be optional because it is not fundamental to the language.
> 
> To improve performance, the use of a more refined type system could be
> entirely automated and invisible to the user.

One aspect of comparing Mathematica to compiled languages in the area of
type checking is that compiled languages typically do their type checking
at compile time.  Yes, dynamic type checking can happen at runtime, but
that already assumes certain compile time checking has been performed. 
Furthermore, dynamic type checking usually incurs a performance hit.  If
there were typechecking in Mathematica, that could mean a test is perfromed
for every parameter each time a function is evaluated.

Ironically, in C++, it appears that functional programming constructs tend
to be slower than procedural ones.  In Mathematica, the opposite appears to
be the case.  The same may be true of type checking.

> To improve correctness, the type system must be exposed to the user in the
> form of static type errors.

One thing I've noticed about Mathematica regarding errors is that, for the
most part, "errors" do not halt evaluation.  In compiled languages, a type
checking error will halt compilation. 

There are such constructs as Throw and Catch in Mathematica, but I'm not
convinced of their usefulness.

-- 
The Mathematica Wiki: http://www.mathematica-users.org/
Math for Comp Sci http://www.ifi.unizh.ch/math/bmwcs/master.html
Math for the WWW: http://www.w3.org/Math/


  • Prev by Date: Re: Types in Mathematica thread
  • Next by Date: Mathematica and Transcendental Numbers
  • Previous by thread: Re: Types in Mathematica
  • Next by thread: Re: Re: Types in Mathematica