Oh, I think I get it!
You're keeping the code steadfast instead of having a conditional inside valid/1.
valid/1 backs out if the value isn't grounded which makes the next clause trigger keeping all the choice point mangling in a single place.
Am I close?
Like swap the
var/1 and valid/1 tests.
This was in the rbtree.
Here's
check/1:
check(Term) :-
( valid(Term) ->
true
; var(Term) ->
instantiation_error
; type_error(rbtree, Term)
).
It calls
valid/1 which is here: valid(X) :-
var(X),
!,
fail.
valid(t(Nil,Nil)) :-
!.
valid(t(_,Tree)) :-
catch(check_rbtree_root(Tree), _, fail).
So the first clause of
valid/1 calls var/1 right off the start. Then it does the weird cut and fail thing.
Then the very next clause in the conditional calls
var/1.
Throwing an instantiation_error.
Now what I don't understand is why you're structuring this. I thought exceptions wipe away choice points. As do conditionals, in fact? (One of the reasons why conditionals are considered code smell by people like ROK, IIRC?)
The construct
var/1, !, fail looks a lot like you're trying to chew away choice points, but ... the action for the var/1 situation later is an exception so I'm a bit baffled.
That said, type-checking nowadays is preferably accomplished using the
type object.
I had to manually copy them forward from the backup.
Fixed for the Windows installer. Try https://ci.appveyor.com/project/pmoura/logtalk3/builds/40703956/artifacts
In the case of Linux and macOS, the backup of the
$LOGTALKUSERdirectory and the copy of any settings.lgtor settings.logtalk file is done not by the installers but by running the logtalk_user_setup script. This script is automatically called when the $LOGTALKUSERdirectory is outdated due to a new Logtalk version been installed.
Different issue I can't fathom: I'm trying to print debug messages. It's not working. I've compiled the .lgt file with debug(on) in the options. I've manually added set_logtalk_flag(debug, on) in the load script. I am manually TYPING set_logtalk_flag(debug, on) in the toplevel. I am checking that current_logtalk_flag(debug, X) binds 'on' to X.
But all of my print_message(debug, component, Message) calls aren't doing a thing.
If I switch that to information, say, it works.
What step am I missing that makes debug messages display? Does it need to be run in the context of the debugger?
You also don't need to compile code that calls
logtalk::print_message(debug, component, Message)in debug mode.
:- uses(logtalk, [print_message(debug, foo, Message) as dbg(Message)]).
Printing of debug message requires the debug flag to be on when the call is made, not when the code making the calls is compiled.
See the remarks section on https://logtalk.org/library/logtalk_0.html and also https://logtalk.org/manuals/userman/debugging.html#debugging-messages