You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
stklos> (define (f) (/ 1 0))
**** Error:
/: cannot make rational with null denominator
(type ",help" for more information)
stklos> (define (g) (-))
**** Error:
compiler-error: -: needs at least one argument
(type ",help" for more information)
And disassemble-expression signals an error:
stklos> (disassemble-expr '(-) #t)
**** Error:
compiler-error: -: needs at least one argument
The previous one was a compilre error. The following is a generic error (because it was not caught in the ilining code - easy o fix actually):
stklos> (disassemble-expr '(/10) #t)
**** Error:
/: cannot make rational with null denominator
(type ",help" for more information)
So... Should the compiler crash when an inlinable expression is not calculable, or should we just, well, leave it there un-optimized, so it will crash when the code is executer? (I'd argue for signaling the error during compilation -- which is, leave it as it is -- as this is useful).
The text was updated successfully, but these errors were encountered:
jpellegrini
changed the title
Should the compiler crash on (-) or (/ 1 0)?
Should the compiler signal error on (-) or (/ 1 0)? (At compilation time?)
May 31, 2024
Not sure about this @egallesio . Tell me what you think..,.
If we turn off inlining,
But with the default (inlining turned on):
stklos> (define (f) (/ 1 0))
**** Error:
/: cannot make rational with null denominator
(type ",help" for more information)
stklos> (define (g) (-))
**** Error:
compiler-error: -: needs at least one argument
(type ",help" for more information)
And
disassemble-expression
signals an error:The previous one was a compilre error. The following is a generic error (because it was not caught in the ilining code - easy o fix actually):
So... Should the compiler crash when an inlinable expression is not calculable, or should we just, well, leave it there un-optimized, so it will crash when the code is executer? (I'd argue for signaling the error during compilation -- which is, leave it as it is -- as this is useful).
The text was updated successfully, but these errors were encountered: