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: [mg63031] Re: Types in Mathematica
  • From: Sseziwa Mukasa <mukasa at jeol.com>
  • Date: Sun, 11 Dec 2005 04:57:07 -0500 (EST)
  • References: <dn22fb$kum$1@smc.vnet.net> <200512081442.jB8EgCda002721@ljosalfr.globalsymmetry.com> <F44AB4A1-92CA-49D7-ABDD-E94D8270B8EC@jeol.com> <200512081419.17348.hattons@globalsymmetry.com> <dnbmt9$5qf$1@smc.vnet.net> <-4qdnaBC0M37OgTeRVn-uQ@speakeasy.net> <dned7g$6d$1@smc.vnet.net> <200512101438.jBAEcJp1031941@ljosalfr.globalsymmetry.com>
  • Sender: owner-wri-mathgroup at wolfram.com

On Dec 10, 2005, at 9:38 AM, Steven T. Hatton wrote:

> Atoms really do seem to satisfy the definition of abstract data type.  
> One
> might even say they satisfy the definition of object in the OOP sense.

Sort of, they are a decent candidate.

>> Part cannot take anything beyond the 0th
>> (head) element of atoms, Part returns a Message
>
> I'm not sure I would use the term "Message" here.  But then, "message" 
> is
> something I consider specific to SmallTalk, and not generally useful 
> when
> discussing OOP.

I meant message in the sense of Message[Arguments], from now on when 
talking about Mathematica expressions I'll capitalize the first letter 
and use lower case when some other meaning is intended.  Rereading 
these messages though, I notice that I'm a poor editor of emails so 
there will be mistakes.

> I'm talking about
> creating things as composite expressions and treating them _as if_ they
> were atomic.

Perhaps doing this in pursuit of a specific application would be 
helpful.  I've notices the occasional relativist (the physics type not 
the philosophic type) who is looking to use Mathematica to represent 
tensors and the other structures they work with symbolically.  I 
believe there is a package that does so already, but if there is a 
candidate for something that should act like and Atom but is not one I 
suppose that's it.  I know far too little of what researchers in 
relativity do to be able to pursue that idea further.

> It appears Maeder would have had a stronger type
> system in Mathematica.  [deleted]  I suspect there were
> discussion about this sort of thing in the early days, and the notion 
> of a
> type system along the lines of C++ was rejected.

Many modern languages have rejected the type system used by the various 
C and Algol derived languages: Haskell, ML, Mercury, Prolog, Dylan, 
Common Lisp...  I know a lot of people are happy with C++ but as far as 
I can tell from programming language designers it is not really an 
interesting path to follow.

>   Was it just a question of who could yell loudest or pout longest, or 
> were there solid reasons for not taking that approach?

I suggest reading up on Hindley-Milner type systems, they seem to be 
the rage in statically typed functional languages.

> What would happen if users could define Atom-like types?  That is, 
> types
> that only expose their content through an interface.  Whoops!  That's 
> OOP!

There's nothing inherently wrong with OOP but it achieved prominence on 
the back of C and Algol like languages and those implementations of OOP 
systems create issues that other languages simply don't have.  For 
example at least one person 
(http://norvig.com/design-patterns/ppframe.htm) thinks the Gang of Four 
would not be earning a dime of royalty or consulting fees if they used 
a dynamically typed language because most of their patters are trivial 
in other idioms.

>> The value of Arg[1+I] is Arg[1+I]
>
> Are you talking about the pattern, or the result given by evaluating 
> the
> expression?

Both since an equation is a tautology.  A better way at looking at 
values in a rewrite system though is a value is what happens when there 
are no more rewrite rules left after applying them to the initial 
expression in which case the value in Mathematica is 
Times[Rational[1,4],Pi].

Similarly the value of Unevaluated[Arg[1+I]] is Arg[1+I] since you have 
to submit the argument of Unevaluated to the evaluator again.

> Indeed, another pit of vipers I seem to have stepped into.  What I 
> should
> have written was What determines (holds) the value of Arg[1+I]//N?

What determines the value is the evaluator, what holds it is some 
expression, in this case one with the head Real.

>> Since there are rewrite
>> rules associated with Arg one has to be careful about when they look
>> at an Arg expression depending on what they want to do with it.
>
> This is certainly a point of frustration I have with Mathematica.  If 
> I look
> at the documentation for Arg[], I am not given a comprehensive 
> description
> of its behavior.

A large part of the Mathematica Book is dedicated to describing the 
evaluator, it would be redundant to repeat it every time.

>> While we continue on our tour of programming languages the
>> logic languages
>
> ??  What do you mean here?  Can you provide an example?  I have been
> glancing at SML over the past few days.  I also compiled and crashed 
> Axiom.

I was thinking of languages similar to Prolog, but this is aside from 
the topic of this thread.

>>> UpValues
>>> DownValues
>>> OwnValues
>>> SubValues
>>
>> These things are side effects of the evaluator, like In and Out, not
>> fundamental.  They are very useful though because they describe
>> expressions we can use to interact with the rewrite rules used by the
>> evaluator itself.
>
> They _are_ the rewrite rules.  At least from the user's perspective.  
> Do you
> not agree?  See 2.6.2 in the Help Browser.

I agree that that is what they are, and their existence makes it 
possible to write self modifying code pretty easily should the need 
arise.  But they are not necessary.

>> Attributes are definitely an interesting beast, I'm not sure but I
>> suspect they can be considered a special set of rules used by the
>> evaluator.
>
> I am willing to bet they are simply bits in a single int variable in 
> the
> Symbol struct.  What the consequences of their being there are, is a
> different story.  They may well be arguments to a switch statement.

Again we're thinking on different levels, I'm not really interested in 
what the implementation of Mathematica looks like (I understand it's a 
blend of C and Mathematica itself).  I'm interested in how one would 
model the evaluator in the abstract.

In my job our product is a blend of an interpreted language and an 
internal implementation in another language and I can honestly say that 
there would be no enlightenment for someone seeking to understand the 
interpreted language to look at its implementation.

> I don't agree.  The items I listed are the abstract data members of the
> "type" Symbol.  The evaluator doesn't have rewrite rules any more than 
> a
> compiler has function definitions.  The rules exist in the expression
> structure passed to the evaluator.

Regardless of how the evaluator actually works, the question is how you 
can reason about it accurately with respect to generating the correct 
output for a given input (even if you get the algorithmic complexity 
wrong).  I submit that the correct way to think about it is as a 
rewrite system, as others have said.

Regards,

Ssezi


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