Ralf,
I think the semantics of union and case are quite clear (provided of
course that the types in the union are unique). It seems fine to me
to read "u case A" as telling me explicitly that in the body of this
condition "u *is* A".
For the purposes of writing self-documenting easy to read code perhaps
f(u: Union(A, B)): String
u case A => u.x
u.case B => u.x
might be preferable but it seems to me that in this example explicit
coercions such as
f(u: Union(A, B)): String
u case A => (u::A).x
u.case B => (u::B).x
do not add much to the readability though perhaps if u occurs
somewhere deeper in the body of the conditions it might help
u case A =>
...
(u::A).x
...
( At least for those people who remain "indentation challenged". :-)
Regards,
Bill Page.
On Fri, Feb 26, 2010 at 5:19 AM, Ralf Hemmecke <r...@hemmecke.de> wrote:
>> The compiler is supposed to know that after 'case' test one of
>> branches is impossible and automatically coerce to the other.
>
> That sounds similar to the fact that in a construction like
>
> if Dom has SomeCat then
> THEN_BODY
> else
> ELSE_BODY
>
> Aldor will augment Dom inside THEN_BODY to additionally make the exports of
> SomeCat available. (Which is a good thing.)
>
>>> In my opinion A and Union(A,B) are two different types and I don't want
>>> any _implicit_ coercion.
>
>> Well, after 'case' test such coercion is quite analogous to
>> allowing NonNegativeInteger in place where Integer is expected.
>
> That's probably true, but I still don't want implicit coercion. If I were a
> machine, I probably wouldn't care, because when I read the sources I would
> always exactly know the type of the variable at hand.
> As a human, it is much harder to keep track of the variable types.
> Just read the current algebra sources. A lot of functions just mention their
> type only in the category part and not again in the implementation part.
> Suppose the category part is just a big join of a lot of categories. If you
> now want to find a bug (suppose you are not the original programmer), you
> just have to waste time to figure out the input and output types of the
> function.
>
> I wouldn't probably care if we have a proper IDE like eclipse that shows me
> the type of a variable when I hover over it with my mouse. But as long as we
> don't have that I will be much in favour of adding redundancy to the source
> code, just because it becomes easier to understand the code of others.
>
>>> Just a quick example where implicit coercion is bad.
>>> Suppose A and B are given as
>>> A === Record(x: String, y: String, z: Integer)
>>> B === Record(y: String, x: String, z: String)
>>> and u is of type Union(A, B).
>>> What code should the compiler produce for
>>>
>>> f(u: Union(A, B)): String
>>> u case A => u.x
>>> u.x
>>>
>>> ?
>>>
>>> Just compute f(["a", "b", "c"]...@b). Is the result "a" or "b"?
>>
>> Should be "b". If you want to report bug say what you get.
>
> I'v tested that and it indeed returns "b". But now as a human I look at the
> source code and see that strange looking code. It returns u.x for case A and
> otherwise it returns u.x. Sure why check for being in case A?
> From a human point of view
>
> f(u: Union(A, B)): String == u.x
>
> is much simpler to understand. Arrrhhh, well, it's wrong. (Except, we add
> another implicit behaviour to the compiler that inserts this "if case A"
> since the compiler sees that u is a Union. Brrrrr. I wouldn't like that.)
>
> Ralf
>
> --
> You received this message because you are subscribed to the Google Groups
> "FriCAS - computer algebra system" group.
> To post to this group, send email to fricas-de...@googlegroups.com.
> To unsubscribe from this group, send email to
> fricas-devel+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fricas-devel?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to fricas-de...@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
