[clean-list] Passing an environment around

[=?iso-8859-1?Q?Jos=E9_Romildo_Malaquias?=]

On Thu, Oct 19, 2000 at 09:17:26AM +0100, Jerzy Karczmarczuk wrote:
> José Romildo Malaquias  <== F.S.A.Zuurbier :
> 
> 
> > > I can think of another possibility you may have to wait for:
> > > If in current Clean you can make * or + an infix operator,
> > > why can't I make (add env) an infix operator? Or maybe I CAN,
> > > I have not tried.
> > 
> > This possibility looks good to me. But I could not find a way
> > of making an expression an infix operator, like you sugest.
> > I am not sure whether Clean support it.
> 
> 
> M. Wierich says plainly NO.
> Emmm.... Can't you use macros here?

I can not see how macros would help. Macros are like
(restricted) functions whose applications are
inlined by the compiler. Having the functions

   add :: Env Exp Exp -> Exp
   mul :: Env Exp Exp -> Exp

one can write expressions like

   mul env (add env e1 e2)
           (add env e3 e4)

When turning (add env) and (mul env) into macros, one
still needs to specify the env argument and

   add` :== add env
   mul` :== mul env

is not valid. Macros in Clean is not the same as in
other languages like C (where they offers nothing more than
a text substitution engine). So macros can not be used
to reduce the number of arguments explicitly writen in
a function call.

> ====================
> 
> Another posting of José Romildo Malaquias:
> 
> 
> > > If you tell me what operations on BigInts you need I'll 
> > > send you an ExtendedArtih library that works on Clean 1.3.2.
> > 
> > I need the basic operations on integers:
> > 
> >         negation
> >         addition
> >         subtraction (not essential,...)
> >         multiplication
> >         division (quotient and remainder)
> >         power (not essential, ...)
> > 
> >         equality
> >         relations (< <= > >=)
> > 
> >         toString
> >         fromString
> 
> ++
> 
> I think you might (as I would myself...) need also
>      the conversion from and to small integers (where applicable)
>      the conversion from/to reals

For development using my CALG library that would be useful if
one wants to work also with small integers or floating pointer
numbers. But to the library itself that would not be so
useful, as the library addresses only exact calculations.
There is no aproximations for rational, real or complex numbers:
the canonical form for 2/3 is
   App Pro [Int 2, App Pow [Int 3, Int ~1]]
Also the integers in CALG are always of arbitrary precision.

> But if you really need all this in order to have something
> workable, not necessarily very efficient, it is quite easy to
> build inf. precision integers in Clean itself! The algorithms
> take 3 - 10 lines...

For sure. I and Antônio Eduardo Costa Pereira once wrote it
and achieved performance comparable with gmp.

> [...]
> 
> By the way. There was an attempt to build a symbolic algebra package
> in Haskell (I lost the reference). It seems that JRM project is quite
> similar.

I believe you are referring to some questions I have issued
in the Haskell mailing list related to extending data types
and function definitions (that is, given an algebraic data
and functions manipulating its values, would it be possible
to new value constructors to it, and now clauses to the
functions without redefining them?). CALG is the library that
needs this feature in the implementation language to keep
the project modular. I have a preliminary implementation of
CALG in Clean and I am porting it to Haskell. So, as to my
knowledge, there is not another similar project.

> I have to say that I feel a bit uneasy about that. I see the
> creation of an undiscriminated expression processor, like Maple
> (or Reduce), with dynamic typing and structural simplification
> rules only, while --

Well, it could have its applications, as Maple, Reduce and 
Mathematica have, but with the advantage of a modern, lazy,
typesafe, pure functional language as the language of
programming the applications.

> I would personally prefer A LOT to have something along the lines
> of Axiom/Magma/MuPAD, with strong categorization of objects.
> With domains, axioms, etc.

This comes at the "Sugestions for Future Works" of my dissertation.
Certainly it is more interesting and difficult than CALG.

Regards,

Romildo
-- 
Prof. José Romildo Malaquias <romildo@iceb.ufop.br>
Departamento de Computação
Universidade Federal de Ouro Preto
Brasil