Please consider these comments as my personal opinions expressed for the sake of discussion only. I do not mean to be critical in any way of your effort to add Maybe as a domain in FriCAS. I greatly appreciate your initiative to make this happen.
On 24 September 2017 at 22:17, oldk1331 <[email protected]> wrote: > On Sun, Sep 24, 2017 at 9:50 AM, Bill Page <[email protected]> wrote: >> The meaning of 'empty' is more neutral than 'failed'. It is possible >> to use Maybe in situations where an empty value does not imply >> failure. > > As the docstring said (which I copied from Haskell's documentation): > > ++ Using Maybe is a good way to deal with errors or exceptional cases without > ++ resorting to drastic measures such as error. > > So I think "failed" is better than "empty". > My emphasis is on "exceptional cases" so "failed" seems like a synonym of "error" to me. In my test code I temporarily kept "failed" as the OutputForm for an empty Maybe but it still looks odd. > "empty" is also exported by aggregates, it might cause confusion in > > x : Maybe List Integer := empty() > 'Maybe' is a particular kind of aggregate in as much as the base semantics of both are that of a Functor (in the Haskell sense). What you wrote above does not seem any more confusing than x : List List Integer := empty() (1) -> x:Maybe List Integer := empty() (1) failed Type: Maybe(List(Integer)) (2) -> y:List List Integer := empty() (2) [] Type: List(List(Integer)) (3) -> x:Maybe List Integer := [] (3) [] Type: Maybe(List(Integer)) >> Instead of wrap/unwrap 'Maybe' should satisfy the exports of >> RetractableTo(R). Then 'Maybe' can export retractIfCan to convert to >> the old representation (at least until 'RetractableTo' is modified to >> use 'Maybe'). 'coerce' and 'retract' play nicely with the interpreter, >> e.g. > > I support to use Maybe explicitly than implicitly. I think Ralf will agree. I have not problem with being explicit. Do you mean that you deliberately design it to be less convenient in the interpreter? > I chooes the name "unwrap" from Rust. I like the duality of "wrap" and > "UNwrap". Naming things is sometimes a matter of personal preference but consistency is something more objective. Do you think Rust is a good model for FriCAS semantics? https://www.rust-lang.org/en-US/ > >> (1) -> x:Maybe INT := 2 >> >> (1) 2 >> Type: Maybe(Integer) >> (2) -> y:Maybe INT := 3 >> >> (2) 3 >> Type: Maybe(Integer) >> (3) -> x+y >> >> (3) 5 >> Type: PositiveInteger > > In my case, it will be > x := wrap 2 > y := wrap 3 > map(+, x, y) > > Your "x+y" can't handle when x or y is "failed". > I think + behaves properly when trying to add a "failed" value. It should return an error. But in the interpreter adding two Maybe values that do retract to an Integer should be expected to just work. Yes, using map is correct when you want to use + inside Maybe. >> I don't think it is a good idea to export a function like 'unwrap!', >> plus the naming convention is non-standard, but it is probably >> OK as a local function. > > I export that function for performance reason. I think the "!" > can give people attention. An example in codebase is > elt and qelt, but I don't think "qunwrap" is better than "unwrap!". > If you insist then do I think "qretract" is better than a name ending in !. >> Why not implement the 'maybe' operator? >> >> maybe : (R -> R, %, R) -> R >> ++ maybe(f,x,default) returns f(unwrap x) or default if failed?(x) >> >> then 'unwrapOr' could be just the two argument form of this function. > > Why is your signature useful? I add 'unwrapOr' because Aldor > has that signature. > The three argument form of 'maybe' is motivated by its use in Haskell, e.g. maybe(inc,x,0) This usage seems less natural: inc unwrapOr(x,-1) >> I attach a copy of my test version using a convenient but less >> efficient representation. >> I added the standard three argument version of map that you suggested above to my test code: map : ((R,R) -> R, %,%) -> % ++ map(f,x,y) returns coerce f(retract x, retract y) or ++ empty() if empty?(x) or empty?(y) ... map(f,x,y) == map(f,x,y)$Rep Bill Page. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
