On Thu, Apr 3, 2008 at 2:02 PM, Gabriel Dos Reis wrote:
>
> ...
> The truth is that
>
> reduce(+,[])
>
> is doubly ambiguous: there are at least a dozen of stuff called
> '+'. And [] is the empty list of type any type. I don't see how
> 0 could be seen as the result.
>
I suppose the interpreter is free to make whatever "reasonable" type
inferences we want but I agree that it should at least be consistent.
>
> Bill Page writes:
> ...
> | and as I said previously, I find it a little "magic" that the
> | expression 'f(first x,myreduce(f,rest x))' apparently compiles as the
> | naive user might expect.
>
> a very special naive user then :-)
>
We are all very special, aren't we? ;-)
>
> | Really should have written '_+$Integer'
> | instead of just '+'
> |
> | (2) -> myreduce(_+$Integer,[])
> | Compiling function red with type (((Integer,Integer) -> Integer),
> | List None) -> Integer
> |
> | (2) 0
> | Type:
> NonNegativeInteger
>
> Even there, I would have expected a type error. The type of the
> operation does not match the type of the contained element (None).
>
Agreed. The interpreter should have smarter but of course I did not
give it enough information. In the interpreter when I write:
red(f,x) == ...
I am not really giving a *function* definition. Since no types are
specified this construction is usually called a "mode", I think. But
even if I am completely specific so that the interpreter has no
choice, then the result is that same - although apparently now
type-correct:
(5) -> red(f:(INT,INT)->INT,x:List INT):INT==(#x>1 => f(first x,red(f,rest x));
#x=1 => first x; f=_+$INT => 0; f=_*$INT => 1;error "use: reduce(op,list,id)")
Function declaration red : (((Integer,Integer) -> Integer),List
Integer) -> Integer has been added to workspace.
Compiled code for red has been cleared.
1 old definition(s) deleted for function or rule red
Type: Void
(6) -> red(_+$Integer,[])
There is more than one * in the domain or package Integer . The one
being chosen has type ((Integer,Integer) -> Integer) .
Compiling function red with type (((Integer,Integer) -> Integer),
List Integer) -> Integer
(6) 0
Type: NonNegativeInteger
Notice however the new warning message.
>
> |
> | But now perhaps equally "magic" is that 'f=_+ => 0' again naively just
> works ...
> |
> | In the library code what I really wanted was something like this
> | modification to ListAggregate:
> |
> | reduce(f, x) ==
> | if empty? x then
> | if S has AbelianMonoid then
> | f=_+$S => 0$S
> | if S has Monoid then
> | f=_*$S => 1$S
> | error "reducing over an empty list needs the 3 argument form"
> | reduce(f, rest x, first x)
> |
> | since presumably then we are checking the specific algebraic
> | properties of the operation. But this does not compile in Spad.
>
> Yeah.
>
Could you be more specific? Would you expect Spad to be able to
compile this or not?
Regards,
Bill Page.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
