On Thursday 10 Mar 2011 16:24:00 Ralf Hemmecke wrote: > Hi Martin Baker, > > maybe you should fix the line > > https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/scene.spad.p > amphlet#L478 > > It's utterly wrong.
I agree, would it be better to say that FriCAS does not support subtype polymorphism with late binding or that it does not support virtual functions? BTW- I did raise this issue earlier in this thread: http://groups.google.com/group/fricas- devel/browse_thread/thread/8fb01acc02c3c96a/0a72d6b222ec7af2?hl You and Bill have raised interesting new points and I am keen to get to the bottom of this. Just to put this in context, for anyone else reading this, this discussion arose from a 'wish-list' that I put on the wiki here: http://axiom-wiki.newsynthesis.org/AxiomIssues?root=Axiom%20Problems I put this on my wish-list because, if I am programming in SPAD I often find that I could simplify, remove duplication and encapsulate applications better if only I could use virtual functions. This example is only one example of that but I think its a good example and worth investigating. I take Bills point: "Categories and Domains, as types are static. They must be fully resolved at compile time" (sorry to quote out of context) so I guess that there would be severe difficulties and disadvantages to implementing virtual functions and realistically I guess its not going to happen (but that's not for me to say). However, that's different from saying that it would be useful and I still think its valid to put on my wish-list and to suggest workarounds to me and potential new users. So taking this particular example, which is a recursive tree structure containing a finite number of node types, then: 1) Is this the best structure to use for this particular scenegraph example? 2) Is this structure likely to arise often enough in a CAS to be concerned about? 3) When this structure does occur, how best to represent and code it? I think its important not to mix these issues so I'll try to take them separately: Q1) Most of the graphics file formats that I know about (VRML, SVG and so on) use this structure (not just graphics - any XML file uses this structure). I don't think its just a file format issue either its a very powerful way to represent the information within the program, related elements can be put under a common node and if a node is moved or its properties are changed then all its children will move with it. Its not just me that thinks this either, an implementation of 'open inventor' written by "The Axiom Team" uses such a recursive tree structure to store the information within Axiom - you can't argue with the Axiom gods! and you can't argue that they are biased to an OO programming style. Q2) It seems to me that a recursive tree structure containing a finite number of node types is a perfectly valid and common mathematical structure. I might even try to argue that things like an equation or a term or a whole program (once parsed) are examples of this type of structure. Q3) I'm not sure I completely understand Bills suggestion, I think the idea is that each node in the tree is represented by two domain instances, a general Scene domain instance and some specific-node-type domain instance, if so this seems to add extra complexity and run-time overhead. I don't really want to replace the messiness of the code as it is at the moment with a new type of messiness. The implementation of 'open inventor' seems to use two instances in this way, a set of inner domains and a set if outer domains. There is also lot of extra complexity to get this all to work (I think there may be some 'pretending' from one instance to another and stuff like that). This is all very complex it takes up 4 whole pamphlet files (invnode.as.pamphlet, invrender.as.pamphlet, invtypes.as.pamphlet, invutils.as.pamphlet). I don't think it is a very good advert for the use of Aldor as a programming language, I certainly would not like to maintain or work on that code. When I think about how simple this would be to do, and easy to maintain, if virtual functions were available. Virtual functions may be hard for a language to implement but they seem to make the user code simpler. It seems to me there is good reason that many languages implement virtual functions? So since SPAD does not support the OO approach to this, how about going to the opposite extreme and thinking how it would be done in a purely functional language like Haskell. I haven't got very far with learning Haskell yet but my guess would be that we would need to use an 'algebraic data type' like this: data SceneNode = rootNode [SceneNode] | groupNode [SceneNode] | lineNode [SceneNode] | materialNode [SceneNode] Could this be recursed over using Haskell methods? is there some way that SPAD could use algebraic data type approach? It would be nice to use static types to police the type hierarchy, as Ralf suggests, but not at the cost of adding complexity. If its simpler to police the type hierarchy dynamically each time a node is added to the tree then that would be OK with me. Martin Baker -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
