Re: Some modules from Modula-2

[Mike Griebling <grieblm@trt.allied.com>]

> On Dec 18 Mike Griebling wrote:
> 
> > > Mike wrote:
> > I have no objection to your naming convention.  It will be implemented so.
> > It will have additional functions which are not part of the ISO standard
> > however (sinh, cosh, tanh, inverses, and a few others).
> 
> If you are going to extend a module defined in some kind of standard, my
> preference is to put the extensions in another module with a similar name.
> Otherwise it defeats the purpose of having a standardised module.

I guess, I can use the OakMath(L) modules to hold the other functions since
they are part of that standard.

> > > I don't see how you can conveniently implement the Complex modules
> > > without a builtin COMPLEX type.  Take for example the function
> > >   PROCEDURE conj (z: COMPLEX): COMPLEX;
> > > This can only be declared when COMPLEX is a pointer type, which isn't
> > > very nice.  And complex constants like "i = CMPLX (0.0, 1.0)" aren't
> > > possible at all.
> >
> > What's wrong with a pointer-based implementation?  The complex "constants"
> 
> I don't think there's anything wrong with it either. Given an efficient
> garbage collector, that is.

Would your garbage collector be available for other back-end writers to use?
Do you consider it an efficient garbage collector?
 
> Frank

Michael G.