Some research seems to indicate that at least OpenMCL, ACL and LispWorks maybe have some kind of facility that allows the definition of commands that can be used at the repl that look like--
:command
--or maybe--
:command arg1 [arg2 ... argn]
I know at least clisp has something like this at least in the debugger. Is this is standard Common Lisp facility? (There is also a comma command syntax in scsh, i know, as well.)
Sorry if the question is vague; i don't know if there is an established term for this. I can't find a reference in the Hyperspec. In any case, it might be nice to be able to define commands like that for convenience at the repl. Can it be done?--or is there a reason it's a bad idea?
> Some research seems to indicate that at least OpenMCL, ACL and LispWorks > maybe have some kind of facility that allows the definition of commands > that can be used at the repl that look like--
> :command
> --or maybe--
> :command arg1 [arg2 ... argn]
> I know at least clisp has something like this at least in the debugger. > Is this is standard Common Lisp facility? (There is also a comma command > syntax in scsh, i know, as well.)
> Sorry if the question is vague; i don't know if there is an established > term for this. I can't find a reference in the Hyperspec. In any case, > it might be nice to be able to define commands like that for convenience > at the repl. Can it be done?--or is there a reason it's a bad idea?
There is no reason it is a bad idea. Most Lisp systems have something like that. There is no standard for this. Everybody does it somehow differently. There is not even a widely used portable one for the terminal - besides what you get when you use SLIME + Emacs. McCLIM comes with a window-based listener.
One simple type of command is when the REPL allows you to get rid of the top-level parentheses. LispWorks does that for example for functions with arguments. You can type at the LispWorks listener:
Evans Winner <tho...@timbral.net> writes: > Some research seems to indicate that at least OpenMCL, ACL and LispWorks > maybe have some kind of facility that allows the definition of commands > that can be used at the repl that look like--
> :command
> --or maybe--
> :command arg1 [arg2 ... argn]
> I know at least clisp has something like this at least in the debugger. > Is this is standard Common Lisp facility? (There is also a comma command > syntax in scsh, i know, as well.)
It is not standard. The role of comma is defined only in the context of backquote.
> Sorry if the question is vague; i don't know if there is an established > term for this. I can't find a reference in the Hyperspec. In any case, > it might be nice to be able to define commands like that for convenience > at the repl. Can it be done?--or is there a reason it's a bad idea?
Note that at least in Allegro Common Lisp, the character prefixing these commands (both user defined and system provided) is configurable.
In the case of clisp, there's no prefix character for user commands. They can be any symbol, not just keywords:
C/USER[23]> (com.informatimago.pjb::define-user-commands (:fecha date user1::dote) "Interactive commands" "Prints the date." (com.informatimago.common-lisp.interactive:date)) :FECHA C/USER[24]> :fecha 2008-01-13 20:24:57 C/USER[25]> date 2008-01-13 20:25:00 C/USER[26]> user1::dote 2008-01-13 20:25:04
For clisp users:
To define more easily user commands in clisp, I use these macros:
> > Some research seems to indicate that at least OpenMCL, ACL and LispWorks > > maybe have some kind of facility that allows the definition of commands > > that can be used at the repl that look like--
> > :command
> > --or maybe--
> > :command arg1 [arg2 ... argn]
> > I know at least clisp has something like this at least in the debugger. > > Is this is standard Common Lisp facility? (There is also a comma command > > syntax in scsh, i know, as well.)
> It is not standard. The role of comma is defined only in the context > of backquote.
The comma is used by some Lisp REPLs. They have REPL modes: command preferred and Form preferred (plus command only, Lisp only). In command-preferred mode, the comma is used to prefix Lisp code, so that it is not interpreted as commands. It is called a 'form dispatch character'. The 'Form preferred mode' has a command dispatch character, a colon. Some CLIM listener may use this.
Form preferred:
:Copy File foo.lisp foo1.lisp is interpreted as a command copy is interpreted as a variable
Command preferred:
Copy File foo.lisp foo1.lisp is interpreted as a command ,copy is interpreted as a variable
The comma is used by some Lisp REPLs. They have REPL modes: command preferred and Form preferred (plus command only, Lisp only). In command-preferred mode, the comma is used to prefix Lisp code, so that it is not interpreted as commands. It is called a 'form dispatch character'.
But this is not part of standard CL, right? Is there a portable way to do it? (It sounds like something one could create with a reader-macro, but `:' and `,' as are a lot of other characters, so it might be inherently un-portable...?)
> The comma is used by some Lisp REPLs. They have REPL modes: command > preferred and Form preferred (plus command only, Lisp only). In > command-preferred mode, the comma is used to prefix Lisp code, so > that it is not interpreted as commands. It is called a 'form > dispatch character'.
> But this is not part of standard CL, right?
Right, REPLs are not an extensive part of the standard. Very little about the REPL user interface is said in the standard.
> Is there a portable way to > do it? (It sounds like something one could create with a reader-macro, > but `:' and `,' as are a lot of other characters, so it might be > inherently un-portable...?)
Either you use one of the portable REPLs (I've mentioned SLIME and McCLIM) or you have to use the implementation specific stuff.
Evans Winner <tho...@timbral.net> writes: > Some research seems to indicate that at least OpenMCL, ACL and LispWorks > maybe have some kind of facility that allows the definition of commands > that can be used at the repl that look like--
> :command
> --or maybe--
> :command arg1 [arg2 ... argn]
> I know at least clisp has something like this at least in the debugger. > Is this is standard Common Lisp facility? (There is also a comma command > syntax in scsh, i know, as well.)
The use of colon has nothing to do with the ":" as far as I know.
Because keywords are bound to themselves, there is little point in a REPL to asking their value. Consequently, I believe the reason :foo was chosen as a command is that one can just call READ normally and see if the result was a keyword, and in that case just treat it as a command. Consider the following two interactions for LispWorks, for example. In the first case, there is no leading colon; in the second case, no colon at all.
CL-USER 1 > keyword:?
:bug-form <subject> &key <filename> Print out a bug report form, optionally to a file. :get <variable> <command identifier> Get a command from the history list and put it in a variable. :help Produce this list. :his &optional <n1> <n2> List the command history, optionally the last n1 or range n1 to n2. :redo &optional <command identifier> Redo a previous command, identified by its number or a substring. :use <new form> <old form> &optional <command identifier> Redo command after replacing old form with new form. NIL
CL-USER 1 > #.(intern "?" "KEYWORD")
:bug-form <subject> &key <filename> Print out a bug report form, optionally to a file. :get <variable> <command identifier> Get a command from the history list and put it in a variable. :help Produce this list. :his &optional <n1> <n2> List the command history, optionally the last n1 or range n1 to n2. :redo &optional <command identifier> Redo a previous command, identified by its number or a substring. :use <new form> <old form> &optional <command identifier> Redo command after replacing old form with new form. NIL
> Sorry if the question is vague; i don't know if there is an established > term for this. I can't find a reference in the Hyperspec. In any case, > it might be nice to be able to define commands like that for convenience > at the repl. Can it be done?--or is there a reason it's a bad idea?
You can easily write your own REPL, but there is no very strict spec-defined REPL ... Just some general conventions about how variables like -, +, ++, +++, *, etc. are intended to be managed _if_ there is a REPL at all.
The main reason there is not a total convention about this is that in some implementations there may be a desire to use other conventions.
On Symbolics Genera, : _was_ an escape into a command parser, in the case of :form-preferred prompting, where everything was a form unless prefixed by a parser. In :form-only mode, there was no such escape. In :command-only mode, you were always in command mode. In :command-preferred mode, I believe you didn't need a prefix for commands but could use , to get to forms. In the Symbolics debugger, single keystrokes (characters with various "bucky bits" set, what one would now call modifier bits) were co-opted as command accelerators.
In LispWorks, there are two debugger modes--one that is command line based and uses these commands, but another that is a GUI debugger and does not.
Common Lisp has tried to encourage uniformity where possible but not to tie the hands of implementations wanting to do better. A spec that required keywords to behave a certain way might be seen as one that required implementations to have old-fashioned interfaces. Or such was the fear, as I recall.
There was pressure to remove the "environment functions/commands" from the spec altogether. But I'm glad they weren't removed. Feeble as the conformance requirements are for commands like ROOM, DESCRIBE, DISASSEMBLE, ED, DOCUMENTATION, etc., it's nice to have hinted to implementations that these are things that matter to a community of users. And they create touch points for people who are new to an implementation to get a foothold.
> The comma is used by some Lisp REPLs. They have REPL modes: command > preferred and Form preferred (plus command only, Lisp only). In > command-preferred mode, the comma is used to prefix Lisp code, so > that it is not interpreted as commands. It is called a 'form > dispatch character'.
> But this is not part of standard CL, right? Is there a portable way to > do it? (It sounds like something one could create with a reader-macro, > but `:' and `,' as are a lot of other characters, so it might be > inherently un-portable...?)
You can implement REPLs portably, even REPLs implementing strange syntaxes for characters like #\: and #\,.
But indeed, the REPL provided by the implementations are rather implementation dependent, because they are rather underspecified by the standard. You cannot provide the same kind of features in a REPL based on punch card than in a REPL based on 3D virtual reality interfaces, much less on mind reading devices.
On 2008-01-14 08:20:19 -0500, p...@anevia.com (Pascal J. Bourguignon) said:
> You cannot provide the same kind of features in a REPL > based on punch card than in a REPL based on 3D virtual reality > interfaces, much less on mind reading devices.
I believe this last is more properly called a RESPL ;^)
Kent M Pitman wrote: >> Some research seems to indicate that at least OpenMCL, ACL and LispWorks > On Symbolics Genera, : _was_ an escape into a command parser, in the case > of :form-preferred prompting, where everything was a form unless prefixed > by a parser.
As a point of history, I believe I was the one responsible for this use of the colon char in a repl. More than 20 years ago several of us at Franz were discussing how to provide various useful repl functionality such as load, compile-file, and abort without requiring the user to enter forms. We were thrashing what syntax to use when I suggested the leading colon char. I can remember part of the message being "When was the last time you needed to evaluate a keyword?"
Nonetheless, I'm pretty sure the LispM command repl had already used colon in some sort of similar context, although with different machinery. I have never pondered how the inheritance of this feature passed from one implementation to another, and am disinterested in doing it now.
> Common Lisp has tried to encourage uniformity where possible but not to tie > the hands of implementations wanting to do better.
One could argue that Common Lisp has tried to discourage doing better (in the language development sense) by failing to tie the hands of implementations, but if I presented that question casual readers would think me a troll...
