>> I also read Waldek's remark. I somehow must agree that 'coerce' is
>> almost always bad and hard to understand, but since it generates better
>> code, I'd be much more for coerce than Waldek.
>
> I do not see how using 'coerce' can be bad - after all when we define
> the coercion somewhere else in the code, 'coerce' is the name that we
> are required to use. To me it is more direct than requiring the user
> parse the expression 'x+->x::EXPR' and to realize that internally this
> just generates a call to 'coerce'.
If I (as a human) see "coerce" in the code, then I have hard times to
figure out the source an target types. If I had an editor that would
show me the types if I hover over "coerce", it would be easier to
understand the sources. Just imagine you have the source code in printed
form. How much time does it take for you to figure out what some piece
of source code really means if it contains some "coerce", but the actual
types are hidden somewhere else in the source. Writing code is sometimes
easier than understanding what other people had in mind.
Your "coerce@(A->B)" style could cure that very well. I like it.
> Perhaps the difficulty is that although we are writing in SPAD and
> functions are available as first-order objects, really we are not so
> used to passing functions as values ... so we are looking for some
> kind of syntactical reminder that this argument really is a function.
I have certainly not a problem in passing functions as arguments. I have
a problem in understanding an identifier (here "coerce") that is soooo
heavily overloaded that its meaning can only be understood if the source
and target types can easily be figured out.
>> Maybe introduction of a local macro
>>
>> liftToPer ==> coerce
>>
>> or a function
>>
>> lift2Per(k: K): % == k::%
>>
>> and then using lift2Per in 'map' instead of coerce would be much more
>> readable and this one function indirection can certainly be compiled
>> away. But all of that should be done after everything is in lambda-notation.
> No, I do not like introducing macros just for creating synonyms. We
> can just as easily provide this information in a short comment.
Of course! How could I forget that one can add a comment? Stupid me.
>> Additionally, I must say that in some places I even don't find the
>> lambda notation very readable.
> Could you explain? Do you mean that you would rather not used
> functions as values if this is not absolutely necessary to the code?
It's more to do with the meaning of the parts and the length of the
construction. I cannot say that I find
kereval(k, lk, lv) ==
match(lk, lv, k, (x : K) : % +->
map(y +-> eval(y, lk, lv), x))
any more readable than the initial
kereval(k, lk, lv) == match(lk, lv, k, map(eval(#1, lk, lv), #1))
Without some comments or without investing a lot of time in figuring out
the involved functions, I have no chance of knowing what is going on.
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
