[Axiom-developer] prototypes (was:[axiom-mail] Declare variable type within function)

[Bill Page]

> > "Bill Page" writes:
> > > Angelos Mantzaflaris wrote:
> > > >  But I can play tricks like this:
> > > >
> > > >  foo(x)==
> > > >         L:=[x.1-x.1]
> > > >         L:= append(L,x)
> > > >         return L
> > > >
> >
> > > Although you might still consider it a "trick" I would suggest
> > > the following code that I think is more transparent:
>  >  >
>  >  >   foo(x)==
>  >  >          L:=select(a+->false,x)
>  >  >          L:= append(L,x)
>  >
>  >
> On 17 Mar 2008 17:27:26 +0100, Martin Rubey wrote:
> > Angelos' trick is better: select would have to consider every
> > element of x...
> >
>
On 3/17/08, Bill Page wrote:

> Define "better". I said it was more "transparent".
>
> ...
>
>  >  But maybe you like
>  >
>  >    foo(x)==
>  >           L:= if empty? x then x else rest [first x]
>  >           L:= append(L,x)
>  >
>
> You are joking, right?  :-) ... what you wrote seems horribly
> obscure to me.
>

Ok, I do agree that it is more efficient then 'select'.

>
> >  The best way to go forward is of course to make type inference
> > better. (And I do believe that it's already quite OK, contrary to Bill)
> >
>
>
> I agree it should be better but I think making it better without
>  changing the whole underlying philosophy could be very difficult.
>  (Think about Haskell as an example of a strongly typed language
> with much better type inference.). And as you know there are
> some cases where Axiom produces some spectacularly unexpected
> results for the new user ... Probably some of these cases could be
> prevented by a careful re-design of the system of coercions available
> by default to the axiom interpreter, but then one might risk also
> further weakening the set of inferences that are possible.  (I guess
> this is a subject best continued on the developer list...)
>

Thus ...

Martin, I think that this question and the examples might suggest that
in general there is a need for object constructor functions that take
*prototypes* as parameters instead of being just nullary functions.
E.g. in List we have

  empty()

which in the interpreter we would have to explicitly package call like:

  L:List(Integer) := [1,2,3]
  ...
  E:=empty()$List(Integer)

even though our intention might be just to create E as an object of
the same type as L whatever the type of L happens to be.

But if the domains in AGG also exported the following unary operator:

  with ...
    empty(x:%)->%

  == add
  empty(x:%):% == empty()$%

then in the interpreter we could simply write:

  L:List Integer := [1,2,3]
  eL:=empty(L)

  S:String := "1,2,3"
  eS:=empty(S)

  etc.

where L is the "prototype" for the list we intend to create. The
interpreter should be able to find the correct 'empty' operator simply
by applying it's usual function selection rules.

There are other functions that might similarly benefit by the use of
prototypes. E.g. 0(zero) and 1(one) for domains in RING.

Regards,
Bill Page.