A little problem...
Ray
When I use (nameofpakage:nameoffun) after load the whole pakage use (load
"mainfilename"),it says
*** - READ from
#<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM>
#<IO SYNONYM-STREAM *DEBUG-IO*>>: there is no package with name
"DIAGRAMS"
But I really have diagrams.lisp and there is no error when I load the
module load it or enening load diagram itself.
Following is the whole input and output:
------------------------------------------------------------------------
D:\Transfer\ai\clisp\bin>lisp -M lispinit.mem -B d:\transfer\ai\clisp\bin
\
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2001
[1]> (load "loading")
;; Loading file D:\Transfer\ai\clisp\bin\loading.fas ...
;; Loading of file D:\Transfer\ai\clisp\bin\loading.fas is finished.
T
[2]> (diagrams:standard-poly)
*** - READ from
#<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM>
#<IO SYNONYM-STREAM *TERMINAL-IO*>>: there is no package with name
"DIAGRAMS"
1. Break [3]> (load "diagrams.lisp)
*** - SYSTEM::STRING-READER: Ctrl-C: User break
2. Break [4]> (load "diagrams")
;; Loading file D:\Transfer\ai\clisp\bin\diagrams.lisp ...
;; Loading of file D:\Transfer\ai\clisp\bin\diagrams.lisp is finished.
T
2. Break [4]> (diagrams:standard-poly)
*** - READ from
#<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM>
#<IO SYNONYM-STREAM *DEBUG-IO*>>: there is no package with name
"DIAGRAMS"
3. Break [5]> (loading:standard-poly)
*** - READ from
#<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM>
#<IO SYNONYM-STREAM *DEBUG-IO*>>: there is no package with name
"LOADING"
4. Break [6]> (gde:standard-poly)
*** - READ from
#<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM>
#<IO SYNONYM-STREAM *DEBUG-IO*>>: there is no package with name "GDE"
5. Break [7]>
Joe Marshall
"Ray" <hyr...@163.com> wrote in message news:Xns9245751DAC3...@202.108.36.140...
> I encounter a little problem while run a lisp code.
> When I use (nameofpakage:nameoffun) after load the whole pakage use (load
> "mainfilename"),it says
>
> *** - READ from
> #<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM>
> #<IO SYNONYM-STREAM *DEBUG-IO*>>: there is no package with name
> "DIAGRAMS"
>
> But I really have diagrams.lisp and there is no error when I load the
> module load it or enening load diagram itself.
It isn't possible to tell what you are expecting from the transcript
you provided because the file `loading' could have anything in it.
However, it *appears* as if you expect that loading a file will
create a package with the same name as the file.
The package system has nothing to do with the file system.
Loading a file called `diagrams' will not in and of itself create
a package called "DIAGRAMS". There has to be specific code to
create the package within the file.
Ray
news:1P7W8.271251$R61.1...@rwcrnsc52.ops.asp.att.net:
Yup.The package name is not same with file name.
I saw
;-*- Mode: LISP; Syntax: Common-lisp; Package: USER-*-
in some of the source file.
And some also have this line (in-package :COMMON-LISP-USER).
It didnot return error of "there is no package with name... ".
But it says "#<PACKAGE COMMON-LISP-USER> has no external symbol with name
"STANDARD-POLY",other function defined in source code also get this
error.
It is really not easy to handle lisp.
I know lisp is a function language.It is also different from other
language with respect the compliing and runing.
Can somebody answer some question of me?
Does the process I do is correct?(load in the main file,and use
(modulename:function) to run it?)
Does the source code contain only one modulename?
Does we can run any function in files?
Joe Marshall
"Ray" <hyr...@163.com> wrote in message news:Xns92458033F76...@202.108.36.140...
>
> Yup.The package name is not same with file name.
> I saw
> ;-*- Mode: LISP; Syntax: Common-lisp; Package: USER-*-
> in some of the source file.
This line tells the Emacs editor how to handle the file.
Lisp does not use it at all.
> And some also have this line (in-package :COMMON-LISP-USER).
Good. This indicates that the rest of the file will be read
in the "COMMON-LISP-USER" package. It is generally a good idea
to have an IN-PACKAGE form at the beginning of every file.
> It did not return error of "there is no package with name... ".
The "COMMON-LISP-USER" package is built in.
> But it says "#<PACKAGE COMMON-LISP-USER> has no external symbol with name
> "STANDARD-POLY", other functions defined in source code also get this
> error.
This is probably because you are using the package prefix.
If the package is "COMMON-LISP-USER", then you ought to be able to
just use the symbol "STANDARD-POLY" at the prompt without having to
type COMMON-LISP-USER:STANDARD-POLY
> It is really not easy to handle lisp.
You'll get the hang of it in no time.
> I know lisp is a function language. It is also different from other
> language with respect the compliing and running.
You'll come to appreciate this.
> Can somebody answer some question of me?
> Does the process I do is correct?(load in the main file,and use
> (modulename:function) to run it?)
> Does the source code contain only one modulename?
> Does we can run any function in files?
You can always refer to any interned symbol by its `fully qualified' name.
This would be the name of the symbol preceeded by the name of the
package and TWO colons. For instance, suppose that there were a function
called RUN-ME in the FOO package, and it took a single integer argument.
You could type this at the prompt:
(foo::run-me 42)
Symbols can be `exported'. If a symbol is exported, then you can access
it with a single colon. (Exporting does more than this, but let's keep
it simple for now.)
(foo:run-me 42)
If the `current package' at the top level prompt is the "FOO" package,
then you don't need the package qualifier at all:
(run-me 42)
You could always type (foo::run-me 42) no matter what the current
package is or no matter whether run-me is exported.
Ray
Thanks for your help.It do work now!
And I have another question,Does lisp have interface with other language
like vc?
eg.prolog have a logic server can use under vc.
Joe Marshall
"Ray" <hyr...@163.com> wrote in message news:Xns9245E346F12...@202.108.36.140...
It would depend on the implementation, but many lisps provide a
`foreign function' interface.
Ray
I found 'foreign function' in allegro CL.It seems that this feature
is that call other language library like dll in lisp.Now the code
I got is what do fundemental work so I want call these function in
more powerful language(not refer logic relate) like vc.
The logic server in prolog can reach these goal.
Aleksandr Skobelev
[...]
> I found 'foreign function' in allegro CL.It seems that this feature
> is that call other language library like dll in lisp.Now the code
> I got is what do fundemental work so I want call these function in
> more powerful language(not refer logic relate) like vc.
I've never heard before about vc. What is a kind of a language?
[...]
Andreas Hinze
about a powerful language ;-)
Best
AHz
Ray
Yup.VC is VisualC++.
What I mean is use common language to call lisp.
As lisp is strong at logic and reasoning so it's a good language for AI.
But lisp is not good at other aspects although there are some visual lisp
now.
For some system to get better interface and human interaction common
language like C++ is better.
So I want use C++ at upper level and lisp at bottom(under) level.
Anyone know prolog can refer logic server of prolog,same purpose.
Andreas Hinze
>
> What I mean is use common language to call lisp.
> As lisp is strong at logic and reasoning so it's a good language for AI.
> But lisp is not good at other aspects although there are some visual lisp
> now.
do you ?
> For some system to get better interface and human interaction common
> language like C++ is better.
I agree that there are task that one don't want to write in lisp. But these
are typically absolute low-level tasks like device drivers and such stuff.
But i can hardly imagine any higher level task that is better implemented in
C++ than in lisp. And that specially holds for human interaction. But maybe
you can give some examples ?
> So I want use C++ at upper level and lisp at bottom(under) level.
I'm new to lisp so i don't know every detail but all what i have learned until
now would lead to an exact opposite direction (when there is a need for C at all).
Best
AHz
Aleksandr Skobelev
[...]
> Yup.VC is VisualC++.
> What I mean is use common language to call lisp.
> As lisp is strong at logic and reasoning so it's a good language for AI.
> But lisp is not good at other aspects although there are some visual lisp
> now.
> For some system to get better interface and human interaction common
> language like C++ is better.
> So I want use C++ at upper level and lisp at bottom(under) level.
> Anyone know prolog can refer logic server of prolog,same purpose.
Well, Visual C++ is not a language. It is a realization of C++, that is a
language. Somewhere this realization is not very good. (Sometimes it makes
me snarl.) :(
Lisp is a language. And there are realizations of this language. There
are realizations (as a rule these are commercial products) which allow
you to create DLLs that can be used with your favourite realization of
C++. But this is still not a very common feature.
So I think it is much more easy (and has much more sence) to use C/C++
from Lisp. Lisp is a language which is on more high level than C++. And
Lisp is definitely good at many other domains but not only in AI.
Aleksandr Skobelev
So do I. But for Ray wrote neither about a realization of C++ nor
about IDE, I decided that I had missed something. :)
Joe Marshall
"Ray" <hyr...@163.com> wrote in message news:Xns924671EE94A...@202.108.36.140...
So you want to create a `foreign-callable' lisp function.
Since you are working in VC++, I'm guessing that Unix compatability
is low on your priority list. You should look at Corman Common Lisp.
It can be loaded as a COM server into your C++ image and called from
C++.
Joel Ray Holveck
>> I saw
>> ;-*- Mode: LISP; Syntax: Common-lisp; Package: USER-*-
>> in some of the source file.
> This line tells the Emacs editor how to handle the file.
> Lisp does not use it at all.
Actually, it doesn't even tell most Emacs editors anything. It's used
by Zmacs (Emacs on the lispm), and by Xanalys's Lisp, but GNU Emacs
only uses the "Mode:" line... ilisp looks for the IN-PACKAGE form.
I don't know of anything other than Symbolics that uses the Syntax:
declaration.
joelh
Rainer Joswig
MCL's "Fred" uses mode lines, too. c-m-shift-M is Add-Modeline,
c-m-m is Reparse-Modeline.
You can also declare packages with some added info
in the mode line:
;;;-*- Syntax: Ansi-Common-Lisp; Base: 10; Mode: lisp; Package:
(cl-http-menu use (common-lisp ccl)) -*-
That way the editor can create the package (knowing which other
packages to use) when opening the file, in case the package is
not already present in the running Lisp.
Christopher C. Stacy
Rainer> In article <y7cznww...@sindri.juniper.net>,
Rainer> Joel Ray Holveck <jo...@juniper.net> wrote:
>> >> Yup.The package name is not same with file name.
>> >> I saw
>> >> ;-*- Mode: LISP; Syntax: Common-lisp; Package: USER-*-
>> >> in some of the source file.
>> > This line tells the Emacs editor how to handle the file.
>> > Lisp does not use it at all.
>>
>> Actually, it doesn't even tell most Emacs editors anything. It's used
>> by Zmacs (Emacs on the lispm), and by Xanalys's Lisp, but GNU Emacs
>> only uses the "Mode:" line... ilisp looks for the IN-PACKAGE form.
>>
>> I don't know of anything other than Symbolics that uses the Syntax:
>> declaration.
>>
>> joelh
Rainer> MCL's "Fred" uses mode lines, too. c-m-shift-M is Add-Modeline,
Rainer> c-m-m is Reparse-Modeline.
Rainer> You can also declare packages with some added info
Rainer> in the mode line:
Rainer> ;;;-*- Syntax: Ansi-Common-Lisp; Base: 10; Mode: lisp; Package:
Rainer> (cl-http-menu use (common-lisp ccl)) -*-
Rainer> That way the editor can create the package (knowing which other
Rainer> packages to use) when opening the file, in case the package is
Rainer> not already present in the running Lisp.
Emacs has always used those attribute lists specified at the top
of the file, at least as far back as the original implementation
in MIT TECO in the late 1970s.
That's not properly called the "Mode Line", though. The mode line
is the dynamic display line at the bottom of the Emacs window that
tells you what current modes are in effect (and whether the buffer
is dirty, the buffer name, percentage of point through the file,
and maybe the line number you're on, mode-specific junk, etc.)
On ITS (the orignal PDP-10 operating system that EMACS ran on),
and of course also on the Lisp Machine, there was also a "Who Line".
This is another dynamic line at the bottom of the entire screen that
is managed by the operating system, displaying system status information
such as the Run/Disk Wait/Paging/GC "run lights", IO state (Net/TYI/TYO),
IO progress bars, current open filename, date/time, current package,
and other general system and programmable status information.
The line at the top of a file that looks like: -*- Lisp -*-
is called the "Attribute List", although Emacs originally didn't
have a name for it and just always referred to it with the phrase
"first non-blank line". Since the original and primary function
of this line is to specify the editing mode (ie. inform the editor
that the file contains source code in a particular language),
it's easy to to see why sometimes people mistakenly said "Mode Line".
Anyway, the Lisp Machine version of Emacs supported this also.
When packages were invented, and as time went on, multiple Lisp
dialects appeared on the Lisp Machine, the Zmacs attribute list
was extended to accomodate those features. After a file was
read in, you could adjust the relevent buffer modes by using
the command "m-x Reparse Attribute List". Or, you could
adjust the buffer independant of the attribute list with
commands like "m-x Set Package". Then you could also use
the command "m-x Update Attribute List" to update it.
The original attribute lists just looked like
(for a MIDAS assembler source file):
-*-MIDAS-*-
When more attributes were put on there, it became:
-*- Mode: Midas -*-
The combination of Mode, Syntax, and Package, together specified a dialect of Lisp.
(With Zetalisp, Common Lisp, and ANSI Common Lisp all coexisting on the same system,
I seem to remember that there was some confusing complications with the attribute lists
at first, and that Kent had a hand in straightening out the meanings.)
The attribute list was also not only by the editor,
but also by the compiler when reading source files.
Originally, there was no IN-PACKAGE function in Lisp;
the "Package:" attribute is what you used to get that effect.
ANSI Common Lisp took that functionality from the operating
environment, and put it into the language itself as IN-PACKAGE.
Here's an attribute list for a typical Zetalisp source file that is
part of the implementation of the Zmacs (ZWEI) editor:
;;; -*- Mode: LISP; Syntax: Zetalisp; Package: ZWEI; Base: 10 -*-
Examples of some of the attributes that could appear on the Zmacs:
Mode: Lisp
Syntax: ANSI-Common-Lisp
Package: (COMPOSITOR :use zl)
Base: 10
Patch-File: Yes
Version-Control: Yes
Lowercase: T
Backspace: No
Tab-Width: 8
NoFill: Yes
Diagram: No
Default-character-style: (:FIX :ROMAN :NORMAL)
VSP: 2
Fonts: CPTFONT,CPTFONTCB
Any editing mode could be defined to put other junk in the
attribute list, although I don't recall seeing much else.
The various languages added other things specific to them.
C had "Search-List", "Export", and "Predefined-Include-Search-List.
Pascal had "Dialect:" either "ISO" or "VS", and "Using:" (program units).
Emacs adopted the both the -*- Lisp -*-
and the new style -*- Mode: Lisp -*-
attribute lines at the top of the file, and uses the
local modes list ("Local Variables") at the bottom of the file.
Emacs never understood any attributes up there other than "Mode".
In EMACS (both the TECO and GNU) there were also buffer variables
that could be set by some lines at the bottom of the file, much like
the attribute lists at the top of the file. These attributes
control the actions of editor commands such as "Compile Buffer",
and can also set other variables such as the fill column.
These are called the "local modes list" or the "local variables list".
As I recall, the Lisp Machine didn't support the local modes list at all.
When reading in a source file, Zmacs wanted to parse the file as it
reading it in, and it already had the fancy attribute list up top,
which was enough to see what language it was supposed to be and
what package to intern things in. The local modes list section at
the bottom of the file in EMACS allowed the possibility of more
customizations and a nicer looking format with multiple lines,
but the ZMACS guys just didn't care for it or see the need.
When GNU Emacs came along, it used a different header to signify
the start of the local modes list; this was needed back when both
operating systems were around. You couldn't have GNU Emacs trying
to evaluate TECO commands; also, when you were specifying a command
to be given the operating system (such as "makealiases" or "gcc")
you wanted different strings for the different operating systems
even if the same file was sometimes hacked on both systems.
This is why "Local modes:" turned into "Local variables:".
All these versions of Emacs also guess the mode/language from the filename.
So a file called "foo.lisp" is assumed to be a Lisp source file to be
editied in "Lisp" mode, unless the attribute list says otherwise.
Chris