Re: [fricas-devel] two argument error function
On 4/3/24 19:48, Waldek Hebisch wrote: Yes. However, here there is question of tracking values. If you give types you should do x : T := v and not x : T ... x := v OK. I think you mentioned some time ago that in SPAD writing x:T basically means "assigning a variable x with and uninitialized value". (Strange concept, but AFAIU, there are no declarations in SPAD.) I would anyway always write x:T:=v. Thank you for the explanation. Ralf -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/a6f30136-d3e1-4ee6-ac88-1a640b80228d%40hemmecke.org.
Re: [fricas-devel] two argument error function
On Wed, Apr 03, 2024 at 07:09:41PM +0200, Ralf Hemmecke wrote: > On 4/3/24 18:41, Waldek Hebisch wrote: > > Well, AFAICS this is one of limitations of current compiler: 'error' > > gets special treatment, but only when it is translated to Boot > > function called 'error'. If you rename 'error3' to 'error', then > > the file will compile. But I expect that such rename will cause > > trouble, so I do not think it is a practical solution. > > That actually brings me to the question whether overloading in BOOT is also > supposed to work, i.e., whether I can have > > error(x) == errorSupervisor($AlgebraError,x) > > error(con, fun, mess) == > errorSupervisor($AlgebraError, [STRCONC(fun, '" $ ", con, '": "), mess]) > > at the same time. I guess no. There is no overloading in Boot. > However, your statement about the declarations bothered me a bit. > First of all, I do not think that declaring the types of variables is a bad > idea, since it is an easy hint for the programmer to understand the code. So > that point of your "suboptimal" does not count for me. > However, you say something about "weakens compiler checking", and that I > don't understand at all. Up to know I would have guessed that when I declare > the type of a variable, the compiler also checks that in places where this > variable is used (or assigned), the actual types match with what I have > declared. Is this not the case? Yes. However, here there is question of tracking values. If you give types you should do x : T := v and not x : T ... x := v The point is that type should be assigned to variable together with value. That way uninitialized variable leads to type error. Declaring type in advance (before assignment) effectively disables detection of uninitialized variables. Sometimes Spad can not see that variable is initialized with correct type, then we have to give declaration in advance. But if possible such advance declarations should be avoided. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/Zg2WegcWSlyYw1bk%40fricas.org.
Re: [fricas-devel] two argument error function
On 4/3/24 18:41, Waldek Hebisch wrote: Well, AFAICS this is one of limitations of current compiler: 'error' gets special treatment, but only when it is translated to Boot function called 'error'. If you rename 'error3' to 'error', then the file will compile. But I expect that such rename will cause trouble, so I do not think it is a practical solution. That actually brings me to the question whether overloading in BOOT is also supposed to work, i.e., whether I can have error(x) == errorSupervisor($AlgebraError,x) error(con, fun, mess) == errorSupervisor($AlgebraError, [STRCONC(fun, '" $ ", con, '": "), mess]) at the same time. I guess no. BTW: my guess is that trouble is due to following pattern: piv2 = 0 => error "impossible 3" ... lf1 := rquo(rp, rw) lf1 := lf1 + nc2*lop Thanks to special treatment of 'error' compiler knows that lf1 is well defined at the end of this sequence. But without special treatment compiler thinks that 'lf1' may be undefined when the sequence is finished. One could work around this by giving lf1 and rf1 explicit type declarations at start of 'lift1', like: lf1 : YDP rf1 : YDP but this is somewhat suboptimal, as it needs more code and weakens compiler checking. OK, that would have been something that I would have tried to do, but I could not see how this would be related to the error3 function. Even now I do not quite see it. Looks like type checking is done after compForm1 was executed so that the typechecker sees error3 and does not know that this, in fact, includes a RETURN-FROM-FUNCTION. OK, that are compiler internals that I am not so much interested in. However, your statement about the declarations bothered me a bit. First of all, I do not think that declaring the types of variables is a bad idea, since it is an easy hint for the programmer to understand the code. So that point of your "suboptimal" does not count for me. However, you say something about "weakens compiler checking", and that I don't understand at all. Up to know I would have guessed that when I declare the type of a variable, the compiler also checks that in places where this variable is used (or assigned), the actual types match with what I have declared. Is this not the case? Ralf -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/cc9badd4-f34c-442f-b130-105b418cc548%40hemmecke.org.
Re: [fricas-devel] two argument error function
On Wed, Apr 03, 2024 at 05:19:03PM +0200, Ralf Hemmecke wrote: > Hi Waldek, > > I've now tried to compile all of FriCAS with your patch (adding the error3 > function to g-error.boot). > > https://github.com/fricas/fricas/compare/master...hemmecke:fricas:wip/error3.patch > > Branch "wip/error3" at my github repo: > > https://github.com/hemmecke/fricas/tree/wip/error3 > > It aborts the compilation with the log below. Obiously while compiling (in > parallel) the file xpfact.spad. > > "master" compiled fine on that machine so the problem must come from your > patch, but I do not see why this would be related. Attached diff adds special handling for 'error3'. I principle we should have special type (or something internal to the compiler) to mark code which does not return. But in the patch I just add extra line making 'error3' magic (like 'error'). -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/Zg2LMG87obdnHpyB%40fricas.org. --- ../trunk.pp6/src/interp/compiler.boot 2024-03-28 21:46:24.406140407 + +++ compiler.boot 2024-04-03 16:52:48.237462018 + @@ -484,10 +484,16 @@ compForm1(form is [op,:argl],m,e) == op="error" => + constr := + NULL($functorForm) => nil + first($functorForm) + fun := + $op = constr => nil + $op #argl = 1 => arg := first(argl) u := comp(arg, $String, e) => - [[op, u.expr], m, e] + [["error3", MKQ(constr), MKQ(fun), u.expr], m, e] SAY ['"compiling call to error ", argl] u := outputComp(arg, e) => [[op, ['LIST, ['QUOTE, 'mathprint], u.expr]], m, e] @@ -961,6 +967,7 @@ level=exitCount and not ValueFlag => nil op="SEQ" => or/[canReturn(u,level+1,exitCount,false) for u in rest expr] op = "error" => nil + op = "error3" => nil op="TAGGEDreturn" => nil op="CATCH" => [.,gs,data]:= expr
Re: [fricas-devel] two argument error function
On Wed, Apr 03, 2024 at 05:19:03PM +0200, Ralf Hemmecke wrote: > Hi Waldek, > > I've now tried to compile all of FriCAS with your patch (adding the error3 > function to g-error.boot). > > https://github.com/fricas/fricas/compare/master...hemmecke:fricas:wip/error3.patch > > Branch "wip/error3" at my github repo: > > https://github.com/hemmecke/fricas/tree/wip/error3 > > It aborts the compilation with the log below. Obiously while compiling (in > parallel) the file xpfact.spad. > > "master" compiled fine on that machine so the problem must come from your > patch, but I do not see why this would be related. > > Any hints? Well, AFAICS this is one of limitations of current compiler: 'error' gets special treatment, but only when it is translated to Boot function called 'error'. If you rename 'error3' to 'error', then the file will compile. But I expect that such rename will cause trouble, so I do not think it is a practical solution. BTW: my guess is that trouble is due to following pattern: piv2 = 0 => error "impossible 3" ... lf1 := rquo(rp, rw) lf1 := lf1 + nc2*lop Thanks to special treatment of 'error' compiler knows that lf1 is well defined at the end of this sequence. But without special treatment compiler thinks that 'lf1' may be undefined when the sequence is finished. One could work around this by giving lf1 and rf1 explicit type declarations at start of 'lift1', like: lf1 : YDP rf1 : YDP but this is somewhat suboptimal, as it needs more code and weakens compiler checking. > Ralf > > > >compiling local lift1 : (FreeMonoid > vl,XDistributedPolynomial(vl,Polynomial F),Integer,FreeMonoid > vl,XDistributedPolynomial(vl,Polynomial > F),Integer,F,XDistributedPolynomial(vl,Polynomial F),Boolean) -> > Record(l_fac: XDistributedPolynomial(vl,Polynomial F),r_fac: > XDistributedPolynomial(vl,Polynomial F),residual: > XDistributedPolynomial(vl,Polynomial F),nsym: Union(Symbol,none)) >Semantic Errors: > [1] algebraic_solution: sol1 is BOTH a variable and a literal > >Warnings: > [1] top_split: k has no value > [2] lexquo: quotient has no value > [3] lexquo: remainder has no value > [4] left_ext_GCD: quotient has no value > [5] left_ext_GCD: remainder has no value > [6] XDP_to_YDP: k has no value > [7] XDP_to_YDP: c has no value > [8] eval_YDP: c has no value > [9] eval_YDP: k has no value > [10] eval_YDP: lt2 has no value > [11] rational_solution: sol has no value > [12] overlap_steps: res has no value > [13] lift1: rdc has no value > [14] lift1: ldc has no value > [15] lift1: lf1 has no value > > ** comp fails at level 4 with expression: ** > error in function lift1 > > (SEQ (|:=| (|:| |nsu| (|Union| (|Symbol|) "none")) "none") > (|:=| |lcw| (|restn| |lw| (- |d1| |j|))) (|:=| |rop| (|lquo| |rfy| > |lcw|)) > (IF (= |rop| 0) > (SEQ (|:=| |rf1p| (|lquo| |rp| |lw|)) > (|:=| |rf1| (* (|::| (/ 1 |lc|) (|Polynomial| F)) |rf1p|)) > (|:=| |rp| (- |rp| (* |lfy| |rf1|))) > (|:=| |lf1| (|rquo| |rp| |rw|)) > (|exit| 1 (|:=| |rp| (- |rp| (* |lf1| |rfy|) > (SEQ (|:=| |rcw| (|firstn| |rw| |j|)) > (|:=| |lop| (|rquo| |lfy| |rcw|)) > (|:=| |row| (* |lw| (|maxdeg| |rop|))) > (|exit| 1 >(IF (= |lop| 0) >(SEQ (|:=| |lf1| (|rquo| |rp| |rw|)) > (|:=| |rp| (- |rp| (* |lf1| |rfy|))) > (|:=| |rf1p| (|lquo| |rp| |lw|)) > (|:=| |rf1| > (* (|::| (/ 1 |lc|) (|Polynomial| F)) |rf1p|)) > (|exit| 1 (|:=| |rp| (- |rp| (* |lfy| |rf1|) >(SEQ (|:=| |low| (* (|maxdeg| |lop|) |rw|)) > (|exit| 1 > (IF (< |row| |low|) > (SEQ (|:=| |lf1| (|rquo| |rp| |rw|)) > (|:=| |rp| (- |rp| (* |lf1| |rfy|))) > (|:=| |rf1p| (|lquo| |rp| |lw|)) > (|:=| |rf1| >(* (|::| (/ 1 |lc|) (|Polynomial| F)) > |rf1p|)) > (|exit| 1 >(|:=| |rp| (- |rp| (* |lfy| |rf1|) > (IF (< |low| |row|) > (SEQ (|:=| |rf1p| (|lquo| |rp| |lw|)) > (|:=| |rf1| >(* (|::| (/ 1 |lc|) (|Polynomial| F)) > |rf1p|)) > (|:=| |rp| (- |rp| (* |lfy| |rf1|))) >
Re: [fricas-devel] two argument error function
Hi Waldek, I've now tried to compile all of FriCAS with your patch (adding the error3 function to g-error.boot). https://github.com/fricas/fricas/compare/master...hemmecke:fricas:wip/error3.patch Branch "wip/error3" at my github repo: https://github.com/hemmecke/fricas/tree/wip/error3 It aborts the compilation with the log below. Obiously while compiling (in parallel) the file xpfact.spad. "master" compiled fine on that machine so the problem must come from your patch, but I do not see why this would be related. Any hints? Ralf compiling local lift1 : (FreeMonoid vl,XDistributedPolynomial(vl,Polynomial F),Integer,FreeMonoid vl,XDistributedPolynomial(vl,Polynomial F),Integer,F,XDistributedPolynomial(vl,Polynomial F),Boolean) -> Record(l_fac: XDistributedPolynomial(vl,Polynomial F),r_fac: XDistributedPolynomial(vl,Polynomial F),residual: XDistributedPolynomial(vl,Polynomial F),nsym: Union(Symbol,none)) Semantic Errors: [1] algebraic_solution: sol1 is BOTH a variable and a literal Warnings: [1] top_split: k has no value [2] lexquo: quotient has no value [3] lexquo: remainder has no value [4] left_ext_GCD: quotient has no value [5] left_ext_GCD: remainder has no value [6] XDP_to_YDP: k has no value [7] XDP_to_YDP: c has no value [8] eval_YDP: c has no value [9] eval_YDP: k has no value [10] eval_YDP: lt2 has no value [11] rational_solution: sol has no value [12] overlap_steps: res has no value [13] lift1: rdc has no value [14] lift1: ldc has no value [15] lift1: lf1 has no value ** comp fails at level 4 with expression: ** error in function lift1 (SEQ (|:=| (|:| |nsu| (|Union| (|Symbol|) "none")) "none") (|:=| |lcw| (|restn| |lw| (- |d1| |j|))) (|:=| |rop| (|lquo| |rfy| |lcw|)) (IF (= |rop| 0) (SEQ (|:=| |rf1p| (|lquo| |rp| |lw|)) (|:=| |rf1| (* (|::| (/ 1 |lc|) (|Polynomial| F)) |rf1p|)) (|:=| |rp| (- |rp| (* |lfy| |rf1|))) (|:=| |lf1| (|rquo| |rp| |rw|)) (|exit| 1 (|:=| |rp| (- |rp| (* |lf1| |rfy|) (SEQ (|:=| |rcw| (|firstn| |rw| |j|)) (|:=| |lop| (|rquo| |lfy| |rcw|)) (|:=| |row| (* |lw| (|maxdeg| |rop|))) (|exit| 1 (IF (= |lop| 0) (SEQ (|:=| |lf1| (|rquo| |rp| |rw|)) (|:=| |rp| (- |rp| (* |lf1| |rfy|))) (|:=| |rf1p| (|lquo| |rp| |lw|)) (|:=| |rf1| (* (|::| (/ 1 |lc|) (|Polynomial| F)) |rf1p|)) (|exit| 1 (|:=| |rp| (- |rp| (* |lfy| |rf1|) (SEQ (|:=| |low| (* (|maxdeg| |lop|) |rw|)) (|exit| 1 (IF (< |row| |low|) (SEQ (|:=| |lf1| (|rquo| |rp| |rw|)) (|:=| |rp| (- |rp| (* |lf1| |rfy|))) (|:=| |rf1p| (|lquo| |rp| |lw|)) (|:=| |rf1| (* (|::| (/ 1 |lc|) (|Polynomial| F)) |rf1p|)) (|exit| 1 (|:=| |rp| (- |rp| (* |lfy| |rf1|) (IF (< |low| |row|) (SEQ (|:=| |rf1p| (|lquo| |rp| |lw|)) (|:=| |rf1| (* (|::| (/ 1 |lc|) (|Polynomial| F)) |rf1p|)) (|:=| |rp| (- |rp| (* |lfy| |rf1|))) (|:=| |lf1| (|rquo| |rp| |rw|)) (|exit| 1 (|:=| |rp| (- |rp| (* |lf1| |rfy|) (IF |o_case| (SEQ (|:=| |ns| ((|Sel| (|Symbol|) |new|))) (|:=| |nsu| |ns|) (|:=| |nc| ((|Sel| (|Polynomial| F) |monomial|) 1 |ns| 1)) (|:=| |oc| (|coefficient| |rp| |low|)) (|:=| |rf1p| (|lquo| |rp| |lw|)) (|:=| |rf1| (* (|::| (/ 1 |lc|) (|Polynomial| F)) |rf1p|)) (|:=| |lf1| (|rquo| |rp| |rw|)) (|:=| |rf1| (+ |rf1| (* |nc| |rop|))) (|:=| |lf1| (- |lf1|
Re: [fricas-devel] two argument error function
On 4/1/24 00:27, Waldek Hebisch wrote: I also saw that it might be possible that fun and/or con could be NIL. I do not yet see where that could happen, but maybe for those cases the code of error3 should be different. Well, the patch is just proof of concept. There are corner cases which should be handled in reasonable way. Note that initialization of constructors is outside functions, so there in no function name. And initialization may signal errors. I am not sure if constructor can be NIL, that should be investigated before commiting better version. Also, for nested functions '$op' contains name of surrounding function. In case of anonymous functions we have no name. That should be handled in some way. Honestly, I think that cases where con or fun are NIL should not count as trouble. Even if the patch shows correct fun$con in 80% of the cases and has some cases where it shows NIL$con or fun$NIL, I would still see it as progress. Note that currently there are two legal variants of error, the second one allowing math formatting. The patch only handles first form, the second one needs a bit more work. What exactly do you mean by "math formatting"? The the "error" function that we speak about allows only one argument which is of type String. Your comment says that I do not use "error" to its full power. Seemingly, I have not yet come across such "math formatting" option. Can you give a pointer. Ralf -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/c624b4ff-b86b-4da3-9c4a-7f7f0d1f4679%40hemmecke.org.
Re: [fricas-devel] two argument error function
On Sun, Mar 31, 2024 at 10:46:34PM +0200, Ralf Hemmecke wrote: > Hello Waldek, > > > Attached is a little patch which changes error function to > > 'error3' and adds two extra paramters, that is constructor name > > and function name. > > > > You need to add definition of 'error3', for example: > > > > error3(con, fun, mess) == > > errorSupervisor($AlgebraError, [STRCONC(con, '"$", fun, '": "), mess]) > > > > Note: to test patch 'compiler.boot' and read it. Then read > > boot file with definition of 'error3'. > > Thank you for that patch. That is really progress. And helps me a lot. > Looks good to me, at least. > > I only think that it would be better to use > > > error3(con, fun, mess) == > errorSupervisor($AlgebraError, [STRCONC(fun, '" $ ", con, '": "), mess]) > > > that is, spaces around $, and fun and con excanged. Yes, fun should go first. I do not understand why you want spaces around '$'. Usual way it to write this without extra spaces, also in hand written error messages. > > I also saw that it might be possible that fun and/or con could be NIL. I do > not yet see where that could happen, but maybe for those cases the code of > error3 should be different. Well, the patch is just proof of concept. There are corner cases which should be handled in reasonable way. Note that initialization of constructors is outside functions, so there in no function name. And initialization may signal errors. I am not sure if constructor can be NIL, that should be investigated before commiting better version. Also, for nested functions '$op' contains name of surrounding function. In case of anonymous functions we have no name. That should be handled in some way. Note that currently there are two legal variants of error, the second one allowing math formatting. The patch only handles first form, the second one needs a bit more work. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZgnjVv28Czu-I_2W%40fricas.org.
Re: [fricas-devel] two argument error function
Hello Waldek, Attached is a little patch which changes error function to 'error3' and adds two extra paramters, that is constructor name and function name. You need to add definition of 'error3', for example: error3(con, fun, mess) == errorSupervisor($AlgebraError, [STRCONC(con, '"$", fun, '": "), mess]) Note: to test patch 'compiler.boot' and read it. Then read boot file with definition of 'error3'. Thank you for that patch. That is really progress. And helps me a lot. Looks good to me, at least. I only think that it would be better to use error3(con, fun, mess) == errorSupervisor($AlgebraError, [STRCONC(fun, '" $ ", con, '": "), mess]) that is, spaces around $, and fun and con excanged. I also saw that it might be possible that fun and/or con could be NIL. I do not yet see where that could happen, but maybe for those cases the code of error3 should be different. But, honestly, if STRCONC allows NIL as argument, then the $ makes clear enough what is function name and what constructor. I'd be happy if this could make it into the next release. Ralf -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/f553927f-e9c8-4dc3-953b-d4c70b311028%40hemmecke.org.
Re: [fricas-devel] two argument error function
On Sat, Mar 30, 2024 at 10:31:46PM +0100, Ralf Hemmecke wrote:
> On 3/30/24 00:43, Waldek Hebisch wrote:
> > Compiler knows function name and constructor name. Note however
> > that FriCAS types are parametrized, and type parameter are known
> > only at runtime.
>
> Waldek, that sounds as if printing function and constructor name would be
> quite easy to achieve.
>
> Yes, the parameters of the constructor would be nice, but for me it would
> already be pretty helpful to know function and constructor name.
In a sense yes. There are limitations:
1) 'error' needs special treatment in the compiler because
'error' means abnormal exit from a function, so no need
for return value. Without that knowledge you would have
to write silly code like
my_error("error")
return some_dummy
to satisfy type checker. Theoretically 'Exit' as return type
could be used for this purpose, but I am affraid that it only
works in the interpeter.
2) Currently 'error' calls 'error' in 'g-error.boot'. So there
is one argument and to call _must_ go to 'errorSupervisor'
before it prints anything. Namely, 'errorSupervisor' may
trap errors, in which case nothing should be printed.
3) 'error' messages are most important in unexpected situations.
Which means that we want to keep error handlers as simple as
possible. Otherwise there is real risk that when "interesting"
error hapen we will get crash in error handler instead of
error message.
Currently actual code for 'error' is generated in 'compForm1'
in 'compiler.boot'. Handling is dead simple:
op="error" =>
#argl = 1 =>
arg := first(argl)
u := comp(arg, $String, e) =>
[[op, u.expr], m, e]
SAY ['"compiling call to error ", argl]
u := outputComp(arg, e) =>
[[op, ['LIST, ['QUOTE, 'mathprint], u.expr]], m, e]
nil
SAY ['"compiling call to error ", argl]
nil
So, if function name is 'error' and there is one argument it
tries to compile this aregument, and if succesful generates call
to 'error' at Boot level passing to computed value of the argument.
Otherwise, in case of one argument it tries to compile agument as
an output form, if that warks it callse Boot hadler giving it
wrapped OutputForm.
Of none of the above works call is treated as error is source
code. There is backtracking in Spad compiler, so theoretically
soemthing else could compile the call, but AFAICS all things
go trough 'compForm1', so probably different treatment is
not possible.
Now, what could we change easily? We could add two or three
argument error at Boot level and call it with extra data.
For example, passing '%' to handler would give it complete
information about current constructor ('%' contains domain
vector which contains all runtime information about type,
including constructor name and parameters). We could pass
'$op' which IIRC contains current function name.
Attached is a little patch which changes error function to
'error3' and adds two extra paramters, that is constructor name
and function name.
You need to add definition of 'error3', for example:
error3(con, fun, mess) ==
errorSupervisor($AlgebraError, [STRCONC(con, '"$", fun, '": "), mess])
Note: to test patch 'compiler.boot' and read it. Then read
boot file with definition of 'error3'.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZgjAhyBta7PXq8Q3%40fricas.org.
--- ../trunk.pp6/src/interp/compiler.boot 2024-03-28 21:46:24.406140407 +
+++ compiler.boot 2024-03-31 01:41:48.306221983 +
@@ -484,10 +484,16 @@
compForm1(form is [op,:argl],m,e) ==
op="error" =>
+ constr :=
+ NULL($functorForm) => nil
+ first($functorForm)
+ fun :=
+ $op = constr => nil
+ $op
#argl = 1 =>
arg := first(argl)
u := comp(arg, $String, e) =>
- [[op, u.expr], m, e]
+ [["error3", MKQ(constr), MKQ(fun), u.expr], m, e]
SAY ['"compiling call to error ", argl]
u := outputComp(arg, e) =>
[[op, ['LIST, ['QUOTE, 'mathprint], u.expr]], m, e]
Re: [fricas-devel] two argument error function
On 3/30/24 00:43, Waldek Hebisch wrote: Compiler knows function name and constructor name. Note however that FriCAS types are parametrized, and type parameter are known only at runtime. Waldek, that sounds as if printing function and constructor name would be quite easy to achieve. Yes, the parameters of the constructor would be nice, but for me it would already be pretty helpful to know function and constructor name. Ralf -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/2515f03a-410c-4f70-a8d8-d32b158c903a%40hemmecke.org.
Re: [fricas-devel] two argument error function
On Fri, Mar 29, 2024 at 11:24:59AM +1100, Hill Strong wrote:
> On Thu, Mar 28, 2024 at 6:02 PM Ralf Hemmecke wrote:
>
> >
> >
> > OK the answer to the above is not soo important to me, but I think Greg
> > is right that the builtin 'error' should automatically show the function
> > name in which it is called. Doesn't the compiler have all this information?
> >
> > Such an improvement would really be great.
> >
>
> The compiler should have enough information to generate appropriate code
> for the builtin function error to be able to generate the
> domain/category/package specification as well as the function in which the
> builtin function is called as well as the relevant parameters used for the
> calling function.
Compiler knows function name and constructor name. Note however
that FriCAS types are parametrized, and type parameter are known
only at runtime. Of course, compiler knows how to access type
parameters. Also note that functions can be overloaded, so
to know which function was called you need its signature (types
of return value and parameters).
> The code generation phase of the compiler should be able
> to generate relevant code that obtains all the necessary runtime
> information and display it. It is far better to get more information
> relating to the error than less.
It depends. Actually in FriCAS I rarely met situations where
information can not be displayed. Problem usually is that
there is way too much info and it is hard to find relevant
part. For example, trace generates a lot of info, but if
one traces "popular" constructor one gets a lot of irrelevant
stuff before important things happen.
And for debugging errors I normally look at backtrace. This
means that for reproducible errors I get way more info that
is reasonable to put into error message. Main drawback of
backtrace is that it works at Lisp level, so info is unreadable
to ordinary FriCAS user. At least using sbcl it is possible
to have user handler for backtrace, so in principle we could
print this info in more convenient way. But that is some
work to do at lowest level in FrICAS. I consider this important,
but other things for me have higher priority. And other folks
have their own priorites. In volunteer open source project telling
other prople to do some work usually is useless: if a person
can and want to do something he/she would do it anyway.
And if a person can not or does not want to do something,
then talk is useless.
> More helpful information reduces the time
> it takes to work out what has gone wrong and what you need to fix that
> specific error.
>
> Yes, I do understand just how much work is involved in doing this and yes
> many people do not see the need for this level of work until it comes and
> bites them on the posterior. If that information is not there, users
> quickly get frustrated (especially new users) and it is always good to have
> new users picking up your systems and becoming enthusiastic proponents of
> the system.
>
> If you go through all calls to error in the FriCAS code base, the current
> error messages are often quite cryptic and of little help in analysing any
> problem that does arise. Since error messages are not the normal mode of
> operation, any system generated code for enhancing error messages will
> not/should not affect any of the normal code being run and should not
> affect how fast the normal mode code runs.
>
> If this is left to the programmer to adjust the various error messages
> throughout the code base, this will be a very large task.
Well, concerning "cryptic error messages", let us look at recent
example posted by Ralf. We got:
>> System error:
The variable $$$ is unbound.
If you consider this carefully, this contains useful information.
First 'System error' tells you that error was detected at lowest
level (by Lisp system in this case). And "The variable $$$ is unbound."
tells you exactly what the problem is: code attempted to access
variable named '$$$' but such variable does not exist at this
time ("unbound" in Lisp terminology).
Of course, ordinary users may consider this cryptic, but IMO the
real trouble was that there was no apparent connection with user
input: from user point of view there was a sequence of commands
that executed OK at command line, but failed inside function body.
I am familiar with FriCAS code and I recently wrote RootSimplification
package that triggered the trouble so I was able to guess part of
explanation. But let us pretend that a developer tries to solve
this starting from "frist principles". First thing to do is to
write
)set break break
After that we get one extra piece of info:
(SB-EVAL::GET-VARIABLE $$$ #)
which may look cryptic, but is the actual Lisp code that failed.
And this confirms that trouble is due to access to '$$$'.
Next thing is get backtrace. Backtrace may be long, so normally
one want only part of it. This time
backtrace 50
(which requires 50 positins) is right thing, but
Re: [fricas-devel] two argument error function
On Thu, Mar 28, 2024 at 6:02 PM Ralf Hemmecke wrote: > > > OK the answer to the above is not soo important to me, but I think Greg > is right that the builtin 'error' should automatically show the function > name in which it is called. Doesn't the compiler have all this information? > > Such an improvement would really be great. > The compiler should have enough information to generate appropriate code for the builtin function error to be able to generate the domain/category/package specification as well as the function in which the builtin function is called as well as the relevant parameters used for the calling function. The code generation phase of the compiler should be able to generate relevant code that obtains all the necessary runtime information and display it. It is far better to get more information relating to the error than less. More helpful information reduces the time it takes to work out what has gone wrong and what you need to fix that specific error. Yes, I do understand just how much work is involved in doing this and yes many people do not see the need for this level of work until it comes and bites them on the posterior. If that information is not there, users quickly get frustrated (especially new users) and it is always good to have new users picking up your systems and becoming enthusiastic proponents of the system. If you go through all calls to error in the FriCAS code base, the current error messages are often quite cryptic and of little help in analysing any problem that does arise. Since error messages are not the normal mode of operation, any system generated code for enhancing error messages will not/should not affect any of the normal code being run and should not affect how fast the normal mode code runs. If this is left to the programmer to adjust the various error messages throughout the code base, this will be a very large task. > Ralf > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/9af94552-a290-4e14-b9d4-b72b4950dd8e%40hemmecke.org > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAEnaMTF9T%3DbDD7tY0uPeJOF%2BiJh3z7p8JfxnvA_9vDZLwmfTdg%40mail.gmail.com.
Re: [fricas-devel] two argument error function
On 3/28/24 03:55, Waldek Hebisch wrote:
On Thu, Mar 28, 2024 at 03:15:46AM +0100, Ralf Hemmecke wrote:
That is easy, we have things like
error "makeSketch: constant polynomial"
That is, include function name as part of error message.
We should, maybe, more often use the two argument error function.
https://github.com/fricas/fricas/blob/master/src/algebra/error.spad#L47
Hmm, have you used them?
Oh, true, I haven't.
Documentation say "callable from the system interpreter". 'error' is
built into Spad compiler...
Wow! I learnt something new. As I understand it, there are two
error: String -> Exit
functions, one builtin and one from ErrorFunctions. I wonder why you say
that calling
error("blah")$ErrorFunctions
in SPAD code might not work. The only strange calls I see are
throwPatternMsg(s, []$(List String))$Lisp
and
"exit" pretend Exit
but are they really problematic?
OK the answer to the above is not soo important to me, but I think Greg
is right that the builtin 'error' should automatically show the function
name in which it is called. Doesn't the compiler have all this information?
Such an improvement would really be great.
Ralf
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/9af94552-a290-4e14-b9d4-b72b4950dd8e%40hemmecke.org.
Re: [fricas-devel] two argument error function
On Thu, Mar 28, 2024 at 03:15:46AM +0100, Ralf Hemmecke wrote: > > That is easy, we have things like > > > > error "makeSketch: constant polynomial" > > > > That is, include function name as part of error message. > > We should, maybe, more often use the two argument error function. > > https://github.com/fricas/fricas/blob/master/src/algebra/error.spad#L47 Hmm, have you used them? Documentation say "callable from the system interpreter". 'error' is built into Spad compiler and it is not clear to me if you can call any other 'error'. Also, if you managed to call them it is not clear if they would for as expected. And finally, what is gain from giving function name as a separate argument? AFAICS in Spad one needs to specify it anyway, so can be part of error 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZgTcLQ_84VxgrPWU%40fricas.org.
