Launching Logtalk with common loading flag #93
Replies: 3 comments 12 replies
-
That's an idea that surfaced in the past. As you likely know, there's no standard set of command-line options shared by most Prolog systems. Thus, the idea of the Logtalk integration scripts abstracting a subset of those options (notably, loading a file and calling a goal) in order to present a common view to the user is certainly appealing. On the other hand, users may also expect to be able to (as it's possible with the current scripts) use the specific command-line options provided by a Prolog system (the integration scripts simply pass those options to the backend). One possible solution would be to use long options names, thus both avoiding conflicts with backend options while still allowing them to be used in tandem. |
Beta Was this translation helpful? Give feedback.
-
Found a StackOverflow discussion on how to handle long options using the Bash built-in This seems to provide an implementation solution without the portability issues (across operating-systems) of the |
Beta Was this translation helpful? Give feedback.
-
Long flags makes a lot of sense, good idea! |
Beta Was this translation helpful? Give feedback.
-
Different Prolog systems accept an initial file to consult in different manners, some with a flag and some just as the first arg.
It'd be nice to create a uniform interface for the Logtalk integration scripts (eclipselgt, gplgt, swilgt, etc) such that we can always specify the file to
logtalk_load/1
. This would allow us to launch Logtalk like so (if the-l
flag were chosen for the implementation)::~$ logtalk -l loader.lgt
This should always be the same no matter which backend was selected.
Beta Was this translation helpful? Give feedback.
All reactions