"Bill Page" <[EMAIL PROTECTED]> 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. 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)
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.
> > 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.
Sorry, I was not precise enough, it seems: I did not intend to say that it
wouldn't matter to have rules. Only, that it wouldn't matter too much what
these rules are.
> >> 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.
At least the impossibility to overload local functions is a huge drawback of
current SPAD in my actual work. 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 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.
Martin
-------------------------------------------------------------------------
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
