This is for the record. I guess I stated my opinion on that topic already, but
I hope that restating doesn't make anybody angry, but rather helps making
things more precise. (I believe that iteration of informal discussion may help
make things more precise).
This is also why I crosspost.
"Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:
> On Wed, May 14, 2008 at 7:54 PM, Waldek Hebisch <[EMAIL PROTECTED]> wrote:
> > Note: personally I do not like namespace pollution and I would like to
> > have compiler mode (switch) which disables implicit declarations. But I
> > would like to have single language and tight rules may be too hard for
> > interactive users.
I support at least the single language part, and I think that many others see
that similar. For example, the SAGE people often stress that they use python,
a mainstream language. I do not know exactly whether they use a different
language at the interpreter level, but I'm quite sure that they don't.
> Many people believe that the two-level languages of Axiom is a strength: one
> for library development, and one for interpreter. Large scale programming
> (libraries) tend to impose different requirements than small scale
> programming (interactive uses).
Although this may be true, I had no problem at all doing rather large scale
projects in SPAD and Aldor, and no problem at all using the interpreter. Not
quite: for me it's a huge drawback of the interpreter that I cannot define
(parametrised) packages. Surprisingly (to me) often, I'd like to define
Pack(R: Ring): with f: R -> R == add (f a == something)
(the reason being that I sometimes need type information in "something", but
need the function f to work for several rings. Note that
f(R: Ring, a: R): R == something
would not help here, since I want to have automatic "guessing" (AKA type
inference) for R.)
> I would like to see a mode detailed an elaboration of that rule, along with
> how overload resolution should proceed. Note: this is not a suggestion that
> the rule will not work, rather, I would like to see the rule elaborated so
> that I can compare where it leads to simpler language for interactive users
> and library users.
Yes, I support this, too.
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.
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 guess that a few places you (Gaby) discovered when making the change
in the compiler concerning locality of looping variables are mistakes, maybe
I'll look into a few.
In any case,
+ uf: SUP
for uf in listpol repeat
--note uf and d not necessarily primitive
degree gcd(uf,d) =0 => nolift:=false
looks very strange to me. I'd really prefer
for free uf in listpol repeat
--note uf and d not necessarily primitive
degree gcd(uf,d) =0 => nolift:=false
In fact, I think that
f() ==
a: R := 1
for a in 1..10 repeat dosomething()
a
should be either illegal, or perhaps return 1 and issue a warning.
> > 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!".
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
