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: Ralf Hemmecke
Subject: [Axiom-developer] Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Date: Tue, 16 May 2006 00:35:36 +0200
User-agent: Thunderbird 1.5.0.2 (X11/20060420)

| System(): with {
|    timestamp: Integer;
|    cpuTemperature: Integer;
| } == add {
|    timestamp: Integer == { obtain the timestamp somehow }
|    cpuTemperature: Integer == { obtain the timestamp somehow }
| }

If this must be a type, what are the terms that inhabit it?

In Aldor there are packages and domains. Their only difference is that the latter exports something involving %. The above code doesn't do this so it is a package. In oo-speak its a class that only exports static constants. There are no instantiations of elements of that package.

| Of course, you can rewrite it to
| | System: with {
|    grabData: () -> %
|    timestamp: % -> Integer;
|    cpuTemperature: % -> Integer;
| } == add {
|    macro Rep == Record( ts: Integer, temp: Integer );
| | grabData(): % == { | per record( obtain the timestamp somehow, obtain the temperature | somehow );
|    }
| | timestamp( a: % ): Integer == { (rep a) . ts; };
|    cpuTemperature( a: % ): Integer == { (rep a) . temp; };
| }
| | , but would that be better? The latter version is the one we are more used | to, but is it really better?

I would claim is it better.  However, I would challenge the claim that
the former is a function that define types.

I would also claim the second is better. Christian, if you call the first System() only once then you wouldn't make it a function, but you certainly like to call System() several times.

| To determine the given temperature and timestamp for the system involves 1 | Function call for non functional Domains and 3 for functional Domains.

I guess you are wrong.

In the first case, each time you want a time-temperature pair you must do like...

S == System();
t := timeStamp$S;
T := cpuTemperature$S;

in the second case it is

d := grabData()$System;
t := timeStamp(d)$System;
T := cpuTemperature(d)$System;

So what do you gain?

If I do not have a functional type system, how am I supposed to do "separate compilation"? How am I supposed to do calls?

I first thought you make a point, but

Cat1: Category == with {..}

Cat1 is a constant. Fine.


Cat2(R: Sometype): Category == with {...}

is equivalent to

Cat2: (R: SomeType) -> Category ==
  (R: SomeType): Category +-> with {...}

Again Cat2 is a constant. Also fine.

Dom1: Cat2(blah) == add {...}

That is a constant. But it should not be defined that way. In order to avoid complications it should be done via

Cat2BLAH == Cat2(bla);
Dom1: Cat2BLAH == add {...}

because later you might want to ask

if Dom1 has Cat2(blah) then ...

Of course, with a non-functional type system that might turn out to be false.

So, for every domain whose category involves a parameter one has to introduce a constant category with exactly that parameter. The same happens one level down. For every element of a parametrised domain, one has to introduce a constant domain (without parameter) before the element can be defined.

I have the impression that soon becomes unhandy. So I feel more on Gaby's side. Non-functional language at the element level, functional at type level.

But it has to be discussed what "equality of arguments" actually means in order to be able to speak about the functionality property, since not every type exports "=: (%, %) -> %".

Ralf





reply via email to

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