Just wondering if you'd seen the dynamic
datatype which basically gives you an "Any"
in ghc/hugs
> -----Original Message-----
> From: Jose Romildo Malaquias [mailto:[EMAIL PROTECTED]]
> Sent: 25 September 2000 12:14
> To: Chris Angus
> Cc: [EMAIL PROTECTED]
> Subject: Re: Extensible data types?
>
>
> On Mon, Sep 25, 2000 at 11:37:24AM +0100, Chris Angus wrote:
> > I've not seen this before,
> >
> > out of interest, why would you want/need such a thing?
> > >
> > > Is there any Haskell implementation that supports
> > > extensible data types, in which new value constructors
> > > can be added to a previously declared data type,
> > > like
> > >
> > > data Fn = Sum | Pro | Pow
> > > ...
> > > extend data Fn = Sin | Cos | Tan
> > >
> > > where first the Fn datatype had only three values,
> > > (Sum, Pro and Pow) but later it was extended with
> > > three new values (Sin, Cos and Tan)?
>
> I want this to make a system I am workin on flexible.
> Without it, my system is going to be too rigid.
>
> I am working on an Computer Algebra system to transform
> mathematic expressions, possibly simplifing them. There
> is a data type to represent the expressions:
>
> data Expr = Int Integer
> | Cte String
> | Var String
> | App Fn [Expr]
>
> An expression may be an integer, a named constante (to
> represent "known" contantes like pi and e), a variable
> or an application. An application has a functor (function
> name) and a list of arguments. The functor is introduced
> with
>
> data Fn = Sum | Pro | Pow
>
> meaning the application may be a sum, a product or a
> power.
>
> The project should be modular. So there are modules to
> deal with the basic arithmetic and algebraic transformations
> involving expressions of the type above. But there are
> optional modules to deal with trigonometric expressions,
> logarithms, vectors, matrices, derivatives, integrals,
> equation solving, and so on. These should be available as
> a library where the programmer will choose what he
> needs in his application, and he should be able to
> define new ones to extend the library. So these modules
> will certainly need to extend the bassic types above.
>
> If it is really impossible (theoriticaly or not implemented)
> then I will have to try other ways to implement the idea.
>
> The functions manipulating the expressions also should be
> extensible to accomodate new algorithms. The extensions
> is in a form of hooks (based on the Fn component of an
> application function) in the main algorithms.
>
> Romildo
> --
> Prof. José Romildo Malaquias <[EMAIL PROTECTED]>
> Departamento de Computação
> Universidade Federal de Ouro Preto
> Brasil
>
