It is good to see this exchange of ideas. At the end of the day different branches of the "Axiom family" might take different paths but at least some the reasons will have this way been better documented.
On Tue, Jan 17, 2012 at 12:59 PM, Gabriel Dos Reis wrote: > ... > From my point of view, a macro is a `papering over some pesky > imperfection'. The definition of domain or a category is fundamental > and macros should not be the first thing people have to encounter. +1 > And when I want to attract people used to languages with similar > syntax (hello Haskell!), I don't even want to given them incentives to > ridicule the syntax. > ... I have a similar "lack of respect" for macro usage. SPAD should consistently be a high level language. Macros belong (perhaps) at a lower level in Boot and in Lisp. If there is something that you think requires a macro in SPAD I would take that as a criticism of the language. It seems to me that even the use of the ... where clause should not encourage us to think in terms of macros but rather as a way of locally defining a context. > | > | For example, look at: > | > | dummy == new()$SE :: F > | > | in combfunc.spad.pamphlet. This is _very_ unlike constants. > I think this usage is what Ralf referred to as "delayed assignment". > In fact, I think this is an example that is illustrative of the constant > vs. nullary function dichotomy. > In this case `dummy' is an abstraction that is supposed to be > generative, e.g. evaluated every time and generate new value. That is > called a function and it should have been written as > > dummy(): SE == new()$SE::F > ... > I would argue that the function definition is much more reflective of > the intent and more elegant. Writing it as a macro only hides the > original intent, it does not make it clearer. > I think these semantics are obviously more economical than thinking of nullary functions as "delayed assignment". Regards, Bill Page. -- 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.
