On Fri, May 16, 2008 at 2:45 AM, Martin Rubey wrote: > > Bill Page writes: > >> 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. > > Could you please repeat the reason to me.
The primary underlying reason is to improve the readability and correctness of the code. There are already examples of incorrect or dubious coding styles in the Axiom library that we have been discussing. Because current shares this semantics with Axiom it is likely that examples of such coding could also be found in the Aldor libraries. In general I am in favor of changes to the panAxiom library compiler and Aldor that encourage or enforce better coding styles without compromising the expressiveness of the language. > So far I can only see the drawback that > > if cond > then x := f() > else x := g() > h(x) > > becomes > > x: sometype > if cond > then x := f() > else x := g() > h(x) > >From the point of view I expressed above, this looks like an advantage to me. > By the way, how will this work in the interpreter? I.e., do you think it > makes sense to force a rewrite of the currently legal > > f x == (if zero? x then z := 0 else z := 1/x; g z) > > to > > f x == (z := if zero? x then 0 else 1/x; g z) > > I'm *not* saying that the first form is better, but I doubt that one of > the two is *always* better. However, the first form becomes illegal > SPAD and interpreted language is to be (as far as possible) identical. > I think the second form is better, but I am not sure it is good idea to force the interpreted language to follow so closely the compiled language. The interpreter allows a form of definition of functions that is very different than the compiler. (You did not specify any types at all in the above input to the interpreter so technically what you wrote does not even define a function.) By design this is not possible in the compiler but it is very convenient in the interactive user interface provided by the interpreter. If you add explicit types to this definition to make it a directly compilable function, it might be natural to write: f(x:Integer):Integer == (z:Integer; if zero? x then z := 0 else z := 1/x; g z) just as one might in the compiler. >> >> 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. > > At least the impossibility to overload local functions is a huge drawback > of current SPAD in my actual work. I am sorry, I was under the mistaken impression that this was already possible in SPAD. As you say, it is not: http://axiom-wiki.newsynthesis.org/SandBoxOverloading Could you explain why it is a drawback to have to define external functions? > And since I adhere to the principle that Integer -> Integer is a type > just as any other type, I do not see why one would want to make > a difference there. I don't think this issue depends on treating 'Integer->Integer' in any special manner. It appears that local overloading in SPAD is not allowed in any case. > (I admit I didn't think through why variable overloading is forbidden > in Aldor, but so far I didn't need that anyway). > > Note that one of the most fundamental reasons why the species (AKA combinat) > project doesn't work well with panAxiom / SPAD, is that functions are treated > specially in panAxiom / SPAD. > > If you can come up with a SPAD-compatible replacement for the construct > > SPECIES == (L: LabelType) -> CombinatorialSpecies L; > Plus( > F: SPECIES, > G: SPECIES > )(L: LabelType): CombinatorialSpecies(L) == add [...] > > you shall be praised and I'll stop talking about language semantics from > now on and refer to you instead. > Please don't :-) I am sorry, but without more explanation and examples I do not understand what you are asking for (besides better support for dependent types in SPAD). 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
