On Sat, May 17, 2008 at 9:57 AM, Ralf Hemmecke <[EMAIL PROTECTED]> wrote:
>
> Hmm, actually I don't quite understand you here. In union(b==3), the "b=="
> is in some (other) sense also optional. Only in case where the types of the
> union are identical, that part would be necessary.
>
> Clearly, that are to versions of "optional", but I like the equal syntax
> using "==" of keyword argument and also for the case of the union above.
I have domain and functions that operate on Syntax objects. I would
like to write
check
MyList(T: Domain): Inductive Domain ==
MyNil
MyCons: (T,%) -> %
could you clearly explain to me how I get '==' systematically and
reliably not interpreted as OPTARG?
>
> In fact, if I define a function (sorry, it's again Aldor)
>
> foo(b: Integer): Integer == ...
>
> then it should be possible to call foo via
>
> foo(3)
> foo(b==7)
>
> so also here the "b==" is optional similar to the union case. See AUG
> Sections 6.3 + 6.4.
You should know by now that `Aldor does it that way' is no substitute for
rational argument, at least if you're discussing directions for OpenAxiom.
>
> If I define it via
>
> foo(b: Integer == 1): Integer == ...
>
> then also
>
> foo()
>
> will be accepted and be equivalent to foo(1).
>
> Could you clarify what exactly you don't like with that? Yes that is
> overloading of ==, but to me it seems quite intuitive to use "==" for the 2
> cases: keyword argument, default value for optional argument.
You should know by now that, I'm comfortable with overloading.
My issue isn't overloading -- defined as the same symbol having different types.
My issue is with a sequence of characters that get parsed into different tokens
depending on the context.
And since your brought it up, I'm not happy with '=' being parsed as '=' or
'equation' depending on the context.
>
> Ralf
>
-------------------------------------------------------------------------
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
