On Thu, May 15, 2008 at 4:24 AM, Martin Rubey wrote:
> ...
> In this spirit: if there are good reasons for loops and conditionals
> introducing new scope, I'm all for it. In that case, I'd argue that the
> spec of Aldor should also change. But, as I said before, in case of
> doubt, I'd rather follow the aldor spec.
I think there are good reasons, therefore I would encourage you to
pursue the idea that the spec of Aldor should also change.
>
> To be honest, I think relying on these scoping rules seems to me bad style
> anyway, so the rules shouldn't matter too much. Giving a warning would be
> good though.
I disagree strongly with this. I think the scoping rules matter a
great deal. Clear semantics are necessary for compiler development.
It is essential that a programmer is able to rely on exactly what the
rules are in any given situation. And it is important that these rules
be simple, powerful and allow freedom of expression.
> ...
>> Waldek wrote:
>> > Note: I am _not_ comfortable with the argument above -- I prefer to
>> > have very clear and simple semantics for core constructs and to make
>> > illegal problematic things. But I supect that Axiom creators may have
>> > use such arguments...
>>
>> Probably. But, they also decided that a variable and a local function
>> must have at most one mode.
>
> Hm, I doubt that this was a decision. I think it was rather "too lazy to
> implement this right now." As a hint: there are quite a few comments
> like "should be local but conditional", and "un-export when the compiler
> accepts conditional local functions!".
>
I do not see how conditional local functions has anything to do with
modes of variables and local functions. Right now only exported
functions can have multiple modes. This allows for a polymorphic style
of coding when calling library functions - i.e. identically named
functions (usually) perform generically similar functions.
While allowing multiple "modes" for variables and local functions, so that
f:Integer
f:Float
f:Integer -> Integer
f:Float -> Float
refer to two *different* variables and and two different functions
all with the same name in the same module would in principle be be
possible (and is allowed in some programming languages), it is not
clear that such local polymorphism is of much advantage. Since code
modules in Axiom are usually short, of two or three pages in length at
most, the economy and semantic connotation of using the same name for
something adds very little to the readability of an algorithm.
On the other hand, there is a tendency to want to use polymorphism
when really a Union is meant - there is really only one variable but
it can have values of two or more different types. For example, the
following type definition:
f:Union(Integer,Float,Integer->Integer,Float->Float)
f:=2
f:=3.14592
f:=(x:Float):Float +-> sin(x)
Unfortunately the interpreter currently fails to apply 'f' as a
function in this case:
(1) -> f:Union(Integer,Float,Integer->Integer,Float->Float)
Type: Void
(2) -> f:=(x:Float):Float +-> sin(x)
(2) theMap(Closure)
Type: Union((Float -> Float),...)
(3) -> f(3.1)
There are 30 exposed and 3 unexposed library operations named elt
having 2 argument(s) but none was determined to be applicable.
Use HyperDoc Browse, or issue
)display op elt
to learn more about the available operations. Perhaps
package-calling the operation or using coercions on the arguments
will allow you to apply the operation.
Cannot find a definition or applicable library operation named elt
with argument type(s)
(Float -> Float)
Float
Perhaps you should use "@" to indicate the required return type,
or "$" to specify which version of the function you need.
(3) ->
---------
I consider this a bug.
Regards,
Bill Page.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
