Re: Declare variable type within function

On 17 Mar 2008 17:27:26 +0100, Martin Rubey <[email protected]> wrote:
> "Bill Page" <[email protected]> writes:
>
>  > >  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)
>
>
> Angelos' trick is better: select would have to consider every element of x...
>

Define "better". I said it was more "transparent".

The Angelo's example actually produces:

(3) -> foo(x)==(L:=[x.1-x.1]; L:=append(L,x))
   Compiled code for foo has been cleared.
   1 old definition(s) deleted for function or rule foo
                                                                   Type: Void
(4) -> foo([1,2,3])
   Compiling function foo with type List PositiveInteger -> List
      Integer

   (4)  [0,1,2,3]
                                                           Type: List Integer

So a "better" definition for this function might be just:

(5) -> foo(x)==concat(0,x)
   Compiled code for foo has been cleared.
   1 old definition(s) deleted for function or rule foo
                                                                   Type: Void
(6) -> foo([1,2,3])
   Compiling function foo with type List PositiveInteger -> List
      Integer

   (6)  [0,1,2,3]
                                                           Type: List Integer

>  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.

>  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...)

Regards,
Bill Page.