Re: Re: Types in Mathematica, a practical example

*To*: mathgroup at smc.vnet.net*Subject*: [mg62861] Re: [mg62820] Re: [mg62800] Types in Mathematica, a practical example*From*: Sseziwa Mukasa <mukasa at jeol.com>*Date*: Tue, 6 Dec 2005 23:10:57 -0500 (EST)*References*: <200512051841.NAA21133@smc.vnet.net> <200512060503.AAA02706@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

On Dec 6, 2005, at 12:03 AM, Andrzej Kozlowski wrote: > It seems to me that you are looking here at Mathematica from the > wrong view point. Although Mathematica is not a strict "functional" > language, it is "functional" at least in the sense that it is > "functions" and not "objects" that play the central role (I am being > deliberately vague here but I have run out of patience with long > discussions of programming languages and general design issues.). Amen, but apparently I have a masochistic streak that makes me persevere in this sisyphean discussion. At any rate I thought about the problem a bit further, I am not sure why, and your point above is related to my thoughts. If one insists on seeing all programming in an "object oriented" manner there is an argument that could be made for understanding how to make a Symbol x have some desired properties corresponding to behavior according to a type. The first thing one must do is forget the Java/C++ model of objects, where objects are defined as record structures which can contain associated methods. Instead the appropriate model is Smalltalk, where the definition of a method on a variable defines the behaviors of the class to which that variable belongs. > In > this case the issue is with the function Plus and not with the nature > or "type" of x etc. Plus has the attribute Listable, which is > responsible for the behaviour you see Agreed, so the "object oriented" approach would be to redefine the Plus method on x to get the behavior we desire. We can consider the regular Plus method to be inherited from the type which roots the Mathematica type system: expression. The larger problem is the evaluator; the Listable attribute gets applied before any definitions of Plus are used and removing the Listable attribute would apply to all definitions of Plus not just the Plus for x. Having spent too much time thinking about this already I'm not really sure how to work around that problem, it seems to me one would need to redefine Plus in such a way that all instances of Plus not involving x behave as a Listable expression which is a nontrivial task. A simpler alternative is to create your own method not named Plus with the properties you desire: objects of type undefined2DArray should return as a symbol and other objects should be evaluated. There are still some issues with the evaluator but mySubtract[undefined2DArray[x_], a_] := HoldForm[mySubtract[x, a]] mySubtract[x_, a_] := x - a mySubtract[undefined2DArray[x], a] ReleaseHold[mySubtract[undefined2DArray[x], a] /. x -> a] gets most of the way there but is admittedly unwieldy to use because of the Holds. > the natural way to deal with your problem is by > temporarily blocking the Listable attribute like this: > > In[10]:= > a = {{1, 2}, {3, 4}}; > > In[11]:= > Block[{Plus}, x - a /. x -> a] > > Out[11]= > {{0, 0}, {0, 0}} Of course, but I think the idea in this thread is to deal with the idea of types and their implementation in Mathematica. The evaluator does not easily fit into a model of types. I think what should be clear though is that unless there is a very good argument for developing the infrastructure necessary to redefine the behavior of Mathematica expressions globally, development of a type system infrastructure is probably far more work than it's worth. Regards, Ssezi

**Follow-Ups**:**Re: Re: Re: Types in Mathematica, a practical example***From:*Pratik Desai <pdesai1@umbc.edu>

**References**:**Types in Mathematica, a practical example***From:*"Ingolf Dahl" <ingolf.dahl@telia.com>

**Re: Types in Mathematica, a practical example***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>