I may very well be wrong, but I have the impression that Common Lisp has
this ability; I just have no idea how to go about capturing a missing
method (or even just a missing function).
But in any case, such a thing is language dependent, and thus outside the
scope of the project.
One reason why I would like to make a Common Lisp shell, is because Common
Lisp is famous for not having good Unix tools for accessing files, or
making use of the underlying operating system. In my twisted logic, I
concluded that the best way to get those features, would be to make the
interpreter into a shell.
That, and I'd much rather use Common Lisp over Bash Script as the Turing
Complete Scripting Language of the shell! :-)
One thing that I'll miss, at least until it's implemented, is
tab-complete. As CL shells go, to the best of my knowledge, only clisp has
tab-completion; and it probably isn't as refined as Bash's tab completion
is!
On Fri, Jul 27, 2012 at 3:24 PM, Ben Booth <benwbo...@gmail.com> wrote:
> OK, here's another idea, although it might be outside of the scope of a
> lisp-reader:
>
> Dynamic languages such as perl or ruby have a feature where an attempt to
> call an undefined function results in the interpreter calling a catch-all
> function, called method_missing in ruby, and AUTOLOAD in perl. This
> functionality would be extremely useful for a lisp shell scripting
> language, so that if you attempted to execute a function that was
> undefined, you could write the catch-all function to instead execute a
> shell command using the function's arguments converted to strings, then
> return the command's exit code. This would allow seamless mixing of
> functions and shell commands. BASH does something similar to this-- you can
> define functions that operate like commands. When BASH interprets a
> command, it first checks to see if there's a matching function with that
> name. If not, it tries to run it as a command.
>
> Like I said, this might be outside the scope of this project, and would
> probably make more sense as a feature of the language instead of the
> syntax. But it could conceivably be implemented as part of the reader, if
> the reader were capable of keeping track of which symbols were defined and
> undefined in any given context, similar to how a hygienic macro expander
> works. If a catch-all function has been declared, a call to an undefined
> function would be replaced with a call to the catch-all function.
>
> The benefit of this feature for a lisp shell would be seamless command
> execution, without having to prefix the command with "run" or some other
> function name.
>
> OK, enough crazy talk for now :)
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Readable-discuss mailing list
> Readable-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
