[FricasUG] FIXME: sec 2.5.2 pag 96 osolete description & Feature suggestion for Union-s

[Riccardo GUIDA]

Hi,

if this is not the correct place for sending FricasUG fix requirements, please excuse me and let me now.

RiCCardo

[FricasUG] FIXME: sec 2.5.2 "Union-s with selectors" pag 96
"Note that case uses the selector name as its right-hand argument. If you accidentally use the branch
type on the right-hand side of case, false will be returned. Now it returns error."


(1) -> U := Union(i:Integer, s:String)

(1) Union(i: Integer,s: String)
Type: Type
(2) -> x:U := "bam"

(2) "bam"
Type: Union(s: String,...)
(3) -> x case Integer

>> Error detected within library code:
upcase: bad Union form

(3) -> x case String

>> Error detected within library code:
upcase: bad Union form

(3) -> x case i

(3) false
Type: Boolean
(4) -> x case s

(4) true

The statements above prove that the fricasUG must be fixed.


=== Feature suggestion for Union-s ===

I must say that I would find more natural (and maybe it would have simpler code)
to have the predicates
x case Integer
x case String
as for non-selector Union-s and to use selectors only to get the values
x.i
x.s
with "failed" instead of a coerce error when the inappropriate selector is called: relying on the fact that a coercion might rescue you if the value branch does not correspond to the selector looks somehow hackish.

(5) -> x.i

>> Error detected within library code:
"bam" of mode Union(i: Integer,s: String) cannot be coerced to mode Integer

(5) -> x.s

(5) "bam"
Type: String

[Riccardo GUIDA]

Sorry, I retract my feature suggestion because Union with selectors are there also in Aldor and with more features that make such selectors more meaningful: i.e. assignment via selector, like u := [num == 3].
RiCCardo

[Waldek Hebisch]

Yes, above using type gives an error. I need to check to determine
if error will be always detected. Consider perverse things like

Union(Integer : Float, Float : Integer)

ATM you can create it but there are problem during use. But there
are natural coding examples which can lead to similar things.
More precisely, there are situations when we want to use the
same identifier as union tag and as variable name. But variables
may contain types. Natural solution is to treat identifier as
tag name, ignoring possible meaning as a type. Of course,
behaviour you see is different.

>
> === Feature suggestion for Union-s ===
>
> I must say that I would find more natural (and maybe it would have simpler code)
> to have the predicates
> x case Integer
> x case String
> as for non-selector Union-s

That would be quite problematic.

--
Waldek Hebisch

[Ralf Hemmecke]

Indeed Riccardo detected a bug. The question is whether I should simply
fix the documentation and (*) remove this line:

"""
If you accidentally use the branch type on the right-hand side of case,
false will be returned.
"""

i.e. we leave it unspecified what happens for cases like

x case Integer

or (**) replace the above line by the sentence:

"""
The use of the type as a selector is no longer allowed.
"""

Or (***) someone (Waldek?) fixes the behaviour so that it is in line
with the FriCAS-UG.

Honestly, I prefer (**).

Opinions?

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> Indeed Riccardo detected a bug. The question is whether I should simply
> fix the documentation and (*) remove this line:
>
> """
> If you accidentally use the branch type on the right-hand side of case,
> false will be returned.
> """
>
> i.e. we leave it unspecified what happens for cases like
>
> x case Integer
>

Yes.

> or (**) replace the above line by the sentence:
>
> """
> The use of the type as a selector is no longer allowed.
> """
>
> Or (***) someone (Waldek?) fixes the behaviour so that it is in line
> with the FriCAS-UG.
>
> Honestly, I prefer (**).
>
> Opinions?

Returning 'false' is invitation for bugs in user programs. ATM
I am not sure if we want to reject type in this situation (probably)
or try to do selection based on types (which also risks bugs in
user programs, but is likely to do what user expects). Usual
documentation trick in such cases is to keep things undocumented.

> Ralf
>
> On 6/28/18 2:54 PM, Riccardo GUIDA wrote:
> > Hi,
> >
> > if this is not the correct place for sending FricasUG fix requirements,
> > please excuse me and let me now.
> >
> > RiCCardo
> >
> > [FricasUG] FIXME: sec 2.5.2 "Union-s with selectors" pag 96
> > "Note that case uses the selector name as its right-hand argument. If
> > you accidentally use the branch
> > type on the right-hand side of case, false will be returned. Now it
> > returns error."
> >
> >
> > (1) -> U := Union(i:Integer, s:String)
> >

> >    (1)  Union(i: Integer,s: String)
> >                                                                    Type:

> > Type
> > (2) -> x:U := "bam"
> >

> >    (2)  "bam"
> >                                                    Type: Union(s:

> > String,...)
> > (3) -> x case Integer

> >  
> >    >> Error detected within library code:
> >    upcase: bad Union form

> >
> > (3) -> x case String

> >  
> >    >> Error detected within library code:
> >    upcase: bad Union form

> >
> > (3) -> x case i
> >

> >    (3)  false
> >                                                                 Type:

> > Boolean
> > (4) -> x case s
> >

> >    (4)  true

> >
> > The statements above prove that the fricasUG must be fixed.
> >
> >
> > === Feature suggestion for Union-s ===
> >
> > I must say that I would find more natural (and maybe it would have
> > simpler code)
> > to have the predicates
> > x case Integer
> > x case String
> > as for non-selector Union-s and to use selectors only to get the values
> > x.i
> > x.s
> > with "failed" instead of a coerce error when the inappropriate selector
> > is called: relying on the fact that a coercion might rescue you if the
> > value branch does not correspond to the selector looks somehow hackish.
> >
> > (5) -> x.i

> >  
> >    >> Error detected within library code:
> >    "bam" of mode Union(i: Integer,s: String) cannot be coerced to mode
> > Integer
> >
> > (5) -> x.s
> >
> >    (5)  "bam"
> >                                                                  Type:
> > String
> >
>
> --
> 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 fricas-devel...@googlegroups.com.
> To post to this group, send email to fricas...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b4f2858a-a41c-94de-1c1d-947d00352dcc%40hemmecke.org.
> For more options, visit https://groups.google.com/d/optout.
>


--
Waldek Hebisch