On 08/06/2008 04:07 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke <[EMAIL PROTECTED]> writes:
>
> | > What is nonconstructive about
> | > forall(T: Type)
> | > identity(T x) == x
> | > which can be used as
> | > identity 4.4 -- T deduced to Float
> | > identity "string" -- T deduced to String
> | > ?
> |
> | Just one remark it certainly is a bit off-topic.
> |
> | You certainly know that Aldor has functions of the form
> |
> | string: Literal -> %
> |
> | that can be exported and implemented by any domain.
> | Do you intend to provide something like that in OpenAxiomm, too?
>
> I saw the suggestion, I've yet to convince myself that it solves the
> original problem it was intended to solve conveniently.
Could you state that problem? (I only know of the solution, 42 ;-).)
> Certainly that is not the only design choice. For example, the
domain Literal
> could have been parameterized by the type of the fundamental domain of
> the literal, so that I could write
> coerce: Literal String -> %
> instead of `moving the type of the literal into the function name'.
Hmmm, maybe you as a language designer knows better than me... but if I
write something like
coerce: Literal String -> %
into the exports of String, that looks a bit odd to me. Why? Because, it
would look like
String: with {
...
coerce: Literal String -> %
} == add {
...
coerce(l: Literal String): % == ...
}
That leads to a mutual dependent definition. Not bad in itself, but I
somehow don't see what the representation of Literal(X: ???) would be.
Somehow I must connect this stuff with functions that are builtin into
the compiler, no? So what is bad with having different function names for
something that "looks like an interger",
something that "looks like a floating point number", and
something that is enclosed in double quotes?
I fail to see what parametrizing Literal might bring (and how it would
be done at all).
> Haskell also uses a different design choice. The design space is not
> a singleton. I have to appreciate better the problem to pick one of
> the solutions. I know where I would like to see literal 4
> interpreted in a way I want; that isn't my problem with the proposed
> Literal domain.
Well, you certainly know that the literal 4 that the (Aldor) compiler
sees can have *any* type. Or rather the compiler replaces that 4 simply by
integer "4"
where "4" is here not something of type String but rather of type
Literal. So if some domain D exports
integer: Literal -> %
then if all is well, 4 could mean something of type D in a certain context.
Personally, I find that very flexible since it allows to also "overload"
numbers. Maybe in some context you would like to write 2 to mean the 3x3
diagonal matrix with 2's in the diagonal. That is already possible in Aldor.
Can you elaborate on your idea with the parametrized Literal.
And... of course I agree that there are many design options.
> | So then if I add a function
> |
> | string(l: Literal): % == 1;
> |
> | to the definition of Float, the statement
> |
> | identity "string"
> |
> | becomes ambiguous. I don't think that is a problem.
> Now, we have double ifs. But just in case OpenAxiom has the domain
> Literal (not parameterized), I don't see the ambiguity: T is deduced
> to Literal.
Well assume a context with
string(l: Literal): % == 1;
added to Integer and "import from Integer, String". Then
"string"
could be either of type String or of type Integer.
Now assume I put that into
stdout << "string"
Then, since there is a function
<<: (TextWriter, %) -> TextWriter
exported by Integer and String, the compiler has no chance to select
just one of the two choices and thus must fail.
Ralf
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
