axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: [Aldor-l] [Axiom-math] Are Fraction and Complex do


From: Stephen Watt
Subject: [Axiom-developer] Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Date: Wed, 17 May 2006 09:56:05 -0400
User-agent: Mutt/1.4.1i

Dear Christian et al,

I've been following your discussion with interest.

The way things are intended to be in the Aldor *language* is as follows.

Expressions in type context (e.g. T in  a: T := ...) must be formed from 
names that are constant in that scope.  These names may be of any type 
and so may refer to domains, domain-constructing functions, integers, 
lists or other things.

The constant-valued names may have definitions that are public or private.
In principle, public constant definitions are expanded in the type expression.
This produces a potentially infinite tree (that can be represented as a finite
graph),  e.g. R == Record(a: A, b: Union(s: S, r: R)).  Additionally, names
in a type expression are resolved to their full form (indicating their origin,
e.g. +$Integer).  This gives the _expanded type expression_.

Two types are statically equivalent if their expanded type expressions
are syntactically equal.

As noted earlier in this thread, the language definition leaves undefined
the number of times expressions in type context are evaluated.  This allows
a wide range of code transformations.

The Aldor *compiler* provides an implementation which approximates this.


The fact that the symbols in type expressions are constant in the scope of
the type's use allows programmers to adopt a functional style for type
expressions.   

There are ways to circumvent this, however, if the programmer makes an 
explicit effort:

-- Aliasing of values and "pretend" can be used to update values pointed
   to by constant names.

-- A constant-valued name may have a side-effecting function as its value
   so a domain constructor that depends on side effects can be written.

-- A constant-valued name may have an updatable data object as its value.

Forcing type expressions to be purely functional and terminating would
of course have been a possibility, but that would have required introducing
a number of new concepts into the langauge.

-- Stephen


On Wed, May 17, 2006 at 03:02:57PM +0200, Christian Aistleitner wrote:
> Hello,
> 
> >OK, I see now. It could be -- in the non functional setting -- that
> >
> >a: NonFunctionalDomainConstructor Integer := something
> >b: NonFunctionalDomainConstructor Integer := otherthing
> >
> >and NonFunctionalDomainConstructor exports an operation f(%, %), but I  
> >still
> >*shouldn't* be able to call f(a, b), since a and b come from different
> >instantiations of NonFunctionalDomainConstructor Integer?
> 
> yes.
> 
> >(Not currently, since it seems that Aldor instantiates a Domain only  
> >another time, if the argument has changed.)
> 
> No. Sometimes, a domain is not re-instantiated, even if the argument  
> changed ;)
> See my Dom example:
> http://www.aldor.org/pipermail/aldor-l/2006-May/000205.html
> 
> >>> I would imagine that Dom(x) and Dom(y) are the same, (i.e.,  
> >>instantiated
> >>> only once) if x and y are the same, i.e., if (eq x y) as opposed to  
> >>(equal
> >>> x y), but I'd be interested to find something about this in the
> >>> documentation.
> >>
> >>That's the main point ... what kind of "equals" does Aldor apply?
> >>I do not know. Just look at the Dom example I gave.
> >
> >which one?
> 
> http://www.aldor.org/pipermail/aldor-l/2006-May/000205.html
> 
> >>> I'd leave it unspecified.
> >>
> >>Leaving compiler behaviour unspecified is a bad thing.
> >
> >No, not necessarily. Maybe I should have said "undefined". In Lisp this  
> >is the
> >case for many things. It's basically saying: "in principle it is an  
> >error, but don't expect that I throw an error message".
> 
> Thereby you specify it. You say the thing of interest is wrong. And you  
> specify that an error might be thrown. But you must not rely on it.  
> Specified.
> 
> >>No user would be allowed to rely on calling List( Integer ) two times  
> >>would give an identical result.
> >
> >I agree that I wouldn't leave *this* unspecified, but I could imagine  
> >saying:
> >
> >* domains are "compatible" (i.e., you may use append in the example you  
> >gave
> >  above), if their arguments were identical. In this case, the domain is
> >  instantiated only once.
> >
> >* if their arguments were not identical, the behaviour is unspecified
> 
> Such a definition would be contradicting the current implementation of the  
> Aldor compiler :)
> And what do you mean by "identical"? The whole thing is terribly  
> complicated (at least for me).
> 
> --
> Kind regards,
> Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]