Re: Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg62802] Re: [mg62740] Re: Types in Mathematica
- From: Sseziwa Mukasa <mukasa at jeol.com>
- Date: Mon, 5 Dec 2005 13:41:09 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
On Dec 4, 2005, at 6:16 AM, Steven T. Hatton wrote:
I started this reply before seeing your conversations with Kris
Carlson, he seems to have better elucidated the points I was trying
to make.
> On Saturday 03 December 2005 21:37, Sseziwa Mukasa wrote:
>
>> On Dec 3, 2005, at 6:52 PM, Steven T. Hatton wrote:
>> An example of a strong and
>> dynamic language is LISP, and this is one respect in which
>> Mathematica
>> differs from LISP.
>>
>
> (setq f 1)
> (setq g 2.2)
> (setq h (+ f g))
> (print h)
> =>3.2
It's been a while since I used LISP, fair enough. Whatever the case
with respect to strong typing LISP is generally considered strong
among computer scientists as far as I can tell.
>> C is of course weak and static, Java is strong and
>> static and that covers the four possibilities.
>>
>
> Java certainly supports primitive type conversion, so I don't
> understand your
> statement.
Allowing type conversion isn't the issue (and real + int is a poor
example) but we both agree it's a difficult concept to define
unambiguously. It also seems it's aside from the general discussion,
this thread does not appear to be about whether Mathematica is strong
or weakly typed but about what a type is exactly in Mathematica.
>> A List is most certainly not a Symbol, nor is it Complex, Integer,
>> Real
>> etc. A List is an expression whose Head is a Symbol with value List
>> applied to zero or more arguments. Hence the idea that everything in
>> Mathematica is an expression, that's really the only type that exists
>> (and paradoxically in that sense Mathematica is strongly typed,
>> but in
>> a universe with only one type it is impossible to distinguish between
>> strong and weak typing).
>
> I don't agree with this.
Fair enough but Head[{1,2,3}] is not Symbol.
> One can say that 1 is an expression with head
> Integer, but to say that expression is a data type is not much
> different than
> saying everything in C++ is a statement.
There are different kinds of statements in C++ of which expressions
are but one class (http://cpp.comsci.us/syntax/). There are no
different kinds of expressions in Mathematica all have the same
structure Head[Arguments...].
>> f[g[x_]] can be considered to be a function that acts on objects of
>> type g. Since Mathematica is not strongly typed to ensure that we
>> know
>> the pattern x_ is to be considered of type g we have to explicitly
>> include the information somewhere, and in Mathematica a convenient
>> location is the head of an expression. It's not necessary to do it
>> that way f[{g,x_}] also works and now the type g is represented as a
>> list whose first element indicates its type.
>>
>
> How does that have superficial resemblance to the use of a type
> system in
> another language?
Because there is no intrinsic type system to which I've added g in
the sense that declaring a class in C++ adds an explicit new type to C
++ along with int, double etc.
> What confusion?
The confusion over exactly what constitutes a type in Mathematica.
I will go out on a limb here and say there are two definitions of
type in Mathematica. One is of what type entities (the word objects
has too many connotations to use in this context) in Mathematica are,
to which the answer is everything is an expression. The other
definition is of how one defines a type hierarchy in Mathematica
which defines objects and operations thereon, and the answer is there
are multiple ways but the generally preferred way is to use the head
of expressions to establish membership in the hierarchy.
> What is the difference between associating a function with an
> operator in C++
> and in Mathematica?
You can't inspect the structure of the function in C++ because it's a
function definition and there is no facility for programmatically
inspecting the contents of a definition in C++. In Mathematica the
contents are stored as an expression in the DownValues which can be
modified as any other expression in Mathematica sans restrictions.
>> Because C++ has well defined constructs called, statements, functions
>> (or operators) and a host of types and a lot of rules explaining how
>> they all interact. Mathematica has none of these.
>
> You are making assertions which are contrary to the terminology
> used to
> discuss Mathematica.
For the sake of brevity and in the correct context clarity, it helps
to refer to things like Plus[a_,b_] as a function or operator and For
[...] as a statement but the truth is in Mathematica they are both
expressions and equivalent in that sense. Making the distinction may
be useful to thinking about problems from the programmer's
perspective but there is nothing within Mathematica itself that
forces that distinction unlike in C++ where function+(a,b) and for
(...){} are different.
I suppose though that this discussion thread would be helped by
examples of where some particular definition of type is both useful
to the programmer and difficult to implement in Mathematica.
Personally I have found that objects which require complicated state
information are not trivial to use in Mathematica but I have usually
found that using a different perspective often obviates the need for
state in the first place. With respect to GUI like programs that
don't lend themselves to the Notebook interface, this is not
generally the case and as has been said many times on this list
Mathematica is not suited to the writing of such programs.
Regards,
Ssezi