Hi al
Just wondering about a few things:
1) Is there any way that a Lisp program can be compiled and saved like
an .exe file in C++?
2) Is there and import or #include statement in Lisp? I hear that
defpackage is similar to #include, but I'm not sure.
Thanks.
--
Certum quod factum.
Philip Haddad
·············@gmail.com (Philip Haddad) writes:
> Hi al
> Just wondering about a few things:
> 1) Is there any way that a Lisp program can be compiled and saved like
> an .exe file in C++?
Yes, there is.
> 2) Is there and import or #include statement in Lisp? I hear that
> defpackage is similar to #include, but I'm not sure.
> Thanks.
LOAD.
(eval-when (:compile-toplevel :load-toplevel :execute)
(load "included-file.lisp"))
Also, I have this function:
(DEFUN INCLUDE (PATH)
"
NOTE: Untasty, but sometimes useful.
DO: Read from the file at PATH all the sexps and returns a list of them
prefixed with 'progn.
USAGE: #.(include \"source.lisp\")
"
(CONS 'PROGN
(WITH-OPEN-FILE (FILE PATH :DIRECTION :INPUT :IF-DOES-NOT-EXIST :ERROR)
(DO ((RESULT '())
(EOF (GENSYM)))
((EQ EOF (CAR RESULT)) (NREVERSE (CDR RESULT)))
(PUSH (READ FILE NIL EOF) RESULT)))));;INCLUDE
which still has some problems, for example, it reads the whole file as
a single sexp, therefore all packages used (package:symbol or
package::symbol) have to be pre-defined. But its behavior is closer to
#include, since it can be used at read-time.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uoeisr9q0.fsf@news.dtpq.com>
·············@gmail.com (Philip Haddad) writes:
> Hi al
> Just wondering about a few things:
> 1) Is there any way that a Lisp program can be compiled
> and saved like an .exe file in C++?
Of course! The exact incantation for creating an executable file
will vary from system to system (just as for any other language).
The procedure is similar to what you would do for any other language,
except that rather than using multiple tools (such as Makefiles
and linker passes), all of that stuff is part of Lisp itself.
In most Lisp systems the file compiler produces what's called
a FASL ("fast load") file, which Lisp can dynamically load.
These are similar to object (".o") files in C.
In the system I use most often, you write a (Lisp) script that does
two things. First, it loads up your application by calling LOAD on
each of the FASL files, or by calling some DEFSYSTEM facility's function
such as LOAD-SYSTEM that does a bunch of them (similar to "make"),
Then to dump out the executable file, the script calls DELIVER on the
filename that you want to be your file (eg. on Windows, "FOO.EXE").
> 2) Is there and import or #include statement in Lisp? I hear that
> defpackage is similar to #include, but I'm not sure.
The function LOAD brings in a source or FASL file.
The package system in Lisp is only about namespaces.
On Sun, 24 Oct 2004 05:00:55 GMT, <······@news.dtpq.com> wrote:
>
> In the system I use most often, you write a (Lisp) script that does
> two things. First, it loads up your application by calling LOAD on
> each of the FASL files, or by calling some DEFSYSTEM facility's function
> such as LOAD-SYSTEM that does a bunch of them (similar to "make"),
> Then to dump out the executable file, the script calls DELIVER on the
> filename that you want to be your file (eg. on Windows, "FOO.EXE").
So every such file includes 'lisp' and is somewhat large?
--
Brownian motion is correctly colored.
Time Waster wrote:
> On Sun, 24 Oct 2004 05:00:55 GMT, <······@news.dtpq.com> wrote:
>>
>> In the system I use most often, you write a (Lisp) script that does
>> two things. First, it loads up your application by calling LOAD on
>> each of the FASL files, or by calling some DEFSYSTEM facility's function
>> such as LOAD-SYSTEM that does a bunch of them (similar to "make"),
>> Then to dump out the executable file, the script calls DELIVER on the
>> filename that you want to be your file (eg. on Windows, "FOO.EXE").
>
>
> So every such file includes 'lisp' and is somewhat large?
>
Yes, of course, but with some caveats:
- "Includes Lisp" ideally means "loads the Lisp core via dynamic linking".
- We're talking less than 10MB here. That's not very much, these days.
In other words, you only pay the price of nothing *else* on the system uses
Lisp, same as with any other language.
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uekjoozqw.fsf@news.dtpq.com>
Time Waster <········@CloudDancer.com> writes:
> On Sun, 24 Oct 2004 05:00:55 GMT, <······@news.dtpq.com> wrote:
> >
> > In the system I use most often, you write a (Lisp) script that does
> > two things. First, it loads up your application by calling LOAD on
> > each of the FASL files, or by calling some DEFSYSTEM facility's function
> > such as LOAD-SYSTEM that does a bunch of them (similar to "make"),
> > Then to dump out the executable file, the script calls DELIVER on the
> > filename that you want to be your file (eg. on Windows, "FOO.EXE").
> So every such file includes 'lisp' and is somewhat large?
The Lisp runtime needs to be present in memory, obviously.
This is the same as for all languages.
In the system that I use most often, the runtime is dumped out into
the executable file (similar to a statically linked C program).
My executable files from Lisp are smaller than the ones for most
programs in C++ and other languages -- the Lisp runtime seems to
be somewhere under 2 MB.
(I don't know where the 10 MB number someone else cited comes from;
that's 5 times larger than what I see. Different Lisp systems will
work differently, of course.)
Christopher C. Stacy wrote:
> (I don't know where the 10 MB number someone else cited comes from;
> that's 5 times larger than what I see. Different Lisp systems will
> work differently, of course.)
That would be me, misremembering.
sbcl.core is actually 24MB, but hopefully it won't always include all of
that.
Philip Haddad wrote:
> Hi al
> Just wondering about a few things:
> 1) Is there any way that a Lisp program can be compiled and saved like
> an .exe file in C++?
Yes, but as in most languages (including C++), this is not part of the
language standard. (For example, .exe don't help you a lot on Unix
platforms. ;)
Check out the various Common Lisp implementations for Windows that
provide ways to create such executables.
> 2) Is there and import or #include statement in Lisp? I hear that
> defpackage is similar to #include, but I'm not sure.
defpackage provides a way to define packages (ha!) which are a kind of
module system. use-package lets you import definitions from such
packages. In order to understand packages, you first (or at least also)
need to understand Common Lisp's symbols, because it is in fact not the
definitions that you import/export but just symbols. However, since
global function and variable definitions are bound to symbols, you
essentially get the effect you need.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
> Yes, but as in most languages (including C++), this is not part of the
> language standard. (For example, .exe don't help you a lot on Unix
> platforms. ;)
>
> Check out the various Common Lisp implementations for Windows that
> provide ways to create such executables.
Maybe I should rephrase that. I use Linux, so I don't want an actual
.exe file. I want to be able to load a fasl file independently of
toplevel. I want to be able to punch it into bash or open it from X
windows, and have it run all by itself.
> > 2) Is there and import or #include statement in Lisp? I hear that
> > defpackage is similar to #include, but I'm not sure.
>
> defpackage provides a way to define packages (ha!) which are a kind of
> module system. use-package lets you import definitions from such
> packages. In order to understand packages, you first (or at least also)
> need to understand Common Lisp's symbols, because it is in fact not the
> definitions that you import/export but just symbols. However, since
> global function and variable definitions are bound to symbols, you
> essentially get the effect you need.
>
>
> Pascal
--
Certum quod factum.
Philip Haddad
On 24 Oct 2004 09:03:31 -0700, ·············@gmail.com (Philip Haddad) wrote:
> Maybe I should rephrase that. I use Linux, so I don't want an actual
> .exe file. I want to be able to load a fasl file independently of
> toplevel. I want to be able to punch it into bash or open it from X
> windows, and have it run all by itself.
Have you looked at the documentation for your Lisp implementation?
Last time I looked at least CMUCL, CLISP, AllegroCL, and LispWorks
explained how to do this in detail.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Philip Haddad wrote:
> Hi al
> Just wondering about a few things:
> 1) Is there any way that a Lisp program can be compiled and saved like
> an .exe file in C++?
> 2) Is there and import or #include statement in Lisp? I hear that
> defpackage is similar to #include, but I'm not sure.
> Thanks.
I have similar needs and would like to add a third question:
3) Is there a portable way of getting command line arguments?
-- MJF
M Jared Finder <·····@hpalace.com> writes:
> 3) Is there a portable way of getting command line arguments?
The existence and structure of command line arguments is not a portable
concept, so it can't be standardized.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain escreveu:
> M Jared Finder <·····@hpalace.com> writes:
>
>
>>3) Is there a portable way of getting command line arguments?
>
>
> The existence and structure of command line arguments is not a portable
> concept, so it can't be standardized.
>
Nor for 'hosted' environments?
M Jared Finder skribis:
> 3) Is there a portable way of getting command line arguments?
No.
But, for instance, in clisp you get the arguments in *args* list.
See http://clisp.cons.org/impnotes/quickstart.html#script-exec
Other implementations should have similar methods.
--
Luís Oliveira Lisp is the red pill.
Reply-To: luismbo (@) netcabo (.) pt -- John Fraser, comp.lang.lisp
Equipa Portuguesa do Translation Project
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=pt
M Jared Finder <·····@hpalace.com> writes:
> Philip Haddad wrote:
> > Hi al
> > Just wondering about a few things:
> > 1) Is there any way that a Lisp program can be compiled and saved like
> > an .exe file in C++?
> > 2) Is there and import or #include statement in Lisp? I hear that
> > defpackage is similar to #include, but I'm not sure.
> > Thanks.
>
> I have similar needs and would like to add a third question:
>
> 3) Is there a portable way of getting command line arguments?
What are command line arguments? I just double-click on my icons...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon wrote:
> M Jared Finder <·····@hpalace.com> writes:
>>Philip Haddad wrote:
>>
>>>Hi al
>>>Just wondering about a few things:
>>>1) Is there any way that a Lisp program can be compiled and saved like
>>>an .exe file in C++?
>>>2) Is there and import or #include statement in Lisp? I hear that
>>>defpackage is similar to #include, but I'm not sure.
>>>Thanks.
>>
>>I have similar needs and would like to add a third question:
>>
>>3) Is there a portable way of getting command line arguments?
>
> What are command line arguments? I just double-click on my icons...
I think I get what you're implying -- that to end users, the command
line doesn't exist. As a developer, I am very familiar with the concept
of a command line and I have many tools available from the command line
or that call other tools via the command line that I would like to use.
Tools such as cp, mv, make, as well as scripts written in other languages.
In theory, I could reimplement all of these in Lisp, thus providing a
nice Lisp interface to everything. But that would take a *long* time,
as there are tons upon tons of tools and more are being made all the
time. I would still like to provide a Lispy interface to shell commands
as well as a shell interface to Lisp functions. This way both sides are
happy as they talk in their "native" language.
-- MJF
M Jared Finder <·····@hpalace.com> writes:
> Pascal Bourguignon wrote:
> > M Jared Finder <·····@hpalace.com> writes:
> >>Philip Haddad wrote:
> >>
> >>>Hi al
> >>>Just wondering about a few things:
> >>>1) Is there any way that a Lisp program can be compiled and saved like
> >>>an .exe file in C++?
> >>>2) Is there and import or #include statement in Lisp? I hear that
> >>>defpackage is similar to #include, but I'm not sure.
> >>>Thanks.
> >>
> >>I have similar needs and would like to add a third question:
> >>
> >>3) Is there a portable way of getting command line arguments?
> > What are command line arguments? I just double-click on my icons...
>
> I think I get what you're implying -- that to end users, the command
> line doesn't exist.
More precisely: on some operating system, there is absolutely no
notion of command line. For example, in MacOS (not MacOSX), there was
no way to give any command-line argument to applications. Another
example would be PalmOS. Someone else has mentionned embedded
environments without any notion of command line.
THEREFORE, there is no way to portably get command line arguments
BECAUSE the notion of command line is not universal.
> As a developer, I am very familiar with the
> concept of a command line and I have many tools available from the
> command line or that call other tools via the command line that I
> would like to use. Tools such as cp, mv, make, as well as scripts
> written in other languages.
>
> In theory, I could reimplement all of these in Lisp, thus providing a
> nice Lisp interface to everything. But that would take a *long* time,
> as there are tons upon tons of tools and more are being made all the
> time. I would still like to provide a Lispy interface to shell
> commands as well as a shell interface to Lisp functions. This way
> both sides are happy as they talk in their "native" language.
What one could ask and be expecting, is a complementary standard for
Common-Lisp on POSIX systems, where command-line arguments exist along
all the range of POSIX implementations, and where we could have a
unique API. Unfortunately, each implementation of Common-Lisp chooses
a different way.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon <····@mouse-potato.com> writes:
> More precisely: on some operating system, there is absolutely no
> notion of command line. For example, in MacOS (not MacOSX), there was
> no way to give any command-line argument to applications. Another
> example would be PalmOS. Someone else has mentionned embedded
> environments without any notion of command line.
>
> THEREFORE, there is no way to portably get command line arguments
> BECAUSE the notion of command line is not universal.
This is not a good justification. By the same reasoning, as I'm sure
there exist embedded systems with no filesystems, would that imply
that the standard should not include any functions dealing with
pathnames?
Being able to access command line arguments on systems which do have
them is *useful* for many applications; it allows them to interoperate
with the environment. There is no reason to make the interface
different in different Lisp implementations. A standard should provide
a universal API for aspects common to many environments.
Implementations don't have to provide *interesting* arguments on
systems which don't have this concept. They would always be empty
for example. But they would be accessible in other implementations,
in particular all implementations on all Unices and Windows. What
would be wrong with that?
And while in theory applications can agree on an API without a
standard, in practice too often they don't. They don't in this
case at least: CLisp has *args*, SBCL has *posix-argv*, GCL has
system:*command-args* and system:argv function (and I will not
check which of them include the program name and which don't).
I would accept the justification: when the standard was designed,
command line arguments were rare among systems. I don't believe this
though; Unix did exist then. The mere fact that they don't exist on
all platforms is not enough. Directories don't exist on all platforms
- should they be excluded from CL?
Maybe the reason is that CL was not designed to produce standalone
executables at all, only to play at REPL?
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uk6tdah76.fsf@news.dtpq.com>
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > More precisely: on some operating system, there is absolutely no
> > notion of command line. For example, in MacOS (not MacOSX), there was
> > no way to give any command-line argument to applications. Another
> > example would be PalmOS. Someone else has mentionned embedded
> > environments without any notion of command line.
> >
> > THEREFORE, there is no way to portably get command line arguments
> > BECAUSE the notion of command line is not universal.
>
> This is not a good justification. By the same reasoning, as I'm sure
> there exist embedded systems with no filesystems, would that imply
> that the standard should not include any functions dealing with
> pathnames?
Have you _seen_ the pathname support?
It's badly crippled exactly because of this.
> Being able to access command line arguments on systems [...]
> A standard should provide a universal API for aspects common
> to many environments.
Yes, but not the core language standard.
> And while in theory applications can agree on an API without a
> standard, in practice too often they don't.
You mean like CL-SQL? Or do you mean one of the other packages?
> They don't in this case at least:
Since this whole thing will take about 5 minutes to implement
portably for all existing platforms, why don't you just invent
the API that you want for your programs and write the library.
> I would accept the justification: when the standard was designed,
> command line arguments were rare among systems.
Command-line arguments were more common, not less common, back then.
> Maybe the reason is that CL was not designed to produce standalone
> executables at all, only to play at REPL?
People have already explained the reason; apparently you just don't get it.
······@news.dtpq.com (Christopher C. Stacy) writes:
> You mean like CL-SQL? Or do you mean one of the other packages?
How many implementations of CL-SQL are there?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uk6tdcktv.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > You mean like CL-SQL? Or do you mean one of the other packages?
>
> How many implementations of CL-SQL are there?
Hmm? Doesn't it run on most everything now?
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> You mean like CL-SQL? Or do you mean one of the other packages?
>
> How many implementations of CL-SQL are there?
Approximately three: CommonSQL from Xanalys, UncommonSQL from Onshore
Development, and CL-SQL from Kevin Rosenberg and contributors.
Admittedly UncommonSQL has (AIUI) been deprecated in favour of CL-SQL
-dan
--
"please make sure that the person is your friend before you confirm"
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <u3c012awq.fsf@news.dtpq.com>
Daniel Barlow <···@telent.net> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > ······@news.dtpq.com (Christopher C. Stacy) writes:
> >> You mean like CL-SQL? Or do you mean one of the other packages?
> >
> > How many implementations of CL-SQL are there?
>
> Approximately three: CommonSQL from Xanalys, UncommonSQL from Onshore
> Development, and CL-SQL from Kevin Rosenberg and contributors.
>
> Admittedly UncommonSQL has (AIUI) been deprecated in favour of CL-SQL
My observation was that there's a universally implemented standard
for doing SQL databases in Common Lisp, written not by the vendors
but by users. My point was that it should therefore be possible
for there to be a similar standard for fetching the command-line,
which is not 10,000 lines of code, but only about 2 lines of code.
Christopher C. Stacy wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>>Pascal Bourguignon <····@mouse-potato.com> writes:
>>
>>>More precisely: on some operating system, there is absolutely no
>>>notion of command line. For example, in MacOS (not MacOSX), there was
>>>no way to give any command-line argument to applications. Another
>>>example would be PalmOS. Someone else has mentionned embedded
>>>environments without any notion of command line.
>>>
>>>THEREFORE, there is no way to portably get command line arguments
>>>BECAUSE the notion of command line is not universal.
>>
>>This is not a good justification. By the same reasoning, as I'm sure
>>there exist embedded systems with no filesystems, would that imply
>>that the standard should not include any functions dealing with
>>pathnames?
>
>
> Have you _seen_ the pathname support?
> It's badly crippled exactly because of this.
>
>
>>Being able to access command line arguments on systems [...]
>>A standard should provide a universal API for aspects common
>>to many environments.
>
>
> Yes, but not the core language standard.
>
>
>>And while in theory applications can agree on an API without a
>>standard, in practice too often they don't.
>
>
> You mean like CL-SQL? Or do you mean one of the other packages?
>
>
>>They don't in this case at least:
>
>
> Since this whole thing will take about 5 minutes to implement
> portably for all existing platforms, why don't you just invent
> the API that you want for your programs and write the library.
>
>
>>I would accept the justification: when the standard was designed,
>>command line arguments were rare among systems.
>
>
> Command-line arguments were more common, not less common, back then.
>
>
>>Maybe the reason is that CL was not designed to produce standalone
>>executables at all, only to play at REPL?
>
>
> People have already explained the reason; apparently you just don't get it.
Apparently I don't. My view is the same as Marcin's, that by the same
logic as "operating systems exist which have no support for the command
line, therefore we should not support the command line" you could state
"operating systems exist which have no support for opening and closing
files, therefore we should not support files".
But obviously Common Lisp has support for opening and closing files, as
I can replicate the `cat' command like this:
(defun cat (&rest files)
(dolist (file files)
(with-open-file (stream file)
(do ((char (read-char stream nil nil) (read-char stream nil
nil)))
((null char))
(write-char char)))))
So why does Lisp provide support for files but not for command line
arguments?
-- MJF
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <u654wlzzt.fsf@news.dtpq.com>
M Jared Finder <·····@hpalace.com> writes:
> So why does Lisp provide support for files but not for command line
> arguments?
Lisp is a useless language, and is obviously not for you;
you should stop wasting your time here and move on.
MJF> Apparently I don't. My view is the same as Marcin's, that by the
MJF> same logic as "operating systems exist which have no support for
MJF> the command line, therefore we should not support the command
MJF> line" you could state "operating systems exist which have no
MJF> support for opening and closing files, therefore we should not
MJF> support files".
The concepts of opening and closing files is fairly uniform across
systems that do support them, so it wasn't too hard for the committee
to agree on an API. OTOH, command line arguments can be expected to
behave differently on different systems, so the effort to design a
coherent interface is higher.
It is only in recent years that lisp startup-times have become short
enough to make #!/bin/lisp-scripts viable. If you start your lisp
image once a week, why bother about options syntax? Actually, I
suspect the committee never considered neither command line arguments
nor environment variables. And if they did, they were probably too
fatigue after their effort on pathnames:-)
Ole
·········@cern.ch wrote:
> MJF> Apparently I don't. My view is the same as Marcin's, that by the
> MJF> same logic as "operating systems exist which have no support for
> MJF> the command line, therefore we should not support the command
> MJF> line" you could state "operating systems exist which have no
> MJF> support for opening and closing files, therefore we should not
> MJF> support files".
>
> The concepts of opening and closing files is fairly uniform across
> systems that do support them, so it wasn't too hard for the committee
> to agree on an API. OTOH, command line arguments can be expected to
> behave differently on different systems, so the effort to design a
> coherent interface is higher.
>
> It is only in recent years that lisp startup-times have become short
> enough to make #!/bin/lisp-scripts viable. If you start your lisp
> image once a week, why bother about options syntax? Actually, I
> suspect the committee never considered neither command line arguments
> nor environment variables. And if they did, they were probably too
> fatigue after their effort on pathnames:-)
Thank you for your well articulated answer. I'm young compared to all
the people here (who I gather are 30 - 40+) and have no experience
programming on operating systems other than Unix-like ones. I used a
Mac for programming *way back when*, and dimly recall it crashing to
some sort of command line, but that's about it.
-- MJF
On 2004-10-28 12:58:40 -0400, M Jared Finder <·····@hpalace.com> said:
> I used a Mac for programming *way back when*, and dimly recall it
> crashing to some sort of command line, but that's about it.
That was (is) a debugger, not a true command line, and optional as
well - ordinary users' machines did not typically have macsbug
installed at all.
Raffael Cavallaro wrote:
> On 2004-10-28 12:58:40 -0400, M Jared Finder <·····@hpalace.com> said:
>
>> I used a Mac for programming *way back when*, and dimly recall it
>> crashing to some sort of command line, but that's about it.
>
>
> That was (is) a debugger, not a true command line, and optional as well
> - ordinary users' machines did not typically have macsbug installed at all.
Was macsbug known for being buggy? That Mac was the most unstable
machine I've ever worked with; it would reliably crash every one to two
hours, even if you weren't doing anything with it.
-- MJF
M Jared Finder wrote:
> Raffael Cavallaro wrote:
>
>> On 2004-10-28 12:58:40 -0400, M Jared Finder <·····@hpalace.com> said:
>>
>>> I used a Mac for programming *way back when*, and dimly recall it
>>> crashing to some sort of command line, but that's about it.
>>
>>
>>
>> That was (is) a debugger, not a true command line, and optional as
>> well - ordinary users' machines did not typically have macsbug
>> installed at all.
>
>
> Was macsbug known for being buggy?
No, but MacOS was. It was not really an OS at all, but a very large
subroutine library running assembly, Pascal, and C code all in the same
heap with rather idiosyncratic memory management (and without any sort
of memory protection until pretty late in the game). A small, simple
boo-boo could (and very often did) take down the entire machine.
>That Mac was the most unstable
> machine I've ever worked with; it would reliably crash every one to two
> hours, even if you weren't doing anything with it.
That's fairly extreme, but several crashes a day while in use were not
unusual.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
> On 2004-10-28 12:58:40 -0400, M Jared Finder <·····@hpalace.com> said:
>
> > I used a Mac for programming *way back when*, and dimly recall it
> > crashing to some sort of command line, but that's about it.
>
> That was (is) a debugger, not a true command line, and optional as
> well - ordinary users' machines did not typically have macsbug
> installed at all.
I seem to remember that there was a small rom based debugger as well,
you could at least type G to continue execution and inspect the 68k
registers.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad <·············@gustad.com> writes:
> I seem to remember that there was a small rom based debugger as well,
> you could at least type G to continue execution and inspect the 68k
> registers.
that's right.
(On the SE there was an easter egg showing a slide show of the
developers, you could start that by using the G command to
resue execution at a specific address)
--
(espen)
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-dot-mac.com> wrote:
> On 2004-10-28 12:58:40 -0400, M Jared Finder <·····@hpalace.com> said:
> > I used a Mac for programming *way back when*, and dimly recall it
> > crashing to some sort of command line, but that's about it.
> That was (is) a debugger, not a true command line, and optional as
> well - ordinary users' machines did not typically have macsbug
> installed at all.
There was MPW Shell, which was essentially a command line -- but that
wasn't installed on most user macs either.
Michael
M Jared Finder <·····@hpalace.com> writes:
> I used a Mac for programming *way back when*, and dimly recall it
> crashing to some sort of command line, but that's about it.
Uh... that's a machine debugger. You can't exactly type in names of
applications and have them run from there, heh. You can peek and poke at
memory and step over instructions, tho, and if you install a better
debugger like Macsbug, you can get disassemblies and analyze the heap
and even install plugins to do all kinds of funky stuff.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
M Jared Finder <·····@hpalace.com> writes:
> So why does Lisp provide support for files but not for command line
> arguments?
Where do the command line arguments come from on a Lisp machine and why
are they comparable to command line arguments in an invocation from a
Unix command line and why would a Windows command line have the same
syntax as a Unix one? You need something _different_ than just a bunch
of strings typed by the user. You need a command line arg parser that's
appropriate for the host OS's conventions.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uacu3svnn.fsf@news.dtpq.com>
Rahul Jain <·····@nyct.net> writes:
> M Jared Finder <·····@hpalace.com> writes:
>
> > So why does Lisp provide support for files but not for command line
> > arguments?
>
> Where do the command line arguments come from on a Lisp machine
The Lisp Machine had the fanciest command-line parser, ever.
It was based on the functionality of the TOPS-20 command-line,
but it was object-oriented and based on presentations.
Of course, that makes it quite different from the command-line
interfaces on systems like Unix -- theres no list of string
arguments for the application to parse, or whatever.
> You need a command line arg parser that's appropriate
> for the host OS's conventions.
Gee, isn't everything Unix, and isn't that the same as DOS?
:)
Christopher C. Stacy wrote:
> Rahul Jain <·····@nyct.net> writes:
>>M Jared Finder <·····@hpalace.com> writes:
>>
>>
>>>So why does Lisp provide support for files but not for command line
>>>arguments?
>>
>>You need a command line arg parser that's appropriate
>>for the host OS's conventions.
>
> Gee, isn't everything Unix, and isn't that the same as DOS?
> :)
While I know that that statement was in jest, it seems that all modern
operating systems either have Unix style commandlines, or have no
concept of the command line at all. What operating systems exist at the
moment that aren't Unix like and have a command line?
-- MJF
M Jared Finder <·····@hpalace.com> writes:
> While I know that that statement was in jest, it seems that all modern
> operating systems either have Unix style commandlines, or have no
> concept of the command line at all. What operating systems exist at the
> moment that aren't Unix like and have a command line?
Windows NT.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uhdoblfng.fsf@news.dtpq.com>
Rahul Jain <·····@nyct.net> writes:
> M Jared Finder <·····@hpalace.com> writes:
>
> > While I know that that statement was in jest, it seems that all modern
> > operating systems either have Unix style commandlines, or have no
> > concept of the command line at all. What operating systems exist at the
> > moment that aren't Unix like and have a command line?
>
> Windows NT.
I understand the original proposed problem to be that the ANSI Common
Lisp language standard does not define a standard function that returns
a string corresponding to the command-line typed in by the user.
It's already been explained that this doesn't belong in the language
standard, but rather in a standard extension library. It was then
suggested that such a library would be hard to write. It was then
explained that we're talking about less than six lines of code, and
examples were cited of very complex portable libraries such as CL-SQL.
Now the complaints have returned full-cycle that since such standard
code has (allegedly) not been written, Lisp is unusable.
My feeling is that if someone is unable to figure out how to design
and write two or three lines of code to implement the standard,
something like this:
(defun standard-get-the-command-line ()
(implementation-specific:get-the-command-line))
then they should not be trying to write computer programs.
Christopher C. Stacy wrote:
> Rahul Jain <·····@nyct.net> writes:
>>M Jared Finder <·····@hpalace.com> writes:
>>
>>
>>>While I know that that statement was in jest, it seems that all modern
>>>operating systems either have Unix style commandlines, or have no
>>>concept of the command line at all. What operating systems exist at the
>>>moment that aren't Unix like and have a command line?
>>
>>Windows NT.
Really? Window's command line seems awfully Unix like:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcommandline.asp
If you're talking about command line tools like mv and cp, those are
easy enough to add.
> I understand the original proposed problem to be that the ANSI Common
> Lisp language standard does not define a standard function that returns
> a string corresponding to the command-line typed in by the user.
> It's already been explained that this doesn't belong in the language
> standard, but rather in a standard extension library. It was then
> suggested that such a library would be hard to write. It was then
> explained that we're talking about less than six lines of code, and
> examples were cited of very complex portable libraries such as CL-SQL.
>
> Now the complaints have returned full-cycle that since such standard
> code has (allegedly) not been written, Lisp is unusable.
>
> My feeling is that if someone is unable to figure out how to design
> and write two or three lines of code to implement the standard,
> something like this:
>
> (defun standard-get-the-command-line ()
> (implementation-specific:get-the-command-line))
>
> then they should not be trying to write computer programs.
Since I brought up the original point, I'll assume that this is targeted
at me. I have written such a function. Writing the function was
extremely easy and did not make Lisp any more or less usable. However,
just because something is easy to write, doesn't mean that it shouldn't
be in a standard library. NTH is easy to write, but it still is in the
standard library.
I see the key benefit of having a standard library beyond core
primitives as providing a standard style of discourse with regards to
different subjects. I think this is more important for simple things
than for difficult things, because simple things are likely to be
duplicated instead of reused. Imagine if something as simple as NTH was
called LIST-AREF in one implementation, LIST-INDEX in another, NTH in
yet another!
-- MJF
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <u1xff74hn.fsf@news.dtpq.com>
M Jared Finder <·····@hpalace.com> writes:
> However, just because something is easy to write, doesn't mean that it
> shouldn't be in a standard library. NTH is easy to write, but it
> still is in the standard library.
NTH is applicable to all platforms where Common Lisp ran in the past,
runs today, and will run in the future; but the same cannot be
said for a command-line interface (even for just "today").
That's why it's not there; this has been explained several times.
> I have written such a function. Writing the function
> was extremely easy and did not make Lisp any more or less usable.
If it was trivial and doesn't make it any more usable, it must
not have been very important. (On the other hand, if there is some
demand for this feature, then perhaps people will adopt yours.)
What a tremendous amount of noise over nothing.
······@news.dtpq.com (Christopher C. Stacy) writes:
> M Jared Finder <·····@hpalace.com> writes:
> > However, just because something is easy to write, doesn't mean that it
> > shouldn't be in a standard library. NTH is easy to write, but it
> > still is in the standard library.
>
> NTH is applicable to all platforms where Common Lisp ran in the past,
> runs today, and will run in the future; but the same cannot be
> said for a command-line interface (even for just "today").
> That's why it's not there; this has been explained several times.
I can understand the general philosophy of this, but it seems that
perhaps some sort of interface to "program parameters" would not be a
bad thing to have in the language. On platforms without a command line
interface, one could imagine that vendors could create a different way
of specifying and supplying such parameters.
Presumably such an interface might take the form of an ALIST or other
structure which associates keys with values.
There are certainly other functions that are in the standard that are
not really applicable to all potential platforms. Certain embedded
processors don't have file systems, but that wouldn't be a good argument
for not including file system operations in the CL standard.
In fact, I think that the lack of a DIRECTORY-P predicate for pathnames
is a real weakness of the standard. It makes it impossible to write a
portable file system traversal within standard Common Lisp. IIRC the
argument against this was partly that not all file systems have
directory structures. But for such file systems, it would be simple
enough to have DIRECTORY-P always return NIL.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <u4qk851gu.fsf@news.dtpq.com>
···@sevak.isi.edu (Thomas A. Russ) writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > M Jared Finder <·····@hpalace.com> writes:
> > > However, just because something is easy to write, doesn't mean that it
> > > shouldn't be in a standard library. NTH is easy to write, but it
> > > still is in the standard library.
> >
> > NTH is applicable to all platforms where Common Lisp ran in the past,
> > runs today, and will run in the future; but the same cannot be
> > said for a command-line interface (even for just "today").
> > That's why it's not there; this has been explained several times.
>
> I can understand the general philosophy of this, but it seems that
> perhaps some sort of interface to "program parameters" would not be a
> bad thing to have in the language. On platforms without a command line
> interface, one could imagine that vendors could create a different way
> of specifying and supplying such parameters.
>
> Presumably such an interface might take the form of an ALIST or
> other structure which associates keys with values.
While I believe that there are some things that could be improved
in the standard, it cannot be underestimated that adopting a feature
into the ANSI Common Lisp standard is a very problematic venture.
The political, technical, and financial implications are enormous.
I don't think that most people comprehend what it means to invoke
the ANSI mechanism. Because of that, I believe the "core language"
standard should be limited to universally applicable solutions.
Given our accumulated experience, I think that this criteria
should be even more stringent than it was the first time around.
In many cases, a better route would be a standard library.
I sense some reluctance to this concept -- what's the problem?
Command-line arguments were considered in the design of Common Lisp.
I remember raising the related issue of returning values to the
operating system (eg. an "exit status code"), even though my
primary platform (LispM) did not have that concept.
Of course, there are also many more environment-related features
that we could talk about. Unlike command-line arguments, some of
these other things (like network sockets and multiprocessing) have
serious technical implications for the vendors of implementations.
Let's see how far we can get with this fairly trivial one first.
We knew more about command-line arguments back then than most
programmers do today. Here are some things that we know today
about command-line arguments and ANSI Common Lisp:
1. The lack of these features in the language hasn;t stopped
anybody from writing Common Lisp programs in the past
couple of decades, and did even stop a newbie last week.
People even write portable programs that do this.
2. Some people would like a standard interface for this.
I don't know of anybody who disagrees, although some
people feel that it does not need to part of the core
language defined by the ANSI standard.
3. There are many different ways they are specified.
Without specifying something vastly grander, the key
and value objects would be necessarily platform-dependant
and therefore unspecified in nature.
4. Commond-line arguments were arguably more important on
those older systems 20-30 years ago, and are still used
sometimes on major systems today. They are increasingly
inapplicable to even more modern platforms: GUI-based
workstations and portable computers, mobile phones and
other "embedded" computers, robots, network-oriented
applications (HTTP/XML/SOAP services, agents), etc.
5. Standard libraries for ANSI Common Lisp have been very
successful recently, with lots of user contributions
and vendor cooperation.
Let's have people propose exactly what they would like for
a command-line API, in the form of a portable reference
implementation. The result can be proposed as a standard
library that we might adopt.
> There are certainly other functions that are in the standard that are
> not really applicable to all potential platforms. Certain embedded
> processors don't have file systems, but that wouldn't be a good argument
> for not including file system operations in the CL standard.
>
> In fact, I think that the lack of a DIRECTORY-P predicate for pathnames
> is a real weakness of the standard. It makes it impossible to write a
> portable file system traversal within standard Common Lisp.
I very much agree that The file/pathname system is a serious wart
in ANSI Common Lisp, because it is so incomplete and underspecified
as to be worse than useless.
It is an illustration of the problems with adding such features to
the language. Although The pathname and file system features was
an entirely and beautifully solved technical issue at the time,
the politics did not allow for its inclusion in the standard.
Instead, we got a pile of insufficient crap adopted in its place.
Whether including these features in the core language should be
considered to have been a misttake is a question that is loaded.
The reality is, the legacy of this is that to really be able to
fully portable ANSI Common Lisp programs that use the file system,
users have had to implement their own multi-platform libraries.
Some people have written more, and some less, and there is no
standard library that everyone uses.
So I don't see file/pathname system features as a positive
recommendation of why command-line arguments ought to be part
of the ANSI language standard.
(I feel as though everything I've said in this message is
just the same old song that I've been singing over and over,
but perhaps I've was using too much shorthand and not getting
my points across.)
cheers,
Chris
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uvfco3mkz.fsf@news.dtpq.com>
···@sevak.isi.edu (Thomas A. Russ) writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > M Jared Finder <·····@hpalace.com> writes:
> > > However, just because something is easy to write, doesn't mean that it
> > > shouldn't be in a standard library. NTH is easy to write, but it
> > > still is in the standard library.
> >
> > NTH is applicable to all platforms where Common Lisp ran in the past,
> > runs today, and will run in the future; but the same cannot be
> > said for a command-line interface (even for just "today").
> > That's why it's not there; this has been explained several times.
>
> I can understand the general philosophy of this, but it seems that
> perhaps some sort of interface to "program parameters" would not be a
> bad thing to have in the language. On platforms without a command line
> interface, one could imagine that vendors could create a different way
> of specifying and supplying such parameters.
>
> Presumably such an interface might take the form of an ALIST or
> other structure which associates keys with values.
While I believe that there are some things that could be improved
in the standard, it cannot be underestimated that adopting a feature
into the ANSI Common Lisp standard is a very problematic venture.
The political, technical, and financial implications are enormous.
I don't think that most people comprehend what it means to invoke
the ANSI mechanism. Because of that, and for longevity and quality,
I believe the "core language" standard should be limited to universally
applicable solutions. Given our accumulated experience,
I think that this criteria should be even more stringent
than it was the first time around.
In many cases, a better route would be a standard library.
I sense some reluctance to this concept -- what's the problem?
Command-line arguments were considered in the design of Common Lisp.
I remember raising the related issue of returning values to the
operating system (eg. an "exit status code"), even though my
primary platform (LispM) did not have that concept.
Of course, there are also many more environment-related features
that we could talk about. Unlike command-line arguments, some of
these other things (like network sockets and multiprocessing) have
serious technical implications for the vendors of implementations.
Let's see how far we can get with this fairly trivial one first.
We knew more about command-line arguments back then than most
programmers do today. Here are some things that we know today
about command-line arguments and ANSI Common Lisp:
1. The lack of these features in the language hasn't stopped
anybody from writing Common Lisp programs in the past couple
of decades, and did not even stop a newbie last week.
People even write portable programs that do this.
2. Some people would like a standard interface for this.
I don't know of anybody who disagrees, although some
people feel that it does not need to part of the core
language defined by the ANSI standard.
3. There are many different ways they are specified.
Without specifying something vastly grander, the key
and value objects would be necessarily platform-dependant
and therefore unspecified in nature.
4. Commond-line arguments were arguably more important on
those older systems 20-30 years ago, and are still used
sometimes on major systems today. They are increasingly
inapplicable to even more modern platforms: GUI-based
workstations and portable computers, mobile phones and
other "embedded" computers, robots, network-oriented
applications (HTTP/XML/SOAP services, agents), etc.
5. Standard libraries for ANSI Common Lisp have been very
successful recently, with lots of user contributions
and vendor cooperation.
Let's have people propose exactly what they would like for
a command-line API, in the form of a portable reference
implementation. The result can be proposed as a standard
library that we might adopt.
> There are certainly other functions that are in the standard that are
> not really applicable to all potential platforms. Certain embedded
> processors don't have file systems, but that wouldn't be a good argument
> for not including file system operations in the CL standard.
>
> In fact, I think that the lack of a DIRECTORY-P predicate for pathnames
> is a real weakness of the standard. It makes it impossible to write a
> portable file system traversal within standard Common Lisp.
I very much agree that The file/pathname system is a serious wart
in ANSI Common Lisp, because it is so incomplete and underspecified
as to be worse than useless.
It is an illustration of the problems with adding such features to
the language. Although The pathname and file system features was
an entirely and beautifully solved technical issue at the time,
the politics did not allow for its inclusion in the standard.
Instead, we got a pile of insufficient crap adopted in its place.
Whether including these features in the core language should be
considered to have been a misttake is a question that is loaded.
The reality is, the legacy of this is that to really be able to
fully portable ANSI Common Lisp programs that use the file system,
users have had to implement their own multi-platform libraries.
Some people have written more, and some less, and there is no
standard library that everyone uses.
So I don't see file/pathname system features as a positive
recommendation of why command-line arguments ought to be part
of the ANSI language standard.
(I feel as though everything I've said in this message is
just the same old song that I've been singing over and over,
but perhaps I've was using too much shorthand and not getting
my points across.)
cheers,
Chris
······@news.dtpq.com (Christopher C. Stacy) writes:
> Whether including these features in the core language should be
> considered to have been a misttake is a question that is loaded.
> The reality is, the legacy of this is that to really be able to
> fully portable ANSI Common Lisp programs that use the file system,
> users have had to implement their own multi-platform libraries.
> Some people have written more, and some less, and there is no
> standard library that everyone uses.
Despite the formal questions posed by all the OPs, the problem is not
that there is no Common-Lisp universal standard to get the
command-line arguments (or a universal standard for pathnames, etc).
The problem is that there is no standard for all implementations on
ONE (or the other) OS.
It's very well that on MacOS or PalmOS or in GSM phones, there's no
command-line to provide arguments. Good. We can't have a universal
standard, and we don't need one.
But what's really irritating is that there is no Common-Lisp
substandard to get command-line arguments on POSIX. POSIX defines
command-line arguments and all program written in C on POSIX system,
whatever the implementation of the POSIX C compiler, can get the
command line argument in the same way. Why can't the implementors of
Common-Lisp on POSIX system provide us with a common API?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <u1xfcej54.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > Whether including these features in the core language [...]
> But what's really irritating is that there is no Common-Lisp
> substandard to get command-line arguments on POSIX. POSIX defines
> command-line arguments and all program written in C on POSIX system,
> whatever the implementation of the POSIX C compiler, can get the
> command line argument in the same way. Why can't the implementors of
> Common-Lisp on POSIX system provide us with a common API?
Obviously they can, but perhaps they obviously do not consider
this a serious demand from the market. Why don't people who are
"really irritated" about this help themselves?
······@news.dtpq.com (Christopher C. Stacy) writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > ······@news.dtpq.com (Christopher C. Stacy) writes:
> > > Whether including these features in the core language [...]
>
> > But what's really irritating is that there is no Common-Lisp
> > substandard to get command-line arguments on POSIX. POSIX defines
> > command-line arguments and all program written in C on POSIX system,
> > whatever the implementation of the POSIX C compiler, can get the
> > command line argument in the same way. Why can't the implementors of
> > Common-Lisp on POSIX system provide us with a common API?
>
> Obviously they can, but perhaps they obviously do not consider
> this a serious demand from the market. Why don't people who are
> "really irritated" about this help themselves?
They've started, but they have to pay the bills too...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
* Pascal Bourguignon wrote:
> Despite the formal questions posed by all the OPs, the problem is not
> that there is no Common-Lisp universal standard to get the
> command-line arguments (or a universal standard for pathnames, etc).
> The problem is that there is no standard for all implementations on
> ONE (or the other) OS.
I think the problem you're missing is that although it is a lot
cheaper to define some `substandard' than it is to invoke the whole
ANSI mechanism (almost anything is cheaper and less painful than that:
I know this from experience!) it is still far from free. We've seen a
lot of such substandards recently such as system definition things
(ASDF &c), threads standards (apparently several...) and so on, which
is good. But it is still really a lot of work to write up something
in a way that can be used, do one or more sample implementations, deal
with comments and so on, deal with fractious programmers and so on.
As an example, I have what I think is a fairly nice command-line
handling system. It lets you do a reasonable subset of what (say)
perl's long options stuff will do, including unique prefixes,
automatic help and so on. It's been used in anger. But:
* It has no documentation at all, so I'd have to write that;
* It has omissions and oddnesses, so I'd have to fill those in;
* The existing implementation only runs on one implementation
(LispWorks), so I'd have to define a downwards API (all it
actually needs is a list of command line arguments from the
implementation) so it could be ported;
* The existing implementation relies on facilities that exist in
the large system of which it's a part: I'd have to extract those
or possibly reimplement them.
So, I could do all this, and provide a document and a sample
implementation of it which should be portable to pretty much any CL.
May be it would take me a couple of weeks (maybe more now as it's well
over a year since I looked at any of it). But where do I get two
weeks? Where does anyone get two weeks? I can't just decide not to
do my job for two weeks, and I don't really fancy sacrificing my
holidays. And I'm not particularly unusual.
--tim
On Tue, 02 Nov 2004 12:58:25 +0000, Tim Bradshaw wrote:
> As an example, I have what I think is a fairly nice command-line
> handling system. It lets you do a reasonable subset of what (say)
> perl's long options stuff will do, including unique prefixes,
> automatic help and so on. It's been used in anger. But:
>
> * It has no documentation at all, so I'd have to write that;
> * It has omissions and oddnesses, so I'd have to fill those in;
> * The existing implementation only runs on one implementation
> (LispWorks), so I'd have to define a downwards API (all it
> actually needs is a list of command line arguments from the
> implementation) so it could be ported;
> * The existing implementation relies on facilities that exist in
> the large system of which it's a part: I'd have to extract those
> or possibly reimplement them.
Hi,
I'm currently writing a library which provides a scripting environment for
Common Lisp.
Among other things, one of its main features is a command line option
parser. I'm currently finishing up the syntax for specifying options and
arguments.
I intend to release it under BSD license when it's finished. And I'd be
very pleased if you could let me see your code. I want to learn what
others do the stuff.
Let me present examples to show you what it's like.
A simple script.
---
#!/usr/bin/env kashinkoji
;; -*- mode: Lisp; -*-
(destructuring-bind ((&key |a| |b| |c| &allow-other-keys) &rest arguments)
(script:parse-arguments '(:options ("a" "b" "c")
:arguments (("integer" :type integer) . *)))
(when |a|
;; do something for -a option.
)
(when |b|
;; do something for -b option.
)
(when |c|
;; do something for -c option.
))
;; script body
---
A complex script
---
#!/usr/bin/env kashinkoji
;; -*- mode: Lisp; -*-
(require "script")
(in-package "script")
(defscript skeleton (options &rest arguments)
:version "$Revision: 1.3 $"
:date "$Date: 2004/10/18 05:02:35 $"
:author "Yuji Minejima"
:options ("a"
"b"
("number" :alias "n" :argument (:optional-p t :type integer))
("verbose" :alias "V" :repeatable-p t)
("version" :processor #'print-version)
("help" :processor #'print-usage))
:option-bundling-p nil
:arguments ("file" . *)
"document"
;; style 1: use keyword arguments mechanism.
(destructuring-bind (&key |a| |b| &allow-other-keys) options
(when |a|
)
(when |b|
))
;; style 2: iterate options.
(loop for (option value) on options by #'cddr
do (case option
(:|number| )
(:|verbose| )
(t nil)))
(format t "hello world!~%")
;; script body
)
(quit (run))
;;; skeleton ends here
---
I intend to implement the following features for command line options.
* Both short and long options are supported.
* Users can declare a lisp type of option arguments and script arguments.
* Messages for --help and --version can be automatically generated.
* other relevant stuff of Perl's Getopt::Long.
Other stuff which are already implementated or planned to be implemented.
* script:load loads a script just like cl:load but ignores the
she-bang line (e.g. #!/bin/lisp) and script:run function just returns
without executing the script proper.
* script:require first tries to load (asdf:operate 'asdf:load-op "module")
before delegating the job to cl:require.
* ...
Any comments are welcome.
Yuji.
* Yuji Minejima wrote:
> Hi,
> I'm currently writing a library which provides a scripting environment for
> Common Lisp.
> Among other things, one of its main features is a command line option
> parser. I'm currently finishing up the syntax for specifying options and
> arguments.
> I intend to release it under BSD license when it's finished. And I'd be
> very pleased if you could let me see your code. I want to learn what
> others do the stuff.
It's not open source, sorry. (I'm not making some political point
here - I'd like to make this stuff available but it would have to be
extracted from the guts of the package of which it was part which
would be painful.) I will try and dig out some usage examples though.
--tim
On Thu, 04 Nov 2004 08:46:02 +0000, Tim Bradshaw wrote:
> It's not open source, sorry. (I'm not making some political point
> here - I'd like to make this stuff available but it would have to be
> extracted from the guts of the package of which it was part which
> would be painful.) I will try and dig out some usage examples though.
Oh, I seem to have jumped to a hasty conclusion that it's open
source, sorry. Usage examples are definitely very interesting.
I'll notify c.l.l as an informal RFC when some working code is done,
before writing documentation.
Regards,
Yuji.
Pascal Bourguignon escreveu:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>>Whether including these features in the core language should be
>>considered to have been a misttake is a question that is loaded.
>>The reality is, the legacy of this is that to really be able to
>>fully portable ANSI Common Lisp programs that use the file system,
>>users have had to implement their own multi-platform libraries.
>>Some people have written more, and some less, and there is no
>>standard library that everyone uses.
>
>
> Despite the formal questions posed by all the OPs, the problem is not
> that there is no Common-Lisp universal standard to get the
> command-line arguments (or a universal standard for pathnames, etc).
>
> The problem is that there is no standard for all implementations on
> ONE (or the other) OS.
>
> It's very well that on MacOS or PalmOS or in GSM phones, there's no
> command-line to provide arguments. Good. We can't have a universal
> standard, and we don't need one.
>
> But what's really irritating is that there is no Common-Lisp
> substandard to get command-line arguments on POSIX. POSIX defines
> command-line arguments and all program written in C on POSIX system,
> whatever the implementation of the POSIX C compiler, can get the
> command line argument in the same way. Why can't the implementors of
> Common-Lisp on POSIX system provide us with a common API?
>
FFI does not rescue us in this topic?
Cesar Rabak <······@acm.org> writes:
> > But what's really irritating is that there is no Common-Lisp
> > substandard to get command-line arguments on POSIX.
> FFI does not rescue us in this topic?
What's really irritating is that there is no Common-Lisp substandards
for FFI with C, FFI with Fortran, FFI with ADA, etc.
Instead, you have clisp FFI, cmucl aliens, SBCL sb-aliens, openmcl FFI, etc.
Yes, I know UFFI: it only proves my point:
- UFFI does not and cannot support ALL Common-Lisp implementations,
- any random new or old Common-Lisp implementation has not standard
on which to base its FFI, so it's always reinventing the wheel,
and users must spend their time to patch UFFI instead of developing
on their applications.
--
__Pascal Bourguignon__
Pascal Bourguignon escreveu:
> Cesar Rabak <······@acm.org> writes:
>
>>>But what's really irritating is that there is no Common-Lisp
>>>substandard to get command-line arguments on POSIX.
>>
>>FFI does not rescue us in this topic?
>
>
> What's really irritating is that there is no Common-Lisp substandards
> for FFI with C, FFI with Fortran, FFI with ADA, etc.
People you're getting irritated very often lateley ;-)
Methinks the reason of this state of affairs is the difficulty an
encompassing (meaning here the implementations) substandard would be to
come with if the required tradeoffs where to be considered, specified
and finally the substandard put in use.
>
> Instead, you have clisp FFI, cmucl aliens, SBCL sb-aliens, openmcl FFI, etc.
>
> Yes, I know UFFI: it only proves my point:
>
> - UFFI does not and cannot support ALL Common-Lisp implementations,
OK. Can we agree in another way of seeing it on an optimistic side?
Majority of, or perhaps includes the most used, etc.?
>
> - any random new or old Common-Lisp implementation has not standard
> on which to base its FFI, so it's always reinventing the wheel,
> and users must spend their time to patch UFFI instead of developing
> on their applications.
Yes this is an issue, but it would be the case for any standard,
wouldn't it?
--
Cesar Rabak
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <upt2q1uwp.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> - UFFI does not and cannot support ALL Common-Lisp implementations,
Which implementations could not be supported?
······@news.dtpq.com (Christopher C. Stacy) writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
> > - UFFI does not and cannot support ALL Common-Lisp implementations,
>
> Which implementations could not be supported?
- those that are not one of these:
* AllegroCL v6.2 and v7.0 (Linux x86, AMD64, PPC, and Microsoft Windows�
* Lispworks v4.3 (Linux and Microsoft Windows�)
* CMUCL v19a (Linux)
* SBCL 0.8.13 (Linux)
* SCL 1.1 (Linux)
* OpenMCL 0.14.1 (Debian GNU/Linux PowerPC, Mac OS X)
* MCL is partially supported (Macintosh)
(I wrote CANNOT, not COULD NOT).
- those that don't provide a FFI.
- those for which there are no developer interested in patching the
exisitng UFFI or writting a new implementation of the UFFI API.
- those implementations that run on a system where there is no other
language, or where the native ABI is that of lisp.
- use your imagination!
--
__Pascal Bourguignon__
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <ur7n6w9v6.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> > > - UFFI does not and cannot support ALL Common-Lisp implementations,
> >
> > Which implementations could not be supported?
>
> - those that are not one of these:
> * AllegroCL v6.2 and v7.0 (Linux x86, AMD64, PPC, and Microsoft Windows�
> * Lispworks v4.3 (Linux and Microsoft Windows�)
> * CMUCL v19a (Linux)
> * SBCL 0.8.13 (Linux)
> * SCL 1.1 (Linux)
> * OpenMCL 0.14.1 (Debian GNU/Linux PowerPC, Mac OS X)
> * MCL is partially supported (Macintosh)
> (I wrote CANNOT, not COULD NOT).
>
> - those that don't provide a FFI.
I think "can not support" means "it is currently impossible to port
UFFI to this platform", and "could not" means " never will be possible".
But maybe what are trying to say is that UFFI is currently only supported
by a limited set of implementations.
My first observation is, that according to the set you have supplied,
UFFI happens to be supported by every existing ANSI Common Lisp
implementation I've ever heard of, except CLISP.
I don't know of any reason why CLISP could never support UFFI, but
the vendor does not feel that their customers are demanding this.
(In this case, since it's "free software", the "vendor" is the same
as the "customer", so it's a sort of a tautology that if they felt
it was worth it to have this, they would just do it.)
Not every library will be applicable to every implementation, because
not every library makes sense. This is just one of many reasons why
someoen would prefer one Lisp platform over another.
I think this shows that UFFI is a good example of a standard library.
······@news.dtpq.com (Christopher C. Stacy) writes:
> I don't know of any reason why CLISP could never support UFFI, but
There was some discussion about this in the CLISP mailing list. It
looks like there are technical issue, but I can't remember the
details.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
* Christopher C Stacy wrote:
> I think "can not support" means "it is currently impossible to port
> UFFI to this platform", and "could not" means " never will be possible".
> But maybe what are trying to say is that UFFI is currently only supported
> by a limited set of implementations.
Yes, I think that's how I would read this. At least, I would say `does
not' for `currently has not been ported to ...'
--tim
I wrote:
> - UFFI does not and cannot support ALL Common-Lisp implementations,
······@news.dtpq.com (Christopher C. Stacy) writes:
> I think "can not support" means "it is currently impossible to port
> UFFI to this platform", and "could not" means " never will be possible".
> But maybe what are trying to say is that UFFI is currently only supported
> by a limited set of implementations.
You seem to restrict the notion of possibility on only a technical
point of view. I wrote "cannot" because while technically it would be
possible to port UFFI to some more platforms, financially, humanely,
and timely it's not. Otherwise it would have been done already.
> Not every library will be applicable to every implementation, because
> not every library makes sense. This is just one of many reasons why
> someoen would prefer one Lisp platform over another.
I'd agree if we were discussing implementation, but I think we're
discussing Common-Lisp and its lack of complementary standards.
> I think this shows that UFFI is a good example of a standard library.
It's not standard in as much that implementers don't use its API as
their native FFI API.
--
__Pascal Bourguignon__
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uekj5cc7c.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> I wrote:
> > - UFFI does not and cannot support ALL Common-Lisp implementations,
>
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > I think "can not support" means "it is currently impossible to port
> > UFFI to this platform", and "could not" means " never will be possible".
> > But maybe what are trying to say is that UFFI is currently only supported
> > by a limited set of implementations.
>
> You seem to restrict the notion of possibility on only a technical
> point of view. I wrote "cannot" because while technically it would be
> possible to port UFFI to some more platforms, financially, humanely,
> and timely it's not. Otherwise it would have been done already.
>
>
> > Not every library will be applicable to every implementation, because
> > not every library makes sense. This is just one of many reasons why
> > someoen would prefer one Lisp platform over another.
>
> I'd agree if we were discussing implementation, but I think we're
> discussing Common-Lisp and its lack of complementary standards.
It sounds like we have a fundamental disagreement about what these
"standards" are. I believe that they are optional libraries that
people may wish to use, and they are "standard" in the sense that
they are widely available across many implementations, popularly
accepted, and easy to locate.
I get the impression that you think that "standards" are some magical
way of demanding features from vendors without having to pay for them.
> > I think this shows that UFFI is a good example of a standard library.
>
> It's not standard in as much that implementers don't
> use its API as their native FFI API.
I don't see what that has to do with it, because that is not the
functional purpose of this particular standard. It's purpose is
to allow users to write portable foreign function calls.
(Your complaint is also true of all of ANSI Common Lisp itself,
by the way: mostly, ANSI Common Lisp.is not implemented in
ANSI Common Lisp, nor even defined in terms of itself,)
······@news.dtpq.com (Christopher C. Stacy) writes:
> > > Not every library will be applicable to every implementation, because
> > > not every library makes sense. This is just one of many reasons why
> > > someoen would prefer one Lisp platform over another.
> >
> > I'd agree if we were discussing implementation, but I think we're
> > discussing Common-Lisp and its lack of complementary standards.
>
> It sounds like we have a fundamental disagreement about what these
> "standards" are. I believe that they are optional libraries that
> people may wish to use, and they are "standard" in the sense that
> they are widely available across many implementations, popularly
> accepted, and easy to locate.
Yes, nice trick to change the definition of the words during an argument...
> I get the impression that you think that "standards" are some magical
> way of demanding features from vendors without having to pay for them.
Yes, that falls into the financial part of the "cannot". If I was as
rich as Bill Gate I could finance all the Common-Lisp implementers, do
they provide free or commercial implementations, to implement all the
same API for FFI, Sockets, Processes, etc. But I'm not.
> > > I think this shows that UFFI is a good example of a standard library.
> >
> > It's not standard in as much that implementers don't
> > use its API as their native FFI API.
>
> I don't see what that has to do with it, because that is not the
> functional purpose of this particular standard. It's purpose is
> to allow users to write portable foreign function calls.
Good. By your rules, gcc is a _standard_ Common-Lisp implementation,
as well as Microfocus COBOL or awk. After all, they only need a
library implementing the Common-Lisp API to be as standard as any
Common-Lisp implementation.
> (Your complaint is also true of all of ANSI Common Lisp itself,
> by the way: mostly, ANSI Common Lisp.is not implemented in
> ANSI Common Lisp, nor even defined in terms of itself,)
No, it has nothing to do with what language Common-Lisp is
implemented. You're confused.
--
__Pascal Bourguignon__
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uwtwx7y65.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > > > Not every library will be applicable to every implementation, because
> > > > not every library makes sense. This is just one of many reasons why
> > > > someoen would prefer one Lisp platform over another.
> > >
> > > I'd agree if we were discussing implementation, but I think we're
> > > discussing Common-Lisp and its lack of complementary standards.
> >
> > It sounds like we have a fundamental disagreement about what these
> > "standards" are. I believe that they are optional libraries that
> > people may wish to use, and they are "standard" in the sense that
> > they are widely available across many implementations, popularly
> > accepted, and easy to locate.
>
> Yes, nice trick to change the definition of the words during an argument...
I originally thought everybody understood the definition here.
(As far as I can tell, you're the only one who understood
something different.)
At this point, I have no idea what you want.
(I'we also lost interest.)
······@news.dtpq.com (Christopher C. Stacy) writes:
[Many cogent arguments snipped]
> 2. Some people would like a standard interface for this.
> I don't know of anybody who disagrees, although some
> people feel that it does not need to part of the core
> language defined by the ANSI standard.
> 5. Standard libraries for ANSI Common Lisp have been very
> successful recently, with lots of user contributions
> and vendor cooperation.
>
> Let's have people propose exactly what they would like for
> a command-line API, in the form of a portable reference
> implementation. The result can be proposed as a standard
> library that we might adopt.
OK, I'm convinced that this is a better route to go.
Thanks for the more in-depth explanation.
--
Thomas A. Russ, USC/Information Sciences Institute
> * Christopher C. Stacy <······@arjf.qgcd.pbz> [2004-11-02 04:28:36 +0000]:
>
> Let's have people propose exactly what they would like for a
> command-line API, in the form of a portable reference implementation.
> The result can be proposed as a standard library that we might adopt.
CLOCC/bin/run-lisp implements a common interface:
Usage:
run-lisp [clause ...] [argument ...]
clause ::= -i file ; load file `file'
| -c file ; compile file `file'
| -x form ; execute form `form'
| -I image ; use image file `image'
| -d image ; dump to image `image'
| --safety n ; set safety level for compilation
| --speed n ; set speed level for compilation
Note: Lisp specific extensions (e.g. .dxl on ACL or .mem for CLISP)
are not to be included into the image argument
Anything else is stuffed into the Lisp variable 'argv', which is
available in the lexical environment forms given to -x are
evaluated in.
run-lisp -run image
interactively run `image'
(user:run) will be called upon start up.
Makefile support
run-lisp -faslext
echo the fasload file extension to stdout.
This is useful for Makefile; you could then say e.g.
FAS:=$(shell $(TOP)/bin/run-lisp -faslext)
run-lisp -dumpext
echo the memory image extension _with_ dot.
usage: (like above)
DUMP:=$(shell $(TOP)/bin/run-lisp -dumpext)
run-lisp -cat [fasl-file ...]
Cat all the given fasl files together.
EXAMPLE
$ run-lisp -x "(print argv)" foo bar baz "Hallo Welt" foo\"bar
("foo" "bar" "baz" "Hallo Welt" "foo\"bar")
$
it supports the following lisps:
# clisp uses ${CLISP} if set, else "clisp"
# cmucl uses ${CMUCL} if set, else "lisp"
# acl43 uses ${ACL43} if set, else "cl"
# acl5 uses ${ACL5} if set, else "cl"
# gcl uses ${GCL} if set, else "gcl"
# sbcl uses ${SBCL} if set, else "sbcl"
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
What's the difference between Apathy & Ignorance? -I don't know and don't care!
······@news.dtpq.com (Christopher C. Stacy) writes:
> Command-line arguments were considered in the design of Common Lisp.
> I remember raising the related issue of returning values to the
> operating system (eg. an "exit status code"), even though my
> primary platform (LispM) did not have that concept.
And providing a standard way of doing either of these would be a lie to
the user. The actual data involved is in no way consistent from one
platform to the next. An exit code of 15 could mean one thing on one
platform and another thing on another platform. Also, "/w" as a
command-line parameter means one thing on one platform and a hugely
different one on another platform, just looking at OSes in common use
today.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
M Jared Finder <·····@hpalace.com> writes:
> Really? Window's command line seems awfully Unix like:
But then: Can't you count e.g. TOPS-20, VMS (the grandfather of NT), CP/M
(the grandfather of Windows 9x) in as "awfully unix like" as well?
--
(espen)
······@news.dtpq.com (Christopher C. Stacy) writes:
> I understand the original proposed problem to be that the ANSI Common
> Lisp language standard does not define a standard function that returns
> a string corresponding to the command-line typed in by the user.
I'm not sure that any of the implementations actually give the whole
command line. I think they give a subset of the command line removing
the options that are provided to the implementation itself, at least for
some implementations.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
······@news.dtpq.com (Christopher C. Stacy) writes:
> My feeling is that if someone is unable to figure out how to design
> and write two or three lines of code to implement the standard,
> something like this:
>
> (defun standard-get-the-command-line ()
> (implementation-specific:get-the-command-line))
>
> then they should not be trying to write computer programs.
Are you speaking about the implementors or about the application developers?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uvfcr5pvb.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > My feeling is that if someone is unable to figure out how to design
> > and write two or three lines of code to implement the standard,
> > something like this:
> >
> > (defun standard-get-the-command-line ()
> > (implementation-specific:get-the-command-line))
> >
> > then they should not be trying to write computer programs.
>
> Are you speaking about the implementors or about the application developers?
Your question does not make sense to me in the context of the discussion.
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <upt2zlgiu.fsf@news.dtpq.com>
M Jared Finder <·····@hpalace.com> writes:
> Christopher C. Stacy wrote:
> > Rahul Jain <·····@nyct.net> writes:
> >>M Jared Finder <·····@hpalace.com> writes:
> >>
> >>
> >>>So why does Lisp provide support for files but not for command line
> >>>arguments?
> >>
> >>You need a command line arg parser that's appropriate
> >>for the host OS's conventions.
> > Gee, isn't everything Unix, and isn't that the same as DOS?
> > :)
>
> While I know that that statement was in jest, it seems that all modern
> operating systems either have Unix style commandlines, or have no
> concept of the command line at all. What operating systems exist at
> the moment that aren't Unix like and have a command line?
Why doesn't someone write up the three or four line program that
they are bitching about, which would provide a standard API on top
of each implementation's function that returns the command line?
This whole discussion seems like so much idiotic trolling...
······@news.dtpq.com (Christopher C. Stacy) writes:
> Why doesn't someone write up the three or four line program that
> they are bitching about, which would provide a standard API on top
> of each implementation's function that returns the command line?
It's not a three or four line program, because you need to take into
account the platform's syntax for command line options. In DOS/Windows,
they're prefixed with a slash and are a single character optionally
followed by a colon and a specification of the value for that option. In
Unix applications, they're either a hyphen followed by a single letter
and then the rest of the option or the next option could be the value if
that option is specified to have a value or two hyphens followed by a
hyphen-separated option name and optionally an equals sign followed by
the value of the option. I couldn't even describe the specification for
the syntax in three or four lines, let alone the way that these options
need to be specified.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
······@news.dtpq.com (Christopher C. Stacy) writes:
> Why doesn't someone write up the three or four line program that
> they are bitching about, which would provide a standard API on top
> of each implementation's function that returns the command line?
>
> This whole discussion seems like so much idiotic trolling...
What was the point of Common-Lisp to begin with? We were quite happy
with MACLISP, INTERLISP, LeLisp, emacs lisp, etc...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <ur7nf5puu.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > Why doesn't someone write up the three or four line program that
> > they are bitching about, which would provide a standard API on top
> > of each implementation's function that returns the command line?
> >
> > This whole discussion seems like so much idiotic trolling...
>
> What was the point of Common-Lisp to begin with? We were quite happy
> with MACLISP, INTERLISP, LeLisp, emacs lisp, etc...
This seems like a non-sequitor in the context of the discussion.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Why doesn't someone write up the three or four line program that
> they are bitching about, which would provide a standard API on top
> of each implementation's function that returns the command line?
I suspect the question was rhetorical, and the answer you're looking
for is: because they'd quite rapidly find out that a reasonably
general-purpose wrapper turned out to embody a buttload of
implementation-specific knowledge and require a lot more than four
lines.
At least, that's been my experience with opening a socket.
-dan
--
"please make sure that the person is your friend before you confirm"
From: Christopher C. Stacy
Subject: Re: Running Standalone Lisp Programs
Date:
Message-ID: <uekjf56o5.fsf@news.dtpq.com>
Daniel Barlow <···@telent.net> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > Why doesn't someone write up the three or four line program that
> > they are bitching about, which would provide a standard API on top
> > of each implementation's function that returns the command line?
>
> I suspect the question was rhetorical, and the answer you're looking
> for is: because they'd quite rapidly find out that a reasonably
> general-purpose wrapper turned out to embody a buttload of
> implementation-specific knowledge and require a lot more than four
> lines.
>
> At least, that's been my experience with opening a socket.
Dealing with a socket is a lot more complicated than returning
a string that someone handed you.
In article <···············@uni-berlin.de>,
M Jared Finder <·····@hpalace.com> wrote:
> Christopher C. Stacy wrote:
> > Rahul Jain <·····@nyct.net> writes:
> >>M Jared Finder <·····@hpalace.com> writes:
> >>
> >>
> >>>So why does Lisp provide support for files but not for command line
> >>>arguments?
> >>
> >>You need a command line arg parser that's appropriate
> >>for the host OS's conventions.
> >
> > Gee, isn't everything Unix, and isn't that the same as DOS?
> > :)
>
> While I know that that statement was in jest, it seems that all modern
> operating systems either have Unix style commandlines, or have no
> concept of the command line at all. What operating systems exist at the
> moment that aren't Unix like and have a command line?
>
> -- MJF
Cisco IOS.
······@news.dtpq.com (Christopher C. Stacy) writes:
> The Lisp Machine had the fanciest command-line parser, ever.
> It was based on the functionality of the TOPS-20 command-line,
> but it was object-oriented and based on presentations.
I should have guessed. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
> * Philip Haddad <·············@tznvy.pbz> [2004-10-23 16:40:27 -0700]:
>
> 1) Is there any way that a Lisp program can be compiled and saved like
> an .exe file in C++?
you might be talking about "application delivery" here.
Different CL implementations do it differently.
Here is the CLISP way:
<http://clisp.cons.org/impnotes/quickstart.html>
> 2) Is there and import or #include statement in Lisp? I hear that
> defpackage is similar to #include, but I'm not sure.
I think LOAD or REQUIRE is more like #include.
YMMV
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Lottery is a tax on statistics ignorants. MS is a tax on computer-idiots.
Sam Steingold wrote:
>>* Philip Haddad <·············@tznvy.pbz> [2004-10-23 16:40:27 -0700]:
>>
>>1) Is there any way that a Lisp program can be compiled and saved like
>>an .exe file in C++?
>
>
> you might be talking about "application delivery" here.
> Different CL implementations do it differently.
> Here is the CLISP way:
> <http://clisp.cons.org/impnotes/quickstart.html>
>
Is there any way of making a executable which doesn't need "clisp" or
some interpreter support? A binary.
-Surendra Singhi
On Mon, 01 Nov 2004 23:52:01 -0700, surendra <·········@netscape.net> wrote:
> Is there any way of making a executable which doesn't need "clisp"
> or some interpreter support? A binary.
Have you read the rest of this thread? The general answer is yes, you
can do it but it depends on the Lisp implementation. For the CLISP
implementation the answer is currently no (like you can't deploy a
Java executable without the Java runtime library).
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Mon, 01 Nov 2004 23:52:01 -0700, surendra <·········@netscape.net> wrote:
>
>> Is there any way of making a executable which doesn't need "clisp"
>> or some interpreter support? A binary.
>
> Have you read the rest of this thread? The general answer is yes, you
> can do it but it depends on the Lisp implementation. For the CLISP
> implementation the answer is currently no (like you can't deploy a
> Java executable without the Java runtime library).
And before he objects that C++ can, it can't. You need the C++ runtime
to run a C++ application... unless you statically link it in. But you
could have just shipped your own version of it and provided a wrapper
script to make sure that the linker uses that version instead of the one
that's installed where the linker is configured to look by default...
but you can do that with a lisp runtime, too.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist