Re: Re: Re: Re: [fricas-devel] unique Value of Void
Riccardo GUIDA wrote: > > > You seem to use different terminology. Spad is language of .spad files. > > They are intended for non-interactive use -- basicaly enhancements to > > FriCAS library. Spad is different than language of .input files. > > .input files are intended for interactive use. Now, with "interactive > > language" there is some confusion, as functions are normally compiled > > while command line gets special treatment. > > Dear Waldek, > > to explain: my answer relied on the following hypotheses > > * SPAD is the language of .spad files, invoked by )compile Yes > * the interpreter = >interprets a subset of SPAD language (eg no definitions of domain) on > command line and via )read .input files not "a subset" but rather "a variant". Once you get to tiny details it make sense to treat it a a separate language, very similar, but not identical to Spad. > + heuristics guesses & coercitions on types > + SPAD compilation of functions in case of complete type resolutions No Spad. Despite the name interpreter is a full-fledged compiler. It has "interpret" mode for cases where it can not assign types during compilation and for cases when value is requested. > > ... so naively I thought that, if the interpreter is so unpredictable on > types, maybe it was more pedagogical to present things as subsets of SPAD, > which is well defined, but now I realize that maybe the examples given maybe > do not compile in SPAD, even if embedded in functions of user-defined > packages, I do not know, I'm learning using the command line. > > > I guess I need some official glossary, could you please enlighten me? > > * How should be called "The language of .input files?" On the list we usually write about "interpeter". If you want to be more precise use "interpeter language". This is what FriCAS book calls "interactive language". > * Is "The language of .input files" the same thing as "the language of > command line"?, and if not how is called the latter? > I affraid it is question to philosophers if it is the same or not. Command line and .input files are handled by the same code (called "interpreter"). But there is bunch of variables which make things different. Main difference is that you can not make piles on command line. There is important difference between functions (which "interpreter" tries to compile) and code outside functions (which is evaluated to produce a value). There is pragmatic difference: it is incovenient to define larger functions on command line, so they are usually defined in .input files. OTOH commands (code outside functions) are more useful on command line. So pragmaticaly, rules for functions are more important for '.input' files. Special handling for command is more visible on command line. > * Is the compiler invoked by the interpreter when compiling functions the > same compiler (same language) as the SPAD compiler invoked by )compile ? No. The first stage, that is splitting input into tokens is common to interpreter and Spad compiler. After that Spad compilation and interpreter are separate. In particular there are two different parsers. Different parsers means that syntax is slightly different. "interpreter" has two modes of operation. In one it compiles (produces code). In other it produces values. As I wrote there is bunch of variables which decides in which mode "interpreter" operates. > > * Which language is meant by 'The FriCAS language' and 'The FriCAS > interactive language'? Phrase 'The FriCAS interactive language' in FriCAS book refers to language of '.input' files. 'The FriCAS language' is more fuzzy, so it is useful for cases when we do not want to specify variant. Extra explanation: all languages involved are intended to be compatible, ideally identical. Historical developement caused more differences than desired. To say the truth before your original message I was happy to accept statement in FriCAS book about type of one-armed 'if' at face value. I like to write well-typed code so I use one-armed 'if' only in context where 'Void' is right type. I was not aware that Spad compiler allowed getting different type. -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: Re: Re: [fricas-devel] unique Value of Void
You seem to use different terminology. Spad is language of .spad files. They are intended for non-interactive use -- basicaly enhancements to FriCAS library. Spad is different than language of .input files. .input files are intended for interactive use. Now, with "interactive language" there is some confusion, as functions are normally compiled while command line gets special treatment. Dear Waldek, to explain: my answer relied on the following hypotheses * SPAD is the language of .spad files, invoked by )compile * the interpreter = interprets a subset of SPAD language (eg no definitions of domain) on command line and via )read .input files + heuristics guesses & coercitions on types + SPAD compilation of functions in case of complete type resolutions ... so naively I thought that, if the interpreter is so unpredictable on types, maybe it was more pedagogical to present things as subsets of SPAD, which is well defined, but now I realize that maybe the examples given maybe do not compile in SPAD, even if embedded in functions of user-defined packages, I do not know, I'm learning using the command line. I guess I need some official glossary, could you please enlighten me? * How should be called "The language of .input files?" * Is "The language of .input files" the same thing as "the language of command line"?, and if not how is called the latter? * Is the compiler invoked by the interpreter when compiling functions the same compiler (same language) as the SPAD compiler invoked by )compile ? * Which language is meant by 'The FriCAS language' and 'The FriCAS interactive language'? A post on a related question will follow. riccardo -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: Re: [fricas-devel] unique Value of Void
Riccardo GUIDA wrote: > > @ Waldek > > > The command line is not representative of FriCAS language. > > OK, crystal clear. > > The pedagogical problem is that, maybe not to scare the reader, the FricasUG > is somehow vague on the differences among interpreter and compiler. For > instance note that the chapter 5 (which raised my questions) is titled > "Introduction to the FriCAS Interactive Language", while it is presently more > like an (incomplete) SPAD reference. You seem to use different terminology. Spad is language of .spad files. They are intended for non-interactive use -- basicaly enhancements to FriCAS library. Spad is different than language of .input files. .input files are intended for interactive use. Now, with "interactive language" there is some confusion, as functions are normally compiled while command line gets special treatment. -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: Re: [fricas-devel] unique Value of Void
@Bill: If the else clause is missing but the if condition is false then the value of the if-then expression is the unique value of Void. +1 I think an important though somewhat less technical addition to the user guide concerning the meaning and use of the Void and Exit domains would indeed be quite useful. +1 (Maybe adding also something on None if this Type will still be around. Somewhere near section 2.6 might be a good place.) @ Waldek The command line is not representative of FriCAS language. OK, crystal clear. The pedagogical problem is that, maybe not to scare the reader, the FricasUG is somehow vague on the differences among interpreter and compiler. For instance note that the chapter 5 (which raised my questions) is titled "Introduction to the FriCAS Interactive Language", while it is presently more like an (incomplete) SPAD reference. riccardo -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
On Sat, Jun 30, 2018 at 11:30 AM, Waldek Hebisch wrote: > Bill Page wrote: >> > >> > Well, advantage is consistency with rules. >> > >> >> Could you site specifically what rule is being violated? > > The one that Ricardo was asking about: that 'if' always works, > but for one armed 'if' you get Void as a type. > >> ... >> In fact the Spad compiler does not always do what I had hoped. For >> example compiling the following function using Spad: >> >> f(x:Integer):PositiveInteger == if x<1 then 1 >> >> -- >> >> (1) -> f(0) >> >>(1) 1 >> Type: PositiveInteger >> (2) -> f(1) >>Internal Error >>Interpreter code generation failed for expression(|f| 1) > > The message looks fishy. Do you really used _Spad_ function here? Yes, here is the exact code that I compiled: -- file: one-armed.spad )abbrev domain TEST Test Test(): with test1: ()->Integer test2: ()->Void f:Integer -> PositiveInteger g:Integer -> PositiveInteger h:Integer -> PositiveInteger == add z:Integer := 1 test1() == A := if z<2 then 1 return A test2() == B := if 2<1 then 1 return B f(x:Integer):PositiveInteger == if x<1 then 1 g(x:Integer):PositiveInteger == coerce((if x<1 then 1 else void()$Void)::Union(Void,PositiveInteger)) h(x:Integer):PositiveInteger == g(x)+1 -- This is the result: (1) -> )co one-armed Compiling FriCAS source code from file /home/wspage/one-armed.spad using old system compiler. TEST abbreviates domain Test ... Test is now explicitly exposed in frame frame1 Test will be automatically loaded when needed from /home/wspage/TEST.NRLIB/TEST (1) -> f(0) (1) 1 Type: PositiveInteger (2) -> f(1) Internal Error Interpreter code generation failed for expression(|f| 1) (2) -> g(0) (2) 1 Type: PositiveInteger (3) -> g(1) >> Error detected within library code: "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode PositiveInteger (3) -> h(0) (3) 2 Type: PositiveInteger (4) -> h(1) >> Error detected within library code: "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode PositiveInteger (4) -> > The message looks like coming from interpreter and given > Spad function of correct type interpreter should just blindly > call it. > Yes, I thought so too. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
Bill Page wrote: > > On Sat, Jun 30, 2018 at 9:40 AM, Waldek Hebisch > wrote: > >> > >> On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch > >> wrote: > >> > On command line interpreter evaluates things so can use actual > >> > values to guess what would be useful. > >> > > Bill Page wrote: > >> Yes, one should expect that the interpreter would try harder to > >> guess reasonable types in order to relieve the user of (some) > >> of this responsibility. > >> > > In command line expression interpreter can use values. > > Sometime you get message that compilation failed, and > > that function will be interpreted. In such case interpreter > > uses similar rules as on command line. However, for serious > > computation such cases should be avoided because assigning > > types takes quite a lot of time. In compiled functions this is > > done once per type, when interpreting type assignment is > > re-done on every execution of a statement. > > > > Yes. There is a system command: > > )set function compile off/on (on by default) > > which is described as > > compile compile, don't just define function bodies > > but when I set function compile off, I still got the following result: > > (1) -> )set function compile off > (1) -> f2(x : Integer) : Integer == if (x > 1) then 1 >Function declaration f2 : Integer -> Integer has been added to > workspace. >Type: Void > (2) -> f2(2) >Compiling function f2 with type Integer -> Integer >Conversion failed in the compiled user function f2 . > >Cannot convert the value from type Void to Integer . > > -- > > Does this option still work? Perhaps my expectation was wrong. "Compile" have many meanings. The option concerns _Lisp_ compilation. I wrote about higher level, where compilation assentially means type assignment. AFAIK intepreter always tries to compile that is perform types assignment. Only when it fails function is interpteted (and this is lot slower then executiong function compilered by interpteter to Lisp and intepreted by Lisp implementation). > >> ... > >> I cannot see any advantage in having this behavior in the > >> interpreter. > > > > Well, advantage is consistency with rules. > > > > Could you site specifically what rule is being violated? The one that Ricardo was asking about: that 'if' always works, but for one armed 'if' you get Void as a type. > > >> I think the interpreter should be changed to do the same > >> thing as the Spad compiler. The function should attempt to coerce > >> the result of the if-then expression > >> > >> if (x > 1) then 1 > >> > >> to Integer. Of course this might cause an error for certain values > >> of x but the user is not likely to be surprised by this. > > > > Well, there are folks that want static checking, that is no type > > errors at runtime. They prefer Void as a result type. And > > there are folks who want to bend the rules. IMO some sloppines > > on command line is OK. But already for "interpreter" functions > > stricter type rules may be beneficial. > > > > Of course, having more relaxed rule in Spad compiler and stricter > > rule in intepreter is counterintuitive. The only explanation I > > see is that original authors decided to change rules. Remember > > that Spad is "old compiler" and compiler included in intepreter > > is "new compiler". > > > > In fact the Spad compiler does not always do what I had hoped. For > example compiling the following function using Spad: > > f(x:Integer):PositiveInteger == if x<1 then 1 > > -- > > (1) -> f(0) > >(1) 1 > Type: PositiveInteger > (2) -> f(1) >Internal Error >Interpreter code generation failed for expression(|f| 1) The message looks fishy. Do you really used _Spad_ function here? The message looks like coming from interpreter and given Spad function of correct type interpreter should just blindly call it. > -- > > This is a rather unexpected and obscure errror message. -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
On Sat, Jun 30, 2018 at 9:40 AM, Waldek Hebisch wrote: >> >> On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch >> wrote: >> > On command line interpreter evaluates things so can use actual >> > values to guess what would be useful. >> > Bill Page wrote: >> Yes, one should expect that the interpreter would try harder to >> guess reasonable types in order to relieve the user of (some) >> of this responsibility. >> >> > In the process it breaks several normal rules. >> > >> > Try: >> > >> > f(x) == if (x > 1) then 1 >> >Type: >> > Void >> > Time: 0 >> > sec >> > (7) -> f(2) >> >Compiling function f with type PositiveInteger -> Void >> >Type: >> > Void >> >Time: 0.02 (OT) = 0.02 >> > sec >> > (8) -> f(0) >> >Compiling function f with type NonNegativeInteger -> Void >> >Type: >> > Void >> >Time: 0.01 (OT) = 0.01 >> > sec >> > >> > In both cases you now get Void. >> >> Clearly this is a very poor (though technically correct) guess as >> to what the user might have wanted. > > Maybe I should say more: compiling a function interpreter can > _not_ use value, the function has to work for any value of > argument, so in compiled function interpreter has to obey rules. OK. I understand the distinction. > In command line expression interpreter can use values. > Sometime you get message that compilation failed, and > that function will be interpreted. In such case interpreter > uses similar rules as on command line. However, for serious > computation such cases should be avoided because assigning > types takes quite a lot of time. In compiled functions this is > done once per type, when interpreting type assignment is > re-done on every execution of a statement. > Yes. There is a system command: )set function compile off/on (on by default) which is described as compile compile, don't just define function bodies but when I set function compile off, I still got the following result: (1) -> )set function compile off (1) -> f2(x : Integer) : Integer == if (x > 1) then 1 Function declaration f2 : Integer -> Integer has been added to workspace. Type: Void (2) -> f2(2) Compiling function f2 with type Integer -> Integer Conversion failed in the compiled user function f2 . Cannot convert the value from type Void to Integer . -- Does this option still work? Perhaps my expectation was wrong. >> ... >> I cannot see any advantage in having this behavior in the >> interpreter. > > Well, advantage is consistency with rules. > Could you site specifically what rule is being violated? >> I think the interpreter should be changed to do the same >> thing as the Spad compiler. The function should attempt to coerce >> the result of the if-then expression >> >> if (x > 1) then 1 >> >> to Integer. Of course this might cause an error for certain values >> of x but the user is not likely to be surprised by this. > > Well, there are folks that want static checking, that is no type > errors at runtime. They prefer Void as a result type. And > there are folks who want to bend the rules. IMO some sloppines > on command line is OK. But already for "interpreter" functions > stricter type rules may be beneficial. > > Of course, having more relaxed rule in Spad compiler and stricter > rule in intepreter is counterintuitive. The only explanation I > see is that original authors decided to change rules. Remember > that Spad is "old compiler" and compiler included in intepreter > is "new compiler". > In fact the Spad compiler does not always do what I had hoped. For example compiling the following function using Spad: f(x:Integer):PositiveInteger == if x<1 then 1 -- (1) -> f(0) (1) 1 Type: PositiveInteger (2) -> f(1) Internal Error Interpreter code generation failed for expression(|f| 1) -- This is a rather unexpected and obscure errror message. However it is possible to compile explicit code such as: g(x:Integer):PositiveInteger == coerce((if x<1 then 1 else void()$Void)::Union(Void,PositiveInteger)) -- 2) -> g(0) (2) 1 Type: PositiveInteger (3) -> g(1) >> Error detected within library code: "()" of mode Union(Void,PositiveInteger) cannot be coerced to mode PositiveInteger -- which does do what I had hoped, i.e. that the code generated for f would be essentially the same as g. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To
Re: Re: [fricas-devel] unique Value of Void
Bill Page wrote: > > On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch > wrote: > > Riccardo GUIDA wrote: > >> ... > >> 3) The user is puzzled because > > > > The command line is not representative of FriCAS language. > > In my opinion it should be (almost) representative of FriCAS language (SPAD). > > > On command line interpreter evaluates things so can use actual values > > to guess what would be useful. > > Yes, one should expect that the interpreter would try harder to guess > reasonable types in order to relieve the user of (some) of this > responsibility. > > > In the process it breaks several normal rules. > > > > Try: > > > > f(x) == if (x > 1) then 1 > >Type: > > Void > > Time: 0 > > sec > > (7) -> f(2) > >Compiling function f with type PositiveInteger -> Void > >Type: > > Void > >Time: 0.02 (OT) = 0.02 > > sec > > (8) -> f(0) > >Compiling function f with type NonNegativeInteger -> Void > >Type: > > Void > >Time: 0.01 (OT) = 0.01 > > sec > > > > In both cases you now get Void. > > Clearly this is a very poor (though technically correct) guess as to > what the user might have wanted. Maybe I should say more: compiling a function interpreter can _not_ use value, the function has to work for any value of argument, so in compiled function interpreter has to obey rules. In command line expression interpreter can use values. Sometime you get message that compilation failed, and that function will be interpreted. In such case interpreter uses similar rules as on command line. However, for serious computation such cases should be avoided because assigning types takes quite a lot of time. In compiled functions this is done once per type, when interpreting type assignment is re-done on every execution of a statement. > > Unlike Spad compiler trying to declare type does not change the result: > > > > (9) -> f2(x : Integer) : Integer == if (x > 1) then 1 > >Function declaration f2 : Integer -> Integer has been added to > > workspace. > >Type: > > Void > > Time: 0 > > sec > > (10) -> f2(2) > >Compiling function f2 with type Integer -> Integer > >Conversion failed in the compiled user function f2 . > > > >Cannot convert the value from type Void to Integer . > > > > (10) -> f2(0) > >Conversion failed in the compiled user function f2 . > > > >Cannot convert the value from type Void to Integer . > > > > I cannot see any advantage in having this behavior in the > interpreter. Well, advantage is consistency with rules. > I think the interpreter should be changed to do the same > thing as the Spad compiler. The function should attempt to coerce the > result of the if-then expression > > if (x > 1) then 1 > > to Integer. Of course this might cause an error for certain values of > x but the user is not likely to be surprised by this. Well, there are folks that want static checking, that is no type errors at runtime. They prefer Void as a result type. And there are folks who want to bend the rules. IMO some sloppines on command line is OK. But already for "interpreter" functions stricter type rules may be beneficial. Of course, having more relaxed rule in Spad compiler and stricter rule in intepreter is counterintuitive. The only explanation I see is that original authors decided to change rules. Remember that Spad is "old compiler" and compiler included in intepreter is "new compiler". -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
On Fri, Jun 29, 2018 at 11:22 AM, Waldek Hebisch wrote: > Riccardo GUIDA wrote: >> ... >> 3) The user is puzzled because > > The command line is not representative of FriCAS language. In my opinion it should be (almost) representative of FriCAS language (SPAD). > On command line interpreter evaluates things so can use actual values > to guess what would be useful. Yes, one should expect that the interpreter would try harder to guess reasonable types in order to relieve the user of (some) of this responsibility. > In the process it breaks several normal rules. > > Try: > > f(x) == if (x > 1) then 1 >Type: Void > Time: 0 sec > (7) -> f(2) >Compiling function f with type PositiveInteger -> Void >Type: Void >Time: 0.02 (OT) = 0.02 sec > (8) -> f(0) >Compiling function f with type NonNegativeInteger -> Void >Type: Void >Time: 0.01 (OT) = 0.01 sec > > In both cases you now get Void. Clearly this is a very poor (though technically correct) guess as to what the user might have wanted. > Unlike Spad compiler trying to declare type does not change the result: > > (9) -> f2(x : Integer) : Integer == if (x > 1) then 1 >Function declaration f2 : Integer -> Integer has been added to > workspace. >Type: Void > Time: 0 sec > (10) -> f2(2) >Compiling function f2 with type Integer -> Integer >Conversion failed in the compiled user function f2 . > >Cannot convert the value from type Void to Integer . > > (10) -> f2(0) >Conversion failed in the compiled user function f2 . > >Cannot convert the value from type Void to Integer . > I cannot see any advantage in having this behavior in the interpreter.I think the interpreter should be changed to do the same thing as the Spad compiler. The function should attempt to coerce the result of the if-then expression if (x > 1) then 1 to Integer. Of course this might cause an error for certain values of x but the user is not likely to be surprised by this. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
Riccardo GUIDA wrote: > > Just to say that my original question to Ralf was a much more low level quest > for clarifications in the user guide: > > 1) A user reads: > > section 5.3 pag 149 > "An if-then-else expression always returns a value. If the else clause is > missing then the entire expression returns the unique value of Void. If both > clauses are present, the type of the value returned by if is obtained by > resolving the types of the values of the two clauses. See Section 2.10 on > page 109 for more information." (Check also the boxed text above this > statement.) > > 2) The user does not really understand the statement and, if he is motivated, > tries to experiment: > > (1) -> if 1>2 then 1 -- here he expects Void > Type: Void > (2) -> if 2>1 then 1 -- here he expects Void but gets PositiveInteger > > (2) 1 > Type: PositiveInteger > (3) -> if 2>1 then 1 else [1,2,3] -- here he expects common supertype, but > which one? > > (3) 1 > Type: PositiveInteger > (4) -> if 1>2 then 1 else [1,2,3] -- here he expects common supertype, which > one? > > (4) [1, 2, 3] >Type: List(PositiveInteger) > > 3) The user is puzzled because The command line is not representative of FriCAS language. On command line interpreter evaluates things so can use actual values to guess what would be useful. In the process it breaks several normal rules. Try: f(x) == if (x > 1) then 1 Type: Void Time: 0 sec (7) -> f(2) Compiling function f with type PositiveInteger -> Void Type: Void Time: 0.02 (OT) = 0.02 sec (8) -> f(0) Compiling function f with type NonNegativeInteger -> Void Type: Void Time: 0.01 (OT) = 0.01 sec In both cases you now get Void. Unlike Spad compiler trying to declare type does not change the result: (9) -> f2(x : Integer) : Integer == if (x > 1) then 1 Function declaration f2 : Integer -> Integer has been added to workspace. Type: Void Time: 0 sec (10) -> f2(2) Compiling function f2 with type Integer -> Integer Conversion failed in the compiled user function f2 . Cannot convert the value from type Void to Integer . (10) -> f2(0) Conversion failed in the compiled user function f2 . Cannot convert the value from type Void to Integer . -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
On Fri, Jun 29, 2018 at 10:10 AM, Riccardo GUIDA wrote: > > Thanks for your clarifications Bill. > Thank you for asking the question. > > Just to say that my original question to Ralf was a much more low > level quest for clarifications in the user guide: > OK. I think I understand your motivation and Ralf's concerns about clarity. Let me try to annotate the quoted section with my interpretation: > 1) A user reads: > > section 5.3 pag 149 > "An if-then-else expression always returns a value. I think this is clear. > If the else clause is missing then the entire expression > returns the unique value of Void. I agree that this sentence is either confusing or wrong. I would suggest the following: If the else clause is missing but the if condition is false then the value of the if-then expression is the unique value of Void. > If both clauses are present, the type of the value returned by if is obtained > by resolving the types of the values of the two clauses. See Section 2.10 > on page 109 for more information." (Check also the boxed text above this > statement.) > I suppose that the key issue is what might be meant by "resolving the types". My interpretation is that that although both an if-then-else expression and an if-then expression "always return a value", the actual type is indeterminate and depends on knowing the types of both clauses, i.e. the type of the then-part and the type of the (possibly missing) else-part. But in the appropriate context the compiler (and in principle the interpreter) are able to determine an appropriate for the result. > 2) The user does not really understand the statement and, if he is > motivated, tries to experiment: > > (1) -> if 1>2 then 1 -- here he expects Void >Type: > Void OK. > (2) -> if 2>1 then 1 -- here he expects Void but gets PositiveInteger > >(2) 1 > Type: PositiveInteger I can see that a naive interpretation of the statement in the guide might lead to this expectation. But given a clear understanding of the Void domain, it should be obvious that such a result could not be useful. > (3) -> if 2>1 then 1 else [1,2,3] -- here he expects common supertype, but > which one? > >(3) 1 > Type: PositiveInteger So, to this user "resolving the type" seems to imply the existence of a supertype. In fact such a supertype does exist in FriCAS (Union) and given that the statement in the guide is not so clear this is certainly a reasonable expectation but I do not think that it is actually implied. > (4) -> if 1>2 then 1 else [1,2,3] -- here he expects common supertype, > which one? > >(4) [1, 2, 3] > Type: > List(PositiveInteger) > If we provide a bit more type information then the users expectations can be met. (1) -> A:Union(PositiveInteger, List PositiveInteger) := if 2>1 then 1 else [1,2,3] (1) 1 Type: Union(PositiveInteger,...) (2) -> A:Union(PositiveInteger, List PositiveInteger) := if 1>2 then 1 else [1,2,3] (2) [1, 2, 3] Type: Union(List(PositiveInteger),...) > 3) The user is puzzled because > > * in (2) below he gets Type: Positive Integer not Type: Void > * in (3) and (4) below he sees 2 different types and not a "common > supertype" > Yes I see how this is possible. > > From your explanations now I understand that there are a lot of > hidden coercion in the game and that what is said in the user > guide does not contradict the experiments. But I feel it would be > helpful to have some clarifying information in the user guide not > after page 149. Writing "the unique value of Void" is not of help > because what is not evident is the fact that "every value can be > coerced to Void". I realize now that this is said at pag 763, > sec 9.87 (in my version of FricasUG), but at least a footnote in > page 149 would have helped. > I think an important though somewhat less technical addition to the user guide concerning the meaning and use of the Void and Exit domains would indeed be quite useful. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
Re: Re: [fricas-devel] unique Value of Void
Hi, Thanks for your clarifications Bill. Just to say that my original question to Ralf was a much more low level quest for clarifications in the user guide: 1) A user reads: section 5.3 pag 149 "An if-then-else expression always returns a value. If the else clause is missing then the entire expression returns the unique value of Void. If both clauses are present, the type of the value returned by if is obtained by resolving the types of the values of the two clauses. See Section 2.10 on page 109 for more information." (Check also the boxed text above this statement.) 2) The user does not really understand the statement and, if he is motivated, tries to experiment: (1) -> if 1>2 then 1 -- here he expects Void Type: Void (2) -> if 2>1 then 1 -- here he expects Void but gets PositiveInteger (2) 1 Type: PositiveInteger (3) -> if 2>1 then 1 else [1,2,3] -- here he expects common supertype, but which one? (3) 1 Type: PositiveInteger (4) -> if 1>2 then 1 else [1,2,3] -- here he expects common supertype, which one? (4) [1, 2, 3] Type: List(PositiveInteger) 3) The user is puzzled because * in (2) below he gets Type: Positive Integer not Type: Void * in (3) and (4) below he sees 2 different types and not a "common supertype" From your explanations now I understand that there are a lot of hidden coercitions in the game and that what is said in the user guide does not contradict the experiments. But I feel it would be helpful to have some clarifying information in the user guide not after page 149. Writing "the unique value of Void" is not of help because what is not evident is the fact that "every value can be coerced to Void". I realize now that this is said at pag 763, sec 9.87 (in my version of FricasUG), but at least a footnote in page 149 would have helped. ric -- 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+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
