Hi,
When working through Lisp tutorials, I get frustrated because I can't
write any useful programs. None of the tutorials show me how to do I/O
in the console, or with files. After a lot of searching, all I have
found so far is (write-string "Hello, World"). I'm stuck with
evaluating one-liners inside emacs.
Does ACL have a standard library with I/O functions, file I/O, and the
bare necessities to do stuff that I could do in C or C++, or any other
language?
For instance, I'd really like to write web server applications in Lisp.
I'd love to develop mod_lisp for apache, where I can write web
services as well as have control over server internals with Lisp.
Can Lisp do network programming? What about system level programming?
Can I access kernel system calls with Lisp?
Finally, is there a decent Lisp tutorial anywhere that shows me how to
write useful programs in Lisp and use its standard library (if it has one?!)
Thanks!
Johnathan
Johnathan Doe <·············@fastmail.com.au> writes:
> When working through Lisp tutorials, I get frustrated because I can't
> write any useful programs. None of the tutorials show me how to do
> I/O in the console, or with files. After a lot of searching, all I
> have found so far is (write-string "Hello, World"). I'm stuck with
> evaluating one-liners inside emacs.
Which tutorials are these? In any case, assuming that by Lisp you
mean Common Lisp, there is a chapter in Peter Seibel's upcoming book,
Practical Common Lisp, all about Files and File I/O. You can read the
work in progress at <http://www.gigamonkeys.com/book/> -- be sure to
send him feedback, particularly if there are things that are unclear.
> Does ACL have a standard library with I/O functions, file I/O, and the
> bare necessities to do stuff that I could do in C or C++, or any other
> language?
In addition to the standardized operators in Lisp (which are not
necessarily terribly close to Operating System-level primitives),
typically an implementation will provide lower-level bindings: I
believe ACL has an Operating System Interface (search in their
documentation); SBCL certainly has bindings to POSIX, and so on.
> For instance, I'd really like to write web server applications in
> Lisp. I'd love to develop mod_lisp for apache, where I can write web
> services as well as have control over server internals with Lisp.
>
> Can Lisp do network programming? What about system level programming?
> Can I access kernel system calls with Lisp?
Before you start developing, you should at least familiarize yourself
with the various solutions out there: start at
<http://www.cliki.net/Web> (and be aware that the page you get is
served up by a Lisp webserver interacting with apache).
> Finally, is there a decent Lisp tutorial anywhere that shows me how to
> write useful programs in Lisp and use its standard library (if it has
> one?!)
I know it's fairly passé these days, but I strongly recommend reading
a real live paper book: probably the one that's closest to your needs
(excluding Peter Seibel's, which isn't available yet) is Peter
Norvig's _Paradigms of Artificial Intelligence Programming_. Find it
in a library, or buy it -- and don't let the AI slant put you off;
it's a fine book about programming, and about Common Lisp.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@cam.ac.uk>...
> Johnathan Doe <·············@fastmail.com.au> writes:
>
> > When working through Lisp tutorials, I get frustrated because I can't
> > write any useful programs. None of the tutorials show me how to do
> > I/O in the console, or with files. After a lot of searching, all I
> > have found so far is (write-string "Hello, World"). I'm stuck with
> > evaluating one-liners inside emacs.
>
> Which tutorials are these? In any case, assuming that by Lisp you
> mean Common Lisp, there is a chapter in Peter Seibel's upcoming book,
> Practical Common Lisp, all about Files and File I/O. You can read the
> work in progress at <http://www.gigamonkeys.com/book/> -- be sure to
> send him feedback, particularly if there are things that are unclear.
Yes, Peter's book is great. I strongly suggest you read this section:
http://www.gigamonkeys.com/book/files-and-file-io.html
It helped me with many of my IO questions. Also look up write-file and
read along with format in the CLHS.
> > Does ACL have a standard library with I/O functions, file I/O, and the
> > bare necessities to do stuff that I could do in C or C++, or any other
> > language?
>
> In addition to the standardized operators in Lisp (which are not
> necessarily terribly close to Operating System-level primitives),
> typically an implementation will provide lower-level bindings: I
> believe ACL has an Operating System Interface (search in their
> documentation); SBCL certainly has bindings to POSIX, and so on.
Of course it does. You have to relieze though, that most people on
c.l.l use a Open Source Lisp. I use CMUCL myself. There are plenty of
IO operations included in CL itself so as I said before, check the
HyperSpec. What OS are you looking to develop on? I have a hunch it's
Windows :-( If you still are going with ACL, if you paid for it there
should be documentation, so read it. If you got the trial edition or
warez, then good luck.
> > For instance, I'd really like to write web server applications in
> > Lisp. I'd love to develop mod_lisp for apache, where I can write web
> > services as well as have control over server internals with Lisp.
Isn't there something already out there like this?
Ah, a few momments with google returned this:
http://www.fractalconcept.com/asp/RgV4/sdataQ1cDRxUhc055DM==/sdataQuqh-N3qe0jUC1B=
> > Can Lisp do network programming? What about system level programming?
> > Can I access kernel system calls with Lisp?
>
> Before you start developing, you should at least familiarize yourself
> with the various solutions out there: start at
> <http://www.cliki.net/Web> (and be aware that the page you get is
> served up by a Lisp webserver interacting with apache).
Yes, it can. I'm only familer with cl-irc under CMUCL, but CMUCL
supports a whole extensions package that will let you do a whole bunch
of networking stuff. See the docs by Mario Mommer here:
http://common-lisp.net/project/cmucl/doc/cmu-user/internet.html
> > Finally, is there a decent Lisp tutorial anywhere that shows me how to
> > write useful programs in Lisp and use its standard library (if it has
> > one?!)
>
> I know it's fairly passé these days, but I strongly recommend reading
> a real live paper book: probably the one that's closest to your needs
> (excluding Peter Seibel's, which isn't available yet) is Peter
> Norvig's _Paradigms of Artificial Intelligence Programming_. Find it
> in a library, or buy it -- and don't let the AI slant put you off;
> it's a fine book about programming, and about Common Lisp.
CL is a standerd library of Lisp. I think it's safe to say that no?
Common Lisp, meaning it's universal. Lisp doesn't really have librarys
like C++ or anything, it just provides everything you need, if it
doesn't have it you can write in right into the language itself with
macros etc. In the meantime, there are many packages to help.
I agree with Christophe, get a real book. Nothing will help you more.
I recommend "Common Lisp Programming for Arificial Intelligence", as
it was my first text. Also "On Lisp" and "ANSI Common Lisp" both by
Paul Graham are excellent. You may want to wait on "On Lisp" until you
have read some other books first though ;-)
> Christophe
--
May the Source be with you.
neo88 (Philip Haddad)
neo88 wrote:
> You have to relieze though, that most people on c.l.l use a Open
> Source Lisp.
I don't think so. I think it's closer to 50%. And several people
actually use both open source and commercial implementations.
> If you still are going with ACL, if you paid for it there should be
> documentation, so read it. If you got the trial edition, then good
> luck.
The trial edition of Allegro also provides documentation.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
"neo88" <······@truevine.net> wrote in message
·································@posting.google.com...
> CL is a standerd library of Lisp. I think it's safe to say that no?
Common Lisp is a dialect of Lisp. Around here I'd say the defalt meaning of
Lisp, sans context, is Common Lisp. Common Lisp is its own complete
language as specified by an ANSI standard.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Coby Beck wrote:
> "neo88" <······@truevine.net> wrote in message
> ·································@posting.google.com...
>
>>CL is a standerd library of Lisp. I think it's safe to say that no?
>
>
> Common Lisp is a dialect of Lisp. Around here I'd say the defalt meaning of
> Lisp, sans context, is Common Lisp. Common Lisp is its own complete
> language as specified by an ANSI standard.
I've seen a lot of people use it that way, but to me "Lisp" refers
to a whole family of languages, taking in Common Lisp, Scheme, Autolisp,
elisp, MacLisp, forthcoming Lisps like Arc, et cetera.... It's not so
much the name of a language as the name of a language design space.
So of course I stifle a laugh whenever I see a parochial statement
that indicates the speaker's lisp universe is limited to only one
dialect.
Of course, my first Lisp was Scheme, so maybe I've just got a different
view of things.
CL is not a standard library; CL is a Lisp that has a lot of
standard library functions built in. But the "library" of
functions isn't portable between Common Lisp implementations,
let alone to different dialects of lisp.
My major gripe with Lisp Libraries for interacting with OS functions
is that, to the extent that they depend on bindings to operating
system functions below the level of the standard of the Lisp in
question (which happens a lot in Common Lisp and is almost universal
in Scheme), they are not portable between implementations of the
language. For example, the Common Lisp and scheme standards are
silent on socket IO and interactions with the TCP/IP stack. But
every implementation of Common Lisp and most implementations of
Scheme provide bindings that allow you to work with them. They may
be named different things or have subtly different semantics, but
they're there.
And the code that makes the low-level bindings available in a given
Common Lisp isn't portable between implementations of CL, and there's
no way to build a library that makes some low-level binding portable
(and consistent) between implementations of CL, and this usually
means any library code that uses such a binding isn't portable
across implementations of CL. Implementing the same functionality
for different implementations of the same Lisp requires a lot of
parallel effort.
I don't know if this can easily be "fixed" -- it would require a common
ABI for Lisps at a much lower level than is customary to provide. But
it's a pet peeve.
Bear
On Sun, Aug 29, 2004 at 05:16:33PM +0000, Ray Dillinger wrote:
> CL is not a standard library; CL is a Lisp that has a lot of
> standard library functions built in. But the "library" of
> functions isn't portable between Common Lisp implementations,
> let alone to different dialects of lisp.
What are you talking about? This is the whole point of Common Lisp,
that the standard functions are portable between implementations.
> My major gripe with Lisp Libraries for interacting with OS functions
> is that, to the extent that they depend on bindings to operating
> system functions below the level of the standard of the Lisp in
> question (which happens a lot in Common Lisp and is almost universal
> in Scheme), they are not portable between implementations of the
> language. For example, the Common Lisp and scheme standards are
> silent on socket IO and interactions with the TCP/IP stack. But
> every implementation of Common Lisp and most implementations of
> Scheme provide bindings that allow you to work with them. They may
> be named different things or have subtly different semantics, but
> they're there.
Of course CL and Scheme standards are silent about very OS dependent
issues like ``sockets'' (which is just ONE model of a network API).
They are trying to define UNIVERSAL languages, not UNIX languages.
Providing ``socket'' support is the job of libraries, of which there
exists plenty for CL. C programmers are in the same situation, but how
often do you hear them whining about ``sockets'' not being in the
standard? They just use the libraries they have.
> And the code that makes the low-level bindings available in a given
> Common Lisp isn't portable between implementations of CL, and there's
> no way to build a library that makes some low-level binding portable
> (and consistent) between implementations of CL, and this usually
What hole have you been living in for the past 3 years? Plenty of
useful work has been done with UFFI, even though it is not perfect.
Please, stop saying things about Common Lisp that you really mean about
Scheme.
> I don't know if this can easily be "fixed" -- it would require a common
> ABI for Lisps at a much lower level than is customary to provide. But
> it's a pet peeve.
This has nothing to do with ``custom.'' Providing the same low-level
ABI everywhere is something that even C doesn't do.
--
;;;; Matthew Danish -- user: mrd domain: cmu.edu
;;;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish wrote:
> On Sun, Aug 29, 2004 at 05:16:33PM +0000, Ray Dillinger wrote:
>>CL is not a standard library; CL is a Lisp that has a lot of
>>standard library functions built in. But the "library" of
>>functions isn't portable between Common Lisp implementations,
>>let alone to different dialects of lisp.
> What are you talking about? This is the whole point of Common Lisp,
> that the standard functions are portable between implementations.
I am talking about the implementation of those functions, not
about particular usages. You are right that using them can
be done in portable code. Implementing them cannot. If,
for example, implementation A's character set is limited to
sixteen-bit, I can't swap out some code for primitive functions
and swap in implementation B's 21-bit character handling code.
As long as you're only using functions that the standard
specifies, your code is portable. And the Common Lisp
standard does a *LOT* more than most others. Still, let's
say I want something that's simple, but outside the standard,
such as cursor control on a character-based interface (the
"curses" library in UNIX).
This requires operating system calls, and therefore cannot
be implemented using the functions given in the standard.
If I write it using machine code, there's no portable way
to write a wrapper for my machine code so that it will work
in more than one Lisp implementation, even on the same OS
and architecture where the machine code works.
By contrast, C implementations in practice have a stack
discipline and data representation that is so simple and
uniform, an implementation of something in machine code
is usually directly portable across different C compilers,
or requires a few simple redeclarations at most.
By the way, don't give me that crap about "universal
language" - The "universal language" is only good for
gazing at its own navel. Even PRINC makes assumptions
about the OS and capabilities. Languages that *DO*
things have to have ways to call operating system functions.
A language standard that doesn't standardize a network
communications library, a graphics library, and a keyboard
and mouse input handling library is not "universal" -
it's "obsolete and needs fixing."
Sure, some platforms won't have the underlying functionality,
and the functions, when called, should return an error value
to signify that they're not available. The standard libraries
in C have minimum specifications for situations where they're
not available; most of them return signal values that say
nothing happened. So you can provide these stubs for library
functions if you're writing for the elevator controller or a
crippled OS, and the library standard should say what the
stubs do if it's not possible to do their normal job. The
benefit of that is that on OS's and platforms where the
functionality *is* available, there is a well-defined standard
way for it to work.
Bear
>>>>> On Mon, 30 Aug 2004 02:21:23 GMT, Ray Dillinger ("Ray") writes:
Ray> Matthew Danish wrote:
>> On Sun, Aug 29, 2004 at 05:16:33PM +0000, Ray Dillinger wrote:
>>> CL is not a standard library; CL is a Lisp that has a lot of
>>> standard library functions built in. But the "library" of
>>> functions isn't portable between Common Lisp implementations,
>>> let alone to different dialects of lisp.
>> What are you talking about? This is the whole point of Common Lisp,
>> that the standard functions are portable between implementations.
Ray> I am talking about the implementation of those functions
That has absolutely nothing to do with whether user-written source
code is portable across Common Lisp implementations. When people
around here say "portable", they are referring to Lisp source code.
They are not referring to the fact that an object file for an Intel
processor will not also execute on a Macintosh. (There is nothing
to suggest that the newbie was thinking of this either, yet your
response was to claim that Common Lisp is not "portable".)
The newbie was asking whether I/O functions such as FORMAT
and WRITE-BYTE existed, and whether they were portable.
Ray> If, for example, implementation A's character set is limited to
Ray> sixteen-bit, I can't swap out some code for primitive functions
Ray> and swap in implementation B's 21-bit character handling code.
Common Lisp provides an abstract data type called a CHARACTER,
which is not a numeric code. When the programmer writes a
character to an output stream, he does not need to worry about
the binary representation of that character. The result will
be the letter A, whether Common Lisp is exeucting on an ASCII
system or a UNICODE system or an EBCDIC system or whatever.
Ray> As long as you're only using functions that the standard
Ray> specifies, your code is portable. And the Common Lisp
Ray> standard does a *LOT* more than most others.
At last, the truth. Why couldn't you just say that at first?
Ray> Still, let's say I want something that's simple, but outside
Ray> the standard, such as cursor control on a character-based
Ray> interface (the "curses" library in UNIX).
Then you do the same thing you would do in C, which is to link
in the curses library and call its functions.
Besides the ANSI standard, there are additional portable libraries.
One of those libraries is called "Universal Foreign Function Call",
which allows one to write portable code to do effect the linking
and calling of foreign libraries, such as curses.
An good example of UFFI is something that's not so simple: a nice
interface to SQL databases. A portable Lisp library called CL-SQL
has been implemented that does this (on top of portable UFFI library).
Ray> By the way, don't give me that crap about "universal
Ray> language" - The "universal language" is only good for
Ray> gazing at its own navel.
I didn't say anything about a "universal language".
I gave you crap for being disingenuous, obtuse, misleading,
giving newbies completely wrong information, and I questioned
your motives.
Ray> Sure, some platforms won't have the underlying functionality,
Ray> and the functions, when called, should return an error value
Ray> to signify that they're not available. The standard libraries
Ray> in C have minimum specifications for situations where they're
Ray> not available; most of them return signal values that say
Ray> nothing happened.
Your use of the phrase "signal values" with respect to C functions
is confusing here. The kind of C libraries that I believe you are
talking about generally return an integer values indicating failures,
and the programmer is expected to check for those after every function call.
Then if you detect one, you usually call a standard library function
that will map the error code to an error string or something.
C programs suffer from the fact that this kind of programming is tedious,
error-prone, and thus often ignored or botched by programmers,
and it makes the programer harder to read.
Common Lisp provides a much more sophisticated mechanism for signalling
and handling exceptional situations. This subject is well addressed by
Kent Pitman's paper, "Condition Handling in the Lisp Language Family".
http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
Ray> So you can provide these stubs for library functions if you're
Ray> writing for the elevator controller or a crippled OS, and the
Ray> library standard should say what the stubs do if it's not
Ray> possible to do their normal job. The benefit of that is that
Ray> on OS's and platforms where the functionality *is* available,
Ray> there is a well-defined standard way for it to work.
ANSI C has a standard library for elevator controllers?
And C compilers guarantee binary compatability across architectures, too?
Common Lisp doesn't define those.
Just what are you smoking?
Christopher C. Stacy wrote:
>>>>>>On Mon, 30 Aug 2004 02:21:23 GMT, Ray Dillinger ("Ray") writes:
> Ray> If, for example, implementation A's character set is limited to
> Ray> sixteen-bit, I can't swap out some code for primitive functions
> Ray> and swap in implementation B's 21-bit character handling code.
>
> Common Lisp provides an abstract data type called a CHARACTER,
> which is not a numeric code. When the programmer writes a
> character to an output stream, he does not need to worry about
> the binary representation of that character. The result will
> be the letter A, whether Common Lisp is exeucting on an ASCII
> system or a UNICODE system or an EBCDIC system or whatever.
In today's world, a programmer writing a character to a stream
really does have to worry about the binary representation of
that character. Common Lisp implementations usually have
essentially a single binary encoding available, and if you need
to interoperate across a stream to something that talks only
UTF-16LE, UTF-32, or whatever, then either the implementation
has to take care of your conversion and byte order marks and
whatnot, or the programmer does. Free implementations mostly
don't take care of that, though the commercial ones might.
Further, it is not even logically possible for an implementation
to get unicode right, and still be ANSI compliant.
I realize that all this is far off the original topic, but this
is a newly dear subject to me. :)
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
Randall Randall wrote:
> Further, it is not even logically possible for an implementation
> to get unicode right, and still be ANSI compliant.
Bummer. Scheme has the same basic problem, due to assumptions
about case mappings that unicode fails in. What are the issues
in Common Lisp?
Bear
Randall Randall <·······@randallsquared.com> writes:
> In today's world, a programmer writing a character to a stream
> really does have to worry about the binary representation of
> that character. Common Lisp implementations usually have
> essentially a single binary encoding available, and if you need
> to interoperate across a stream to something that talks only
> UTF-16LE, UTF-32, or whatever, then either the implementation
> has to take care of your conversion and byte order marks and
> whatnot, or the programmer does. Free implementations mostly
> don't take care of that, though the commercial ones might.
The :external-format argument to external streams is responsible for
this conversion. You're right that Free (libre)
non-Unicode-supporting lisps currently don't allow very many useful
arguments there, but I speak from certain knowledge that this will
change in the very near term.
> Further, it is not even logically possible for an implementation
> to get unicode right, and still be ANSI compliant.
I'm not sure I believe this, though I'll suspend judgment until I've
heard your reasoning. Partly, of course, it depends on what you mean
by "right": I do not believe, for instance, that source program
symbols should have locale-dependent case mappings: maybe you do.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Randall Randall <·······@randallsquared.com> writes:
>
> The :external-format argument to external streams is responsible for
> this conversion. You're right that Free (libre)
> non-Unicode-supporting lisps currently don't allow very many useful
> arguments there, but I speak from certain knowledge that this will
> change in the very near term.
That would be great! The last thing I'd heard about
on that front was an apparently defunct unicode
implementation for CMUCL.
>>Further, it is not even logically possible for an implementation
>>to get unicode right, and still be ANSI compliant.
>
>
> I'm not sure I believe this, though I'll suspend judgment until I've
> heard your reasoning. Partly, of course, it depends on what you mean
> by "right": I do not believe, for instance, that source program
> symbols should have locale-dependent case mappings: maybe you do.
Well, I do think that being able to use whatever character
set one normally uses is a win for non-US-ASCII users, though
I don't really speak from experience (my keyboard is all mapped
inside US-ASCII).
However, case mappings are dealt with as part of string data,
not just source code, and CL assumes a one-to-one mapping for
upper and lower case characters; "The result only ever differs
from character in its code attribute"[1] seems very clear that
mappings from one case to another can't even produce a character
with a different name (e.g., "LATIN CAPITAL LETTER A" and
"LATIN SMALL LETTER A" cannot be used as character names in a
compliant implementation), much less actually convert into
more than one character at the destination case. Unicode does
have characters that convert into more than one character when
up or down cased... although, having written that, I realize
that's not strictly true: unicode has *code points* that convert
into more than one *code point* when the character that they
are representing is up or down cased. In at least one instance,
two different lowercase code points map to the same uppercase
code point:
lower upper
U+0345 => U+0399
U+03B9 => U+0399
but:
U+03B9 <= U+0399
Perhaps a CL implementation of unicode could handle this by
conflating these characters as all the same CL character.
However, elsewhere: "string-capitalize produces a copy of
string such that, for every word in the copy, the first
character of the ``word,'' if it has case, is uppercase
and any other characters with case in the word are
lowercase."[2]
In unicode, characters can have titlecase, which in characters
that have it produces a different representation for the initial
character of a capitalized word. The different representation
is not (in such characters) the same as uppercase. While I
think it would be surprising to programmers to actually strictly
conform to the spec in this case, it does seem that it's not
possible to conform strictly and implement unicode in a way
that keeps the distinctions between titlecase and uppercase.
While some of the conflicts can be resolved by pretending that
all characters concerned are really just differing character
codes with all the other attributes the same, I don't think that
there's any way to conform to the definition of string-uppercase
in a way that preserves the portability of programs that use it.
Having written all this, I have to belatedly admit that it *is*
probably logically possible to have a ANSI-conforming CL
implementation that also does unicode correctly, but it wouldn't
work the way a developer would expect, and would necessarily
make some of the ANSI functions, like string-capitalize, useless
for general use on strings (since initial uppercase isn't what
you're probably looking for when you use it on a unicode string,
but titlecase: a different thing).
[1]
http://www.lispworks.com/reference/HyperSpec/Body/f_char_u.htm
[2]
http://www.lispworks.com/reference/HyperSpec/Body/f_stg_up.htm#string-capitalize
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
Randall Randall <·······@randallsquared.com> writes:
> Christophe Rhodes wrote:
>> The :external-format argument to external streams is responsible for
>> this conversion. You're right that Free (libre)
>> non-Unicode-supporting lisps currently don't allow very many useful
>> arguments there, but I speak from certain knowledge that this will
>> change in the very near term.
>
> That would be great! The last thing I'd heard about
> on that front was an apparently defunct unicode
> implementation for CMUCL.
OK. A little more detail: there is a CVS branch in sbcl's sourceforge
repository named character_branch. This branch has precisely zero
extra features over HEAD, but it has had a fair amount of
infrastructural work done on it (and is at a resting point where it
needs testing, in case that's of interest to anyone out there: see
<http://article.gmane.org/gmane.lisp.steel-bank.devel/3565> and
<http://www-jcsu.jesus.cam.ac.uk/~csr21/TODO.character> for what I
think needs doing: comments -- to the sbcl-devel list unless they're
of general interest -- are most welcome).
>>>Further, it is not even logically possible for an implementation
>>>to get unicode right, and still be ANSI compliant.
>> I'm not sure I believe this, though I'll suspend judgment until I've
>> heard your reasoning. Partly, of course, it depends on what you mean
>> by "right": I do not believe, for instance, that source program
>> symbols should have locale-dependent case mappings: maybe you do.
>
> Well, I do think that being able to use whatever character
> set one normally uses is a win for non-US-ASCII users, though
> I don't really speak from experience (my keyboard is all mapped
> inside US-ASCII).
In terms of program source code, I think this is not a win. I have
limited use of non-US-ASCII (mostly European languages, including
Greek and Cyrillic): but I don't have any particular desire to include
them in program identifiers.
> However, case mappings are dealt with as part of string data,
> not just source code, and CL assumes a one-to-one mapping for
> upper and lower case characters; "The result only ever differs
> from character in its code attribute"[1] seems very clear that
> mappings from one case to another can't even produce a character
> with a different name (e.g., "LATIN CAPITAL LETTER A" and
> "LATIN SMALL LETTER A" cannot be used as character names in a
> compliant implementation), much less actually convert into
> more than one character at the destination case.
I think the name issue comes from an overstrict reading: I think it's
referring here to implementation-defined attributes (such as the cltl2
"font" and "bits"), not general things one can examine in a character:
otherwise #\a (with name "a") cannot be the char-downcase of #\A (with
name "A")! The many-to-one issue is more serious, but I believe it
can be worked around.
> Unicode does have characters that convert into more than one
> character when up or down cased... although, having written that, I
> realize that's not strictly true: unicode has *code points* that
> convert into more than one *code point* when the character that they
> are representing is up or down cased. In at least one instance, two
> different lowercase code points map to the same uppercase code
> point:
> lower upper
> U+0345 => U+0399
> U+03B9 => U+0399
> but:
> U+03B9 <= U+0399
>
> Perhaps a CL implementation of unicode could handle this by
> conflating these characters as all the same CL character.
Possibly, or how about defining distinct synthetic characters in the
application private use plane to act as the upper case variants of
these lower case characters, and normalizing these synthetic
characters to their real (standard-defined) variants on stream output?
Then the lisp system is internally consistent. Something like this
needs to be done for the 12-or-so ligatures in Unicode, too.
> However, elsewhere: "string-capitalize produces a copy of
> string such that, for every word in the copy, the first
> character of the ``word,'' if it has case, is uppercase
> and any other characters with case in the word are
> lowercase."[2]
> [...]
> Having written all this, I have to belatedly admit that it *is*
> probably logically possible to have a ANSI-conforming CL
> implementation that also does unicode correctly, but it wouldn't
> work the way a developer would expect, and would necessarily
> make some of the ANSI functions, like string-capitalize, useless
> for general use on strings (since initial uppercase isn't what
> you're probably looking for when you use it on a unicode string,
> but titlecase: a different thing).
I think that might be fair enough: it is possible that there is a
slight impedance mismatch. On the other hand, if the
string-capitalize issue is the largest, I'd say that it was no
particular disaster: simply advertise UNICODE:STRING-TITLECASE or
somesuch to act as the Unicode-aware operator, and let ANSI operators
behave as specified.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> Randall Randall <·······@randallsquared.com> writes:
>>That would be great! The last thing I'd heard about
>>on that front was an apparently defunct unicode
>>implementation for CMUCL.
>
> OK. A little more detail: there is a CVS branch in sbcl's sourceforge
> repository named character_branch. This branch has precisely zero
> extra features over HEAD, but it has had a fair amount of
> infrastructural work done on it (and is at a resting point where it
> needs testing, in case that's of interest to anyone out there: see
> <http://article.gmane.org/gmane.lisp.steel-bank.devel/3565> and
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/TODO.character> for what I
> think needs doing: comments -- to the sbcl-devel list unless they're
> of general interest -- are most welcome).
Thanks. I'll be interested in testing when you have
this PPCized (as that's my development machine). I
presume I should follow along on the sbcl-devel list
to find out when that is.
>>Well, I do think that being able to use whatever character
>>set one normally uses is a win for non-US-ASCII users, though
>>I don't really speak from experience (my keyboard is all mapped
>>inside US-ASCII).
>
> In terms of program source code, I think this is not a win. I have
> limited use of non-US-ASCII (mostly European languages, including
> Greek and Cyrillic): but I don't have any particular desire to include
> them in program identifiers.
I'd venture to say that this might be because you don't
typically use lots of non-US-ASCII in everyday typing
anyway. If most of your non-programming typing were in
Greek, it might be more useful for you to use ordinary
Greek names for variables, function names, etc. Anyway,
I think I can agree to disagree with you on this for now. :)
>>However, case mappings are dealt with as part of string data,
>>not just source code, and CL assumes a one-to-one mapping for
>>upper and lower case characters; "The result only ever differs
>>from character in its code attribute"[1] seems very clear that
>>mappings from one case to another can't even produce a character
>>with a different name (e.g., "LATIN CAPITAL LETTER A" and
>>"LATIN SMALL LETTER A" cannot be used as character names in a
>>compliant implementation), much less actually convert into
>>more than one character at the destination case.
>
> I think the name issue comes from an overstrict reading: I think it's
> referring here to implementation-defined attributes (such as the cltl2
> "font" and "bits"), not general things one can examine in a character:
> otherwise #\a (with name "a") cannot be the char-downcase of #\A (with
> name "A")!
Well, "a" is not the ANSI CL name of #\a in any implementation
I've tried it on. Usually the alphanumeric characters have no
names, probably precisely because of this detail, so char-name
produces NIL for every graphic character in the PPC versions of
SBCL and CMUCL, for example. They're both:
(char-name #\a) => NIL
Likewise, in my unicode-handling library, unless *ansi-compliant*
is NIL:
(unicode:char-name (code-char 97)) => NIL
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
Randall Randall <·······@randallsquared.com> wrote:
> anyway. If most of your non-programming typing were in
> Greek, it might be more useful for you to use ordinary
> Greek names for variables, function names, etc. Anyway,
Offtopic, but this is a pet hate, so I'll bite...
My native language is finnish, and so is most of my non-programming
typing, and it is really really disruptive to see code where finnish words
appear as variable names or comments while the builtin function remain
english, as it requires a change of mental gears so to speak. This may
have something to do with the "linguistic distance" between english and
finnish; at least it seems that Germans are quite fond of commenting in
german.
As an additional data-point, at least a few finnish companies have a
policy of "code in english" to eg. allow co-operation with foreign
partners.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
·········@random-state.net writes:
> My native language is finnish, and so is most of my non-programming
> typing, and it is really really disruptive to see code where finnish words
> appear as variable names or comments while the builtin function remain
> english, as it requires a change of mental gears so to speak. This may
> have something to do with the "linguistic distance" between english and
> finnish; at least it seems that Germans are quite fond of commenting in
> german.
Hmmm. Interestingly enough I had a different reaction when doing some
programming work in Germany. I found that the division between language
keywords in one language and programmer-defined names in the other
worked as a kind of linguistic syntax-coloring in the source files.
--
Thomas A. Russ, USC/Information Sciences Institute
·········@random-state.net wrote:
> Randall Randall <·······@randallsquared.com> wrote:
>
>
>>anyway. If most of your non-programming typing were in
>>Greek, it might be more useful for you to use ordinary
>>Greek names for variables, function names, etc. Anyway,
>
>
> Offtopic, but this is a pet hate, so I'll bite...
>
> My native language is finnish, and so is most of my non-programming
> typing, and it is really really disruptive to see code where finnish words
> appear as variable names or comments while the builtin function remain
> english, as it requires a change of mental gears so to speak. This may
> have something to do with the "linguistic distance" between english and
> finnish; at least it seems that Germans are quite fond of commenting in
> german.
Okay. All the feedback I've gotten on this is from
those saying essentially this same thing, so I'll
accept that there's no pressing need for non-ASCII
program text. :)
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
Randall Randall <·······@randallsquared.com> writes:
> Thanks. I'll be interested in testing when you have
> this PPCized (as that's my development machine). I
> presume I should follow along on the sbcl-devel list
> to find out when that is.
For what it's worth, Julian Squires and Patrik Nordebo have between
them ported and tested the work so far to PPC (both Linux and Darwin),
so that time is now. (Or maybe "soon", to allow SourceForge to permit
anonymous people to access the up-to-date CVS repository :-)
> I'd venture to say that this might be because you don't
> typically use lots of non-US-ASCII in everyday typing
> anyway. If most of your non-programming typing were in
> Greek, it might be more useful for you to use ordinary
> Greek names for variables, function names, etc. Anyway,
> I think I can agree to disagree with you on this for now. :)
Possibly. I think even in this case I would (mostly) restrain myself
from this apparent personal utility, particularly in programming,
because typically there is much more collaboration between people of
different native tongues in writing a program than in writing a
document, and in addition the intended audiences are generally very
different. If I write documents in French, whether that is because
it's my native tongue or because I'm addressing those who feel most
comfortable in French, the communication's lingua franca (ahem) is
chosen, not imposed. However, in working with computer languages,
part of the audience -- the compiler -- may be language (as it were)
agnostic, but another part -- the people working on the program --
probably aren't. There's a strong context in programming to be fairly
conservative in usage of character sets, simply because some people,
or some environments, aren't set up to accept the full generality.
I can see one context where it is generally useful to have non-ascii
variable names, however: when transcribing mathematical formulae.
There, the availability of characters with glyphs corresponding
directly to those in references would quite conceivably be a net win
in comprehensibility.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> I can see one context where it is generally useful to have non-ascii
> variable names, however: when transcribing mathematical formulae.
> There, the availability of characters with glyphs corresponding
> directly to those in references would quite conceivably be a net win
> in comprehensibility.
Actually, emacs comes in handy to substitute greek letter names to
greek glyphs on the display.
(defconstant *greek-letters*
'( "alpha" "beta" "gamma" "delta" "epsilon" "zeta" "eta"
"theta" "iota" "kappa" "lambda" "mu" "nu" "xi" "omicron" "pi"
"rho" "terminalsigma" "sigma" "tau"
"upsilon" "phi" "chi" "psi" "omega" )
"The order of these strings is fixed by the encoding of greek-iso8859-7!"
);;*greek-letters*
(defun greek-letter-font-lock ()
"
RETURN: A font-lock-keywords list mapping greek letter names
to greek characters.
"
(let ((maj 64) (min 96))
(mapcan
(lambda (letter)
(incf maj) (incf min)
`(
(,(format "\\([^A-Za-z0-9]\\|^\\)\\(%s\\)\\([^A-Za-z]\\|$\\)"
(upcase letter))
(2 (progn (compose-region (match-beginning 2)
(match-end 2)
,(make-char 'greek-iso8859-7 maj)
'decompose-region)
nil)))
(,(format "\\([^A-Za-z0-9]\\|^\\)\\(%s\\)\\([^A-Za-z]\\|$\\)"
(downcase letter))
(2 (progn (compose-region (match-beginning 2)
(match-end 2)
,(make-char 'greek-iso8859-7 min)
'decompose-region)
nil)))))
*greek-letters*))
);;greek-letter-font-lock
(defun tree-upcase-strings (tree)
(cond
((stringp tree) (string-upcase tree))
((consp tree) (cons (tree-upcase-strings (car tree))
(tree-upcase-strings (cdr tree))))
(t tree))
);;tree-upcase-strings
(defvar pretty-greek t)
(defun pretty-greek ()
"
Show LAMBDA keyword as a greek letter lambda in lisp source code.
(add-hook 'emacs-lisp-mode-hook 'pretty-greek)
(add-hook 'lisp-mode-hook 'pretty-greek)
"
(interactive)
(unless (and (boundp 'pretty-greek) (not pretty-greek))
(setq font-lock-keywords-case-fold-search nil)
(font-lock-add-keywords nil (greek-letter-font-lock))
));;pretty-greek
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Christophe Rhodes <·····@cam.ac.uk> writes:
> Possibly, or how about defining distinct synthetic characters in the
> application private use plane to act as the upper case variants of
> these lower case characters, and normalizing these synthetic
> characters to their real (standard-defined) variants on stream output?
> Then the lisp system is internally consistent. Something like this
> needs to be done for the 12-or-so ligatures in Unicode, too.
Unicode says that "�" uppercases to "SS". Synthetic characters won't
help - it should really be a string of length 2, equal to "SS".
Some case mappings are context-sensitive. Greek capital sigma
lowercases to one of two variants of small sigmas depending on whether
it's a final letter in a word.
There are also a few locale-dependent casings related to the dot over
i's, active in Turkish, Azeri, and Lithuanian.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> Possibly, or how about defining distinct synthetic characters in the
>> application private use plane to act as the upper case variants of
>> these lower case characters, and normalizing these synthetic
>> characters to their real (standard-defined) variants on stream output?
>> Then the lisp system is internally consistent. Something like this
>> needs to be done for the 12-or-so ligatures in Unicode, too.
>
> Unicode says that "�" uppercases to "SS". Synthetic characters won't
> help - it should really be a string of length 2, equal to "SS".
>
> Some case mappings are context-sensitive. Greek capital sigma
> lowercases to one of two variants of small sigmas depending on whether
> it's a final letter in a word.
>
> There are also a few locale-dependent casings related to the dot over
> i's, active in Turkish, Azeri, and Lithuanian.
Right, and furthermore, a Common Lisp implementation does not have
to be trying to "get _Unicode_ right" before it runs into these
issues, since they would arise with a number of 8-bit encodings as
well, such as ISO-8859-*.
But I don't think that what _Common Lisp_ calls a lowercase
character (in the sense of CHAR-DOWNCASE, CHAR-UPCASE, LOWER-CASE-P,
UPPER-CASE-P) _must_ match the grammatical rules of each and every
natural language (or the rules prescribed by a standard such as
Unicode). In other words, if I need to process texts in any
language (or at least a wide range of languages), I would probably
use some library that is specialized for the task (which takes into
account all the language specifics, etc.), and I would expect that
(CHAR-UPCASE #\�) => #\� and that there is a function along the
lines of (UNICODE-UPCASE "�") => "SS".
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
>>>>> On Mon, 30 Aug 2004 03:11:46 -0400, Randall Randall ("Randall") writes:
Randall> Christopher C. Stacy wrote:
>>>>>>> On Mon, 30 Aug 2004 02:21:23 GMT, Ray Dillinger ("Ray") writes:
Ray> If, for example, implementation A's character set is limited to
Ray> sixteen-bit, I can't swap out some code for primitive functions
Ray> and swap in implementation B's 21-bit character handling code.
>> Common Lisp provides an abstract data type called a CHARACTER,
>> which is not a numeric code. When the programmer writes a
>> character to an output stream, he does not need to worry about
>> the binary representation of that character. The result will
>> be the letter A, whether Common Lisp is exeucting on an ASCII
>> system or a UNICODE system or an EBCDIC system or whatever.
Randall> In today's world, a programmer writing a character
Randall> to a stream really does have to worry about the binary
Randall> representation of that character.
I should probably have just stuck with the word "stream" there,
instead of "system"; but your follow-up shows that understand that.
(I think "worry" is rather overstating the case.
I write network code all the time, on multiple platforms
and across different Lisp vendors. This has not been tricky.
I haven't had to use any of the more exotic character
translations, though.)
Also, if you really need something that your implementation
doesn't provide, you can use the (non-ANSI) standard stream
extension protocols.
Randall> Further, it is not even logically possible for an
Randall> implementation to get unicode right, and still be
Randall> ANSI compliant.
I don't know what that means, but I could believe it.
But all this means is that the implementations will deviate
from the 1994 ANSI standard, but quickly converge on a de facto
portable industry standard. If there's market pressure, the ANSI
spec will be updated to include this (along with things like the
stream extensions which everyone already implements). It's worth
noting that an additional round of ANSI standardization has not thus
far been necessary for people to write all manner of portable code.
Randall Randall <·······@randallsquared.com> writes:
> Further, it is not even logically possible for an implementation to
> get unicode right, and still be ANSI compliant.
Why?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Christopher C. Stacy wrote:
> That has absolutely nothing to do with whether user-written source
> code is portable across Common Lisp implementations. When people
> around here say "portable", they are referring to Lisp source code.
> They are not referring to the fact that an object file for an Intel
> processor will not also execute on a Macintosh. (There is nothing
> to suggest that the newbie was thinking of this either, yet your
> response was to claim that Common Lisp is not "portable".)
No, my response was that it's not possible to implement libraries
which call operating system functions and are portable between
implementations of Common Lisp. UFFI may be changing this, but
certainly the language standard provides no way to do it.
> Ray> If, for example, implementation A's character set is limited to
> Ray> sixteen-bit, I can't swap out some code for primitive functions
> Ray> and swap in implementation B's 21-bit character handling code.
>
> Common Lisp provides an abstract data type called a CHARACTER,
> which is not a numeric code.
And which, in most implementations I know of handles only a
subset of unicode and allows no standard way to extend it.
> When the programmer writes a
> character to an output stream, he does not need to worry about
> the binary representation of that character. The result will
> be the letter A, whether Common Lisp is exeucting on an ASCII
> system or a UNICODE system or an EBCDIC system or whatever.
This is simply not true any more. Systems don't stand alone
these days; half or more of what you're writing code for these
days is supposed to communicate over a network. Making an
assumption that there's a dominant encoding on the current
platform and you never have to worry about it is wrong. I
don't want to write an "A" on an EBCDIC machine and have some
random sequence of bits go out to a machine or file format
that's expecting UTF8 or UTF16BE. Standard character I/O
functions have to be redefined in network code in terms of
WRITE-BYTE and READ-BYTE, which means, yes, messing with
numerical codes. I've had to write functions to convert
bit sequences in a dozen different encodings back and forth
to characters.
> Ray> Still, let's say I want something that's simple, but outside
> Ray> the standard, such as cursor control on a character-based
> Ray> interface (the "curses" library in UNIX).
>
> Then you do the same thing you would do in C, which is to link
> in the curses library and call its functions.
Interesting. Nothing in the language standard talks about
how to link in C libraries. You're talking about an
implementation-dependent extension here, aren't you?
> Besides the ANSI standard, there are additional portable libraries.
> One of those libraries is called "Universal Foreign Function Call",
> which allows one to write portable code to do effect the linking
> and calling of foreign libraries, such as curses.
Okay, I'll check it out.
Bear
Ray Dillinger <····@sonic.net> writes:
> No, my response was that it's not possible to implement libraries
> which call operating system functions and are portable between
> implementations of Common Lisp. UFFI may be changing this, but
> certainly the language standard provides no way to do it.
The language standard provides two methods of writing portable
programs, which you may be confusing.
One such level of portability -- the 'highest' or 'purest', if you
will -- restricts the program to use only standardized operators.
There are about 978 of those; one can still write interesting programs
using just those, but of course with this definition of portability
you are entirely correct that accessing Operating System functionality
(beyond that provided by the standardized operators themselves) is not
possible.
However, there is a second level of portability, which we could
characterize as being a 'pragmatic' level. Using the read-time
conditional mechanism, it is possible to write programs which access
Operating System functionality in an implementation-dependent manner,
and yet run as expected on all implementations of Common Lisp alive
today. This form of portability is different, as it needs to be
worked on in the face of new implementations and new developments, but
nevertheless programs written this way are portable according at least
to the vernacular definition.
> This is simply not true any more. Systems don't stand alone these
> days; half or more of what you're writing code for these days is
> supposed to communicate over a network. Making an assumption that
> there's a dominant encoding on the current platform and you never
> have to worry about it is wrong. I don't want to write an "A" on an
> EBCDIC machine and have some random sequence of bits go out to a
> machine or file format that's expecting UTF8 or UTF16BE. Standard
> character I/O functions have to be redefined in network code in
> terms of WRITE-BYTE and READ-BYTE, which means, yes, messing with
> numerical codes. I've had to write functions to convert bit
> sequences in a dozen different encodings back and forth to
> characters.
Look up the :EXTERNAL-FORMAT argument to Common Lisp's OPEN function.
>> Then you do the same thing you would do in C, which is to link in
>> the curses library and call its functions.
>
> Interesting. Nothing in the language standard talks about
> how to link in C libraries. You're talking about an
> implementation-dependent extension here, aren't you?
... which can nevertheless be implemented in such a way as to be
portable across implementations. Furthermore, once this is done, user
code can use the (implementation-dependent-yet-portable) layer of
interface to the curses library without worrying about the
under-the-hood implementation, because the same interface to the
lisp/curses library will be presented irrespective of the mechanism
used to pull in the operating system library.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Ray Dillinger <····@sonic.net> writes:
>
> Christopher C. Stacy wrote:
>
> No, my response was that it's not possible to implement libraries
> which call operating system functions and are portable between
> implementations of Common Lisp. UFFI may be changing this, but
> certainly the language standard provides no way to do it.
Well, there are lots of things that become non-portable when you talk
about operating system functions. I just had the "joy" of working out
how to retrieve the local time zone (in C) and trying to get it to work
on Solaris, Darwin, Linux and CYGWIN. Inspite of the existence of
nearly similar time libraries, this turned out to require 3 separate
implementations to handle the subtle differences in available functions
and libraries.
In Common Lisp and Java, it was easier.
--
Thomas A. Russ, USC/Information Sciences Institute
>>>>> On 30 Aug 2004 12:36:12 -0700, Thomas A Russ ("Thomas") writes:
Thomas> Ray Dillinger <····@sonic.net> writes:
>> Christopher C. Stacy wrote:
(didn't write)
Ray Dillinger <····@sonic.net> writes:
>> No, my response was that it's not possible to implement libraries
>> which call operating system functions and are portable between
>> implementations of Common Lisp. UFFI may be changing this, but
>> certainly the language standard provides no way to do it.
Thomas> Well, there are lots of things that become non-portable when you talk
Thomas> about operating system functions. I just had the "joy" of working out
Thomas> how to retrieve the local time zone (in C) and trying to get it to work
Thomas> on Solaris, Darwin, Linux and CYGWIN. Inspite of the existence of
Thomas> nearly similar time libraries, this turned out to require 3 separate
Thomas> implementations to handle the subtle differences in available functions
Thomas> and libraries.
Thomas> In Common Lisp and Java, it was easier.
······@news.dtpq.com (Christopher C. Stacy) writes:
>
> >>>>> On 30 Aug 2004 12:36:12 -0700, Thomas A Russ ("Thomas") writes:
>
> Thomas> Ray Dillinger <····@sonic.net> writes:
> >> Christopher C. Stacy wrote:
>
> (didn't write)
Sorry about that. I didn't look carefully at the attribution lines.
Actually, I guess I didn't look at them at all.
My apologies,
-Tom.
> Ray Dillinger <····@sonic.net> writes:
>
> >> No, my response was that it's not possible to implement libraries
> >> which call operating system functions and are portable between
> >> implementations of Common Lisp. UFFI may be changing this, but
> >> certainly the language standard provides no way to do it.
--
Thomas A. Russ, USC/Information Sciences Institute
>>>>> "CCS" == Christopher C Stacy <······@news.dtpq.com> writes:
>>>>> On Mon, 30 Aug 2004 02:21:23 GMT, Ray Dillinger ("Ray") writes:
Ray> Still, let's say I want something that's simple, but outside
Ray> the standard, such as cursor control on a character-based
Ray> interface (the "curses" library in UNIX).
CCS> Then you do the same thing you would do in C, which is to
CCS> link in the curses library and call its functions.
CCS> Besides the ANSI standard, there are additional portable
CCS> libraries. One of those libraries is called "Universal
CCS> Foreign Function Call", which allows one to write portable
CCS> code to do effect the linking and calling of foreign
CCS> libraries, such as curses.
This is not trivial. The effort required in manually creating these
bindings for one library (OpenSSL) is enough to make me reconsider my
decision to use Common Lisp for my application. I don't prefer
programming in C, but using the "lingua franca" allows me quick and
easy access to a rich variety of libraries I don't have to write.
--
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
On Mon, Aug 30, 2004 at 04:09:54PM -0400, Matthew X. Economou wrote:
> This is not trivial. The effort required in manually creating these
> bindings for one library (OpenSSL) is enough to make me reconsider my
> decision to use Common Lisp for my application. I don't prefer
> programming in C, but using the "lingua franca" allows me quick and
> easy access to a rich variety of libraries I don't have to write.
Are you aware of CL-SSL, the already existing project that
interfaces to OpenSSL with UFFI? I have successfully used it when
testing an Authorize.net gateway client from CL that I was working on.
--
;;;; Matthew Danish -- user: mrd domain: cmu.edu
;;;; OpenPGP public key: C24B6010 on keyring.debian.org
>>>>> On 30 Aug 2004 16:09:54 -0400, Matthew X Economou ("MXE") writes:
CCS> Then you do the same thing you would do in C, which is to
CCS> link in the curses library and call its functions.
MXE> This is not trivial.
One can debate what "trivial" means in the context of developing a
library binding, and of course it depends on the library, how easily
the data structures map to Lisp, and so on. In general, a lot of the
drudge work for this sort of thing could be done by automation.
(I do not know what automation tools are available for that, though.)
I've never used curses (and have no interest in it), but from glancing
at its library documentation, it looks like it would be an easy one.
If someone wanted to implement a curses library for Lisp, I would
offhand suggest doing it with a stream interface that implements
additional functions corresponding to the curses subroutines.
(That is, the stream would encapsulate the window object.)
Then the user could write to the stream using the standard Lisp
functions such as FORMAT rather than having to call waddstr(),
while only having to call functions corresponding to the curses library
to do the actual cursor things like CURSES:CLRTOEL and motion.
Or maybe it would look nice to lexically enclose Lisp output function
calls in a (CURSES:MOVE ..) form. You could bind *STANDARD-OUTPUT*
to *STDSCR* or to your own window, so that you don't have like
seperate mvdelch() and mvwdelch() frobs.
You could look into swig. www.swig.org
It maps C bindings to a number of different languages.
Most notably python, perl and scheeme.
It dosn't support common lisp in it current form but it is a open source
project
and I am sure if somone created support for common lisp they would be glad
to incorporate it.
My version of Corman lisp has a utillity that automatically creates lisp
binding from a C header file (against a dll file) so I am not terribly
motivated.
As quoted from the manual:
"The C declaration parser is written by Vassili Bykov, based on the
original version by
Roger Corman. It automatically generates foreign function interface (FFI)
declarations from C source code.
The parser is invoked whenever a character sequence #! is encountered in
Lisp
code. This character sequence begins a C declaration block: a portion of
the source
containing declarations and preprocessor directives, supposedly pasted
from a C
header file. The declaration block is terminated by a declaration block
end marker:
!#. At the beginning of the block the parser expects to find a translation
parameter
form. The full syntax of parameter form is described later in this text.
The C
declarations in the declaration block are parsed, analyzed, and the
corresponding
Corman Lisp FFI declaration forms are generated."
On Mon, 30 Aug 2004 21:35:10 GMT, Christopher C. Stacy
<······@news.dtpq.com> wrote:
>>>>>> On 30 Aug 2004 16:09:54 -0400, Matthew X Economou ("MXE") writes:
>
> CCS> Then you do the same thing you would do in C, which is to
> CCS> link in the curses library and call its functions.
>
> MXE> This is not trivial.
>
> One can debate what "trivial" means in the context of developing a
> library binding, and of course it depends on the library, how easily
> the data structures map to Lisp, and so on. In general, a lot of the
> drudge work for this sort of thing could be done by automation.
> (I do not know what automation tools are available for that, though.)
>
> I've never used curses (and have no interest in it), but from glancing
> at its library documentation, it looks like it would be an easy one.
>
> If someone wanted to implement a curses library for Lisp, I would
> offhand suggest doing it with a stream interface that implements
> additional functions corresponding to the curses subroutines.
> (That is, the stream would encapsulate the window object.)
> Then the user could write to the stream using the standard Lisp
> functions such as FORMAT rather than having to call waddstr(),
> while only having to call functions corresponding to the curses library
> to do the actual cursor things like CURSES:CLRTOEL and motion.
> Or maybe it would look nice to lexically enclose Lisp output function
> calls in a (CURSES:MOVE ..) form. You could bind *STANDARD-OUTPUT*
> to *STDSCR* or to your own window, so that you don't have like
> seperate mvdelch() and mvwdelch() frobs.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> You could look into swig. www.swig.org
> It maps C bindings to a number of different languages.
> Most notably python, perl and scheeme.
> It dosn't support common lisp in it current form but it is a open
> source project
> and I am sure if somone created support for common lisp they would be
> glad to incorporate it.
SWIG can output its internal representation of the parsed interface
file(s) in an sexp format and there is some experimental code that
translates this into UFFI declarations.
Independent from this Franz added some support for Allegro CL, which
should be included in the CVS version of SWIG.
Though I did not try any of them, I think they are both quite
rudimental.
--
Marco Gidde
John Thingstad wrote:
> You could look into swig. www.swig.org
> It maps C bindings to a number of different languages.
> Most notably python, perl and scheeme.
^^^^^^^
Which Scheme?
Python is a 1.8 implementation language, Perl is a 1 implementation
language and Scheme is a 1 godzillion implementations language :)
Cheers
--
Marco
Several versions of scheeme. See under languages at www.swig.org.
I don't program (much) scheeme so I didn't pay very close attention.
On Tue, 31 Aug 2004 11:46:13 -0400, Marco Antoniotti <·······@cs.nyu.edu>
wrote:
>
>
> John Thingstad wrote:
>> You could look into swig. www.swig.org
>> It maps C bindings to a number of different languages.
>> Most notably python, perl and scheeme.
> ^^^^^^^
>
> Which Scheme?
>
> Python is a 1.8 implementation language, Perl is a 1 implementation
> language and Scheme is a 1 godzillion implementations language :)
>
> Cheers
> --
> Marco
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Marco Antoniotti <·······@cs.nyu.edu> writes:
> John Thingstad wrote:
>> You could look into swig. www.swig.org
>> It maps C bindings to a number of different languages.
>> Most notably python, perl and scheeme.
> ^^^^^^^
>
> Which Scheme?
>
> Python is a 1.8 implementation language, Perl is a 1 implementation
> language and Scheme is a 1 godzillion implementations language :)
SWIG supports three implementations of Scheme: Guile, MzScheme and
Chicken.
The CVS version of SWIG also supports Allegro Common Lisp (contributed
by Ahmon Dancy of Franz, Inc.)
--
Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe
"Matthew X. Economou" <···············@irtnog.org> writes:
> This is not trivial. The effort required in manually creating these
> bindings for one library (OpenSSL) is enough to make me reconsider my
> decision to use Common Lisp for my application. I don't prefer
> programming in C, but using the "lingua franca" allows me quick and
> easy access to a rich variety of libraries I don't have to write.
CLiki to the rescue; look at <URL: http://www.cliki.net/SSL-CMUCL >
and the there mentioned CL-SSL from ACL-COMPAT.
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
Ray Dillinger <····@sonic.net> wrote:
+---------------
| Still, let's say I want something that's simple, but outside
| the standard, such as cursor control on a character-based
| interface (the "curses" library in UNIX).
|
| This requires operating system calls, and therefore cannot
| be implemented using the functions given in the standard.
+---------------
The only operating system calls this requires are two "ioctl()" calls:
one to turn off/on echoing of input and one to switch between line-
oriented and character-oriented input ("cbreak") [and even that makes
sense only on Unix-like systems, and is *NOT* even portable across all
of those (BSD-style vs. System-V-style, for example)]. Everything else
can be done just fine entirely within Common Lisp.
However, as Mathew Danish pointed out in a parallel reply, rather than
re-implement "curses" in Lisp, what most people do is just use some FFI
(such as UFFI or CMUCL's "alien") to call out to a C library version of
"curses"...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ray Dillinger <····@sonic.net> wrote:
+---------------
| Still, let's say I want something that's simple, but outside
| the standard, such as cursor control on a character-based
| interface (the "curses" library in UNIX).
|
| This requires operating system calls, and therefore cannot
| be implemented using the functions given in the standard.
+---------------
The only operating system calls this requires are two "ioctl()" calls:
one to turn off/on echoing of input and one to switch between line-
oriented and character-oriented input ("cbreak") [and even that makes
sense only on Unix-like systems, and is *NOT* even portable across all
of those (BSD-style vs. System-V-style, for example)]. Everything else
can be done just fine entirely within Common Lisp.
However, as others have pointed out[1], rather than re-implement "curses"
in Lisp (even tough that's certainly possible), what most people do is
just use some FFI (such as UFFI or CMUCL's "alien") to call out to a C
library version of "curses"...
-Rob
[1] A previous versions of this reply (which I've tried to cancel)
credited Mathew Danish, who did mention UFFI, but I was really
talking about Christopher Stacy's comments about UFFI & "curses".
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ray Dillinger <····@sonic.net> wrote:
> standard does a *LOT* more than most others. Still, let's
> say I want something that's simple, but outside the standard,
> such as cursor control on a character-based interface (the
> "curses" library in UNIX).
Like this one?
http://www.cliki.net/cl-ncurses
http://common-lisp.net/project/cl-ncurses/
Seems to work fine on top of UFFI.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
·········@random-state.net wrote:
> Ray Dillinger <····@sonic.net> wrote:
>
>
>>standard does a *LOT* more than most others. Still, let's
>>say I want something that's simple, but outside the standard,
>>such as cursor control on a character-based interface (the
>>"curses" library in UNIX).
>
>
> Like this one?
>
> http://www.cliki.net/cl-ncurses
> http://common-lisp.net/project/cl-ncurses/
>
> Seems to work fine on top of UFFI.
Yes, I wrote a terminal-based map viewer for the Hansa2 game using it.
Works fine.
>>>>> On Sun, 29 Aug 2004 17:16:33 GMT, Ray Dillinger ("Ray") writes:
Ray> CL is not a standard library; CL is a Lisp that has a lot of
Ray> standard library functions built in. But the "library" of
Ray> functions isn't portable between Common Lisp implementations,
Ray> let alone to different dialects of lisp.
"Common Lisp" is an ANSI standard; it defines a portable language.
A good reference is http://www.lispworks.com/reference/HyperSpec/index.html
The remainder of your message was about a lack of standard platform
libraries for certain operating system functions. It is true that
those are not part of the language standard. Nor are they part of
the standards for the other languages (eg. C) that original poster
was making comparisons with. (However, there are libraries for doing
most or all of those operating-system dependant things, and they are
generally portable across Common Lisp implementations, and in some
cases even portable across entirely different operating systems.)
The original poster, a newbie, specifically referred to a commercial
Common Lisp implementation. He asking about things which are part of
the language, standard and portable. Specifically, he wanted to know
if there were any standard IO functions besides WRITE-STRING.
This was followed up by another newbie who mentioned some Common Lisp
textbooks. I cannot understand why you, who very well understands
about the different dialects, would want to enter the conversaion by
trying to suggest that Common Lisp was not a standard, and to conflate
perceived defficiencies in Scheme and Common Lisp.
>> Coby Beck wrote:
>> Common Lisp is a dialect of Lisp. Around here I'd say the defalt
>> meaning of Lisp, sans context, is Common Lisp. Common Lisp is its
>> own complete language as specified by an ANSI standard.
Ray> I've seen a lot of people use it that way, but to me "Lisp" refers
Ray> to a whole family of languages, taking in Common Lisp, Scheme, Autolisp,
Ray> elisp, MacLisp, forthcoming Lisps like Arc, et cetera.... It's not so
Ray> much the name of a language as the name of a language design space.
In this particular thread, people were specifically asking for information
about "CL" or "Common Lisp" refers to. The highly qualified statement
that Coby made was "around here", referring to the comp.lang.lisp newsgroup.
Coby made a factual statement -- it is true that when people refer to
"Lisp" in this newsgroup, the almost always mean ANSI Common Lisp.
(By contrast, when they refer to "Lisp" on the Emacs newsgroups,
they are usually referring to the Emacs extension language.
And when they are talking on the Scheme newsgroup, they
use the word...hmmm..."Scheme"..rather than "Lisp"? :)
Ray> So of course I stifle a laugh whenever I see a parochial
Ray> statement that indicates the speaker's lisp universe is
Ray> limited to only one dialect.
It's only your phenomenally arrogant imagination that the regular
denizens of this newsgroup are unfamiliar with the other dialects
of Lisp. Looking over the newsgroup archives would demonstrate that.
But since you've have been around on these newsgroups for years and
are aware of all this, and even prefaced your complaint with "a whole
lot of people" disagreeing with your position, perhaps your logic
is faulty and you have misidentified the parochial party involved.
Ray> Of course, my first Lisp was Scheme, so maybe
Ray> I've just got a different view of things.
You are a regular participant in the comp.lang.scheme newsgroup,
and you are aware of that seperate forum. I think you are also
aware of the autocad newsgroup, and the emacs newsgroup. And you
know that when people come asking about all those other languages,
they get directed to those forums.
So the only thing I can really get from this complaint you have
posted here is that you're a frustrated Scheme programmer who is
trying to start some kind of language or language-name flame war.
We're not really interested in that. And I think you have a lot
more to offer than this, and that you do yourself a considerable
disservice by such trolling,
"Ray Dillinger" <····@sonic.net> wrote in message
··························@typhoon.sonic.net...
> Coby Beck wrote:
> > "neo88" <······@truevine.net> wrote in message
> > ·································@posting.google.com...
> >
> >>CL is a standerd library of Lisp. I think it's safe to say that no?
> >
> > Common Lisp is a dialect of Lisp. Around here I'd say the defalt
meaning of
> > Lisp, sans context, is Common Lisp. Common Lisp is its own complete
> > language as specified by an ANSI standard.
>
> I've seen a lot of people use it that way, but to me "Lisp" refers
> to a whole family of languages, taking in Common Lisp, Scheme, Autolisp,
> elisp, MacLisp, forthcoming Lisps like Arc, et cetera.... It's not so
> much the name of a language as the name of a language design space.
Not by default in comp.lang.lisp. Natural language is most definitively
defined by its usage, and in comp.lang.lisp people mean CL when they say
Lisp the overwhelming majority of the time or they qualify it with what they
really mean.
> So of course I stifle a laugh whenever I see a parochial statement
> that indicates the speaker's lisp universe is limited to only one
> dialect.
Where do you see such a statement?
> CL is not a standard library; CL is a Lisp that has a lot of
> standard library functions built in. But the "library" of
> functions isn't portable between Common Lisp implementations,
> let alone to different dialects of lisp.
The "library" you have defined as the "standard library functions built in
[to CL]." Your statement that this "library" isn't portable between CL
implementations is misleading as it stands. With reasonable assumptions
about what you mean by CL implementations it is completely wrong.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
>>>>> On 22 Aug 2004 08:50:56 -0700, neo88 ("neo88") writes:
I really picked on an experienced Lisp (Scheme) programmer
who reacted to some of your statements here, so I would like
to straighten you out on some of those things.
neo88> CL is a standerd library of Lisp. I think it's safe to say that no?
Your characterization of Common Lisp as "a standard library of Lisp"
suggests that you are very new to Lisp. Common Lisp is a language,
defined by an ANSI standard specification, and it includes many
useful functions. Common Lisp is portable - a program that only
uses what is defined in the standard will run in any Common Lisp.
Some other languages, like C and JAVA, provide fewer of these useful
functions in their core language definition, But they have associated
standards that define those functions in libraries. Some of those
libraries, particularly in the case of JAVA, are portable.
Lisp and C give you source code portability.
JAVA goes beyond that and gives you some binary portability.
neo88> Common Lisp, meaning it's universal.
No! Not "universal" in the sense of providing everything,
nor in the sense of bridging the gaps across the various
different languages that call themselves "dialects of Lisp".
The word "common" in "Common Lisp" refers to what could commonly
be agreed upon by (only) some of the different factions of Lisp,
back at a particular point in history. A more accurate meaning
of "Common" would be along the lines of "least common denominator".
Your syggestion that Lisp is "universal" is overenthusiastic.
Lisp is a very general purpose language, but the "Common Lisp"
language, as defined by its ANSI standard document, does not
come close to providing everything that is necessary to write
any and all kinds of programs.
All Common Lisp implementations also include features that are
outside the Common Lisp standard, and which are not portable.
Common Lisp does not preclude these extra (and necessary) things,
but they are not part of the standard.
neo88> Lisp doesn't really have librarys like C++ or anything, it
neo88> just provides everything you need, if it doesn't have it you
neo88> can write in right into the language itself with macros etc.
Also, there are additional libraries that are popular (might be called
"de facto standards" by some people in the community) that provide
functionality beyond what the ANSI standard provides. These libraries
are portable in the sense that they happen to work in most or all of
the existing Common Lisp implementations. These libraries work by using
the non-ztandard functions available in each implementation -- parts of
these libraries had to be re-implemented for each Common Lisp system.
One of those libraries, called UFFI, provides a portable way
to interface with libraries outside of the Lisp implementation.
This can be used to do "system calls", link and use C libraries,
and so forth. (Of course, those things themselves may or may
not be portable.)
There are also libraries for interfacing to JAVA programs.
(I think these libraries are portable too, but I've never
used them, and I'm not sure. There's no reason why such
an interface facility could not be portable, though.)
There have been many versions of the Lisp language.
Nobody even really fully agrees what constitutes a "Lisp".
The other major branch of Lisp is a dialect called "Scheme".
When people say that these various Lisp languages, such as Scheme,
are dialects of Lisp, they do not mean that they are dialects of
Common Lisp. They mean some imaginary Lisp mother tounge.
It would probably be more accurate to classify these are "languages",
not "dialects", because they are not always quite mutually intelligable
to each other, and especially because they each have armies.
You could say that "Lisp is a universal language", referring to
some imaginary dialect of Lisp that could be invented and defined.
But no such Lisp specification, much less an actual compiler, exists.
Even very early on in history there were different versions of Lisp.
Even the first paper describing the language was different from what
was actually implemented. Before long there were variations on the
language, and wars between Lisp languages. Both of the major Lisp
languages of today, Common Lisp and Scheme, each include (some of
the same and some different) important concepts that were not
present in any early version of Lisp.
Another Lisp language that has been mentioned in this thread is "Emacs
Lisp" or "elisp". It is the extension language for the Emacs editor.
It is currently based on an recent ancestor of Common Lisp, but is
different from Common Lisp in certain radical ways. They are thinking
of changing it to be a version of Scheme (which would make it more like
Common Lisp in some ways, but in most ways more different than CL).
Before "Common Lisp" was an ANSI standard, an earlier version of the
language was an industry standard that was in popular use for a number
of years. The defining document was a book referred to as "CLtL".
An intermediate version was referred to as "CLtL2". There is still
at least one old implementation of Common Lisp that, after a long hiatus,
is still working on making the transition to the ANSI standard definition.
As noted, around here when people say "Lisp", they are usually
referring to "ANSI Common Lisp".
In article
<·························@per-qv1-newsreader-01.iinet.net.au>,
Johnathan Doe <·············@fastmail.com.au> wrote:
> Hi,
>
> When working through Lisp tutorials, I get frustrated because I can't
> write any useful programs. None of the tutorials show me how to do I/O
> in the console, or with files. After a lot of searching,
Where did you search? I found the below links in a minute on the Internet.
> all I have
> found so far is (write-string "Hello, World"). I'm stuck with
> evaluating one-liners inside emacs.
>
> Does ACL have a standard library with I/O functions, file I/O, and the
> bare necessities to do stuff that I could do in C or C++, or any other
> language?
ACL comes with a manual. How about reading it?
It is even online:
http://www.franz.com/support/documentation/6.2/doc/contents.htm
Common Lisp comes as a standard called ANSI Common Lisp.
Look at it. It is even online:
http://www.franz.com/support/documentation/6.2/ansicl/ansicl.htm
> For instance, I'd really like to write web server applications in Lisp.
> I'd love to develop mod_lisp for apache, where I can write web
> services as well as have control over server internals with Lisp.
>
> Can Lisp do network programming? What about system level programming?
> Can I access kernel system calls with Lisp?
Again, it is all online: http://opensource.franz.com/
> Finally, is there a decent Lisp tutorial anywhere that shows me how to
> write useful programs in Lisp and use its standard library (if it has one?!)
On Sun, 22 Aug 2004 10:32:27 +1000, Johnathan Doe <·············@fastmail.com.au> wrote:
> Does ACL have a standard library with I/O functions, file I/O, and
> the bare necessities to do stuff that I could do in C or C++, or any
> other language?
Do you mean ACL as in "ANSI Common Lisp" (the language) or as in
"Allegro Common Lisp" (the implementation)? Anyway, the answer is of
course yes in both cases.
> I'd love to develop mod_lisp for apache, where I can write web
> services as well as have control over server internals with Lisp.
Several options for dynamic web programming with Common Lisp are
available including at least three open source web servers written
completely in Lisp. Also, we already have mod_lisp to interface Common
Lisp programs with Apache so you don't have to develop it.
> Can Lisp do network programming? What about system level
> programming? Can I access kernel system calls with Lisp?
Sure.
> Finally, is there a decent Lisp tutorial anywhere that shows me how
> to write useful programs in Lisp and use its standard library (if it
> has one?!)
You should first learn how to use Google.
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
> Finally, is there a decent Lisp tutorial anywhere that shows me how to
> write useful programs in Lisp and use its standard library (if it has one?!)
Although some seems to think you need to learn how to Google, I fully understand
your position, as I have experience the same problem. Recently I have found
better sources of information though. There are two I would recommend for
a more "practical" source where you can learn some useful API without hunting for
hours in the Hyperspec:
"Practical Common Lisp", which I think has already been mentioned:
http://www.gigamonkeys.com/book/
The "Common Lisp Cookbook":
http://cl-cookbook.sourceforge.net/
--
/ Peter Schuller, InfiDyne Technologies HB
PGP userID: 0xE9758B7D or 'Peter Schuller <··············@infidyne.com>'
Key retrieval: Send an E-Mail to ·········@scode.org
E-Mail: ··············@infidyne.com Web: http://www.scode.org
>>>>> On Sun, 22 Aug 2004 10:32:27 +1000, Johnathan Doe ("Johnathan") writes:
Johnathan> When working through Lisp tutorials, I get frustrated because I can't
Johnathan> write any useful programs. None of the tutorials show me how to do
Johnathan> I/O in the console, or with files. After a lot of searching, all I
Johnathan> have found so far is (write-string "Hello, World"). I'm stuck with
Johnathan> evaluating one-liners inside emacs.
What tutorials are these?
What Lisp are you using?
What does Emacs have to do with it?