1> Is it just me or does working with FFI's rather invalidate some of
the better points of working with lisp (ie suddenly you are working in
a fragile environment, with segfaults a go-go and having to continually
restart your repl? - until the lib stabilises, though?)
2> Is there going to be a new standard? I want the mess with pathnames
fixed, I'd also like inline assembler, a standard FFI, and threads.
Finalisation would be nice. Plus the ability to refer to self in an
:initform or :initarg. The ablilty to align vectors and structs in
memory would be nice, too.
3> Can I still write my own VOPs as a micro-optimisation for CMUCL and
SBCL? (x86)..
4> How many years does it take to get familiar with this langugage and
not feel like a newbie?
-
John Connors
http://badbyteblues.blogspot.com
From: Raymond Toy
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <sxdy8c6grei.fsf@rtp.ericsson.se>
>>>>> "JohnFredCee" == JohnFredCee <·····@yagc.ndo.co.uk> writes:
3> Can I still write my own VOPs as a micro-optimisation for CMUCL and
JohnFredCee> SBCL? (x86)..
Yes, of course. Like all open-source software, you get the sources to
play with however you want.
Ray
Perhaps I should rephrase that - can I define new VOPs in an
application without and expect it not to break with a new version of
SBCL, without my touching the compiler source?
..actually this is a question for the SBCL list..I'll ask there when I
actually get around to doing this..
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> 2> Is there going to be a new standard? I want the mess with pathnames
Define "standard" :)
> fixed, I'd also like inline assembler, a standard FFI, and threads.
You may give CLRFI a try:
http://clrfi.alu.org
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Thomas A. Russ
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <ymiis3axluh.fsf@sevak.isi.edu>
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> 2> Is there going to be a new standard? I want the mess with pathnames
> fixed, I'd also like inline assembler, a standard FFI, and threads.
Hmmm. I find it rather hard to imagine what a standard for inline
assembler would look like, short of just agreeing on a name for a form
whose body is then implementation dependent.
I normally run Common Lisp on 4 different operating systems, 3
different hardward architectures and (at the moment) 5 different actual
processor chips. It's a pretty tall order to cover not only my current
needs, but also those that will arise in the future.
On the other hand, standard FFI, threads and sockets would be nice. So
would some connection to something like ODBC or JDBC.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
>
> > 2> Is there going to be a new standard? I want the mess with pathnames
> > fixed, I'd also like inline assembler, a standard FFI, and threads.
>
> Hmmm. I find it rather hard to imagine what a standard for inline
> assembler would look like, short of just agreeing on a name for a form
> whose body is then implementation dependent.
Of course, you'd not specify an all emcompassing standard. But what
you'd definitely not want, is to have a different API and different
mnemonic symbols in different implementations on the same processor.
A sexp representing an assembler function should be usable portably on
all implementations running on the same architecture.
(And a pathname expression should behave the same way on all
implementations running on POSIX systems, even if this same pathname
expression has a different semantics or even no semantic at all on a
different, non POSIX, file system).
> I normally run Common Lisp on 4 different operating systems, 3
> different hardward architectures and (at the moment) 5 different actual
> processor chips. It's a pretty tall order to cover not only my current
> needs, but also those that will arise in the future.
>
> On the other hand, standard FFI, threads and sockets would be nice. So
> would some connection to something like ODBC or JDBC.
http://clrfi.alu.org/
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Christopher C. Stacy
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <usm2eqgy2.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> > "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> >
> > > 2> Is there going to be a new standard? I want the mess with pathnames
> > > fixed, I'd also like inline assembler, a standard FFI, and threads.
> >
> > Hmmm. I find it rather hard to imagine what a standard for inline
> > assembler would look like, short of just agreeing on a name for a form
> > whose body is then implementation dependent.
>
> Of course, you'd not specify an all emcompassing standard. But what
> you'd definitely not want, is to have a different API and different
> mnemonic symbols in different implementations on the same processor.
>
> A sexp representing an assembler function should be usable portably on
> all implementations running on the same architecture.
Unless you are proposing to define one or more standard assembly
languges, I think you want to be able to conditionalize your LAP
source on several different axis. For example: machine instruction set,
assembler (mnemonics and conventions), and maybe operating system and
other features. Some machine instruction sets will be virtual machines,
such as for byte-code interpreter Lisp systems (which might also
support real machine LAP codes). I think you want to be able to tell
the Lisp implementation to use either its own assembler or be able to
specify an external assembler.
Lots of naming issues, and compile-time vs. run-time conditionalization.
When you're all done, was there a real benefit to doing all this?
And shouldn't it be integrated with a standard FFI interface?
And be sure that you proscribe nothing that will interfere with
an (extended) conforming Lisp for a non-traditional system.
This is an area that seems like it should be part of adjunct standards,
not part of the core language specification.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > ···@sevak.isi.edu (Thomas A. Russ) writes:
> >
> > > "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> > >
> > > > 2> Is there going to be a new standard? I want the mess with pathnames
> > > > fixed, I'd also like inline assembler, a standard FFI, and threads.
> > >
> > > Hmmm. I find it rather hard to imagine what a standard for inline
> > > assembler would look like, short of just agreeing on a name for a form
> > > whose body is then implementation dependent.
> >
> > Of course, you'd not specify an all emcompassing standard. But what
> > you'd definitely not want, is to have a different API and different
> > mnemonic symbols in different implementations on the same processor.
> >
> > A sexp representing an assembler function should be usable portably on
> > all implementations running on the same architecture.
>
> Unless you are proposing to define one or more standard assembly
> languges, I think you want to be able to conditionalize your LAP
> source on several different axis. For example: machine instruction set,
> assembler (mnemonics and conventions), and maybe operating system and
> other features. Some machine instruction sets will be virtual machines,
> such as for byte-code interpreter Lisp systems (which might also
> support real machine LAP codes). I think you want to be able to tell
> the Lisp implementation to use either its own assembler or be able to
> specify an external assembler.
>
> Lots of naming issues, and compile-time vs. run-time conditionalization.
> When you're all done, was there a real benefit to doing all this?
> And shouldn't it be integrated with a standard FFI interface?
>
> And be sure that you proscribe nothing that will interfere with
> an (extended) conforming Lisp for a non-traditional system.
>
> This is an area that seems like it should be part of adjunct standards,
> not part of the core language specification.
One can imagine anything, but to be practical, I only ask that two
implementations running on the same processor (or processor familly)
use the same syntax for assembler sources.
Eg. I'd expect something like this to work on all implementations:
#+(not assembler)
(warn "Will work slower without an assembler)
#+(and assembler (not (or x86 m680x0)))
(warn "No assembler optimization for this architecture.")
#+(or (not assembler) (not (or x86 m680x0)))
(defun sum (a b) (+ a b))
#+(and assembler x86)
(defun sum (a b)
(declare (type (signed-byte 32) a)
(type (signed-byte 32) b))
(assembler
(movl a eax)
(addl b eax)))
#+(and assembler m680x0)
(defun sum (a b)
(declare (type (signed-byte 32) a)
(type (signed-byte 32) b))
(assembler
(move.l a d0)
(add.l b d0)))
#+(and assembler x86)
(defasm interrupt-handler
(pushl ebp)
(movl esp ebp)
(subl 4 esp)
(movl #x401204d0 (-4 ebp)
(movl (-4 ebp) eax)
(cmpb 0 (eax))
(jns :L2)
(movl (-4 ebp) ecx)
(incl ecx)
(movl (-4 ebp) edx)
(incl edx)
(movb #xfc al)
(andb (edx) al)
(movb al (ecx))
:l2
(leave)
(ret)))
#+(and assembler x86)
(poke (+ 28 *interrupt-vector-address*)
(address interrupt-handler))
What we want to avoid is this:
#+(and cmu x86)
(defun sum (a b)
(declare (type (signed-byte 32) a)
(type (signed-byte 32) b))
(assembler
(movl a eax)
(addl b eax)))
#+(and sbcl x86)
(defun sum (a b)
(declare (type (signed-byte 32) a)
(type (signed-byte 32) b))
(sb-asm
"movl a,eax"
"addl b,eax"))
#+(and clisp x86)
(defun sum (a b)
(declare (type (signed-byte 32) a)
(type (signed-byte 32) b))
(asm
load a into eax
add b to eax))
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Christopher C. Stacy
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <ud5ti3vtc.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> >
> > > ···@sevak.isi.edu (Thomas A. Russ) writes:
> > >
> > > > "JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> > > >
> > > > > 2> Is there going to be a new standard? I want the mess with pathnames
> > > > > fixed, I'd also like inline assembler, a standard FFI, and threads.
> > > >
> > > > Hmmm. I find it rather hard to imagine what a standard for inline
> > > > assembler would look like, short of just agreeing on a name for a form
> > > > whose body is then implementation dependent.
> > >
> > > Of course, you'd not specify an all emcompassing standard. But what
> > > you'd definitely not want, is to have a different API and different
> > > mnemonic symbols in different implementations on the same processor.
> > >
> > > A sexp representing an assembler function should be usable portably on
> > > all implementations running on the same architecture.
> >
> > Unless you are proposing to define one or more standard assembly
> > languges, I think you want to be able to conditionalize your LAP
> > source on several different axis. For example: machine instruction set,
> > assembler (mnemonics and conventions), and maybe operating system and
> > other features. Some machine instruction sets will be virtual machines,
> > such as for byte-code interpreter Lisp systems (which might also
> > support real machine LAP codes). I think you want to be able to tell
> > the Lisp implementation to use either its own assembler or be able to
> > specify an external assembler.
> >
> > Lots of naming issues, and compile-time vs. run-time conditionalization.
> > When you're all done, was there a real benefit to doing all this?
> > And shouldn't it be integrated with a standard FFI interface?
> >
> > And be sure that you proscribe nothing that will interfere with
> > an (extended) conforming Lisp for a non-traditional system.
> >
> > This is an area that seems like it should be part of adjunct standards,
> > not part of the core language specification.
>
> One can imagine anything, but to be practical, I only ask that two
> implementations running on the same processor (or processor familly)
> use the same syntax for assembler sources.
>
> Eg. I'd expect something like this to work on all implementations:
But there's no reason to expect that -- Lisp does not include an
assembler, and there's no reason to believe that there's any assembler
on the machine that would understand those opcode mneumonics.
······@news.dtpq.com (Christopher C. Stacy) writes:
> > One can imagine anything, but to be practical, I only ask that two
> > implementations running on the same processor (or processor familly)
> > use the same syntax for assembler sources.
> >
> > Eg. I'd expect something like this to work on all implementations:
>
> But there's no reason to expect that -- Lisp does not include an
> assembler, and there's no reason to believe that there's any assembler
> on the machine that would understand those opcode mneumonics.
You've not read the example, have you.
I'll repeat: the point is that the same assembler source must be
usable on the same processor whatever the Common-Lisp implementation.
It's exactly the same point that says that the same library with the
same FFI API should be usable on the same processor whatever the
Common-Lisp implementation. This is not the case and it's a pain,
that's only partially aleviated by UFFI.
It's still exactly the same point that says that the same pathname
processing should be implemented by all implementations on the same OS
(or even the same OS class, such as POSIX).
There are very good reasons to be expecting this, from a user point of
view. And there are very good reasons for "vendors" to implement
common substandard rather to try to invent vendor-specific APIs. A
good set of libraries usable by all implementations would do much to
"sell" more implementations and to 'sell" Common-Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Christopher C. Stacy
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <ufyydvhch.fsf@news.dtpq.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > > One can imagine anything, but to be practical, I only ask that two
> > > implementations running on the same processor (or processor familly)
> > > use the same syntax for assembler sources.
> > >
> > > Eg. I'd expect something like this to work on all implementations:
> >
> > But there's no reason to expect that -- Lisp does not include an
> > assembler, and there's no reason to believe that there's any assembler
> > on the machine that would understand those opcode mneumonics.
>
> You've not read the example, have you.
>
> I'll repeat: the point is that the same assembler source must be
> usable on the same processor whatever the Common-Lisp implementation.
I'll repeat: the point is that you are demanding that Common Lisp
provide an assembler. It doesn't.
> There are very good reasons to be expecting this, from a user point of view.
I have very good reasons, from a user point of view,
why Common Lisp should give me blowjobs, too.
But I don't think that's any more reasonable than your demand.
Christopher C. Stacy wrote:
> I'll repeat: the point is that you are demanding that Common Lisp
> provide an assembler. It doesn't.
Yeah, but /should/ it?
--tcr.
Let me invert the question: Why shouldn't it?
You'd need just a simple back end that can emit values into the machine
language output of the compiler, plus maybe fixnum addresses and
simple-array adresses.
Ok, I'm assuming we are using a native compiler, but that info can be
gleaned from *features* or the like.
Once that is part of the standard, your assembler is just another
Common lisp App - parser, lookup table, symbol table, yawn..
There are things you can only do really effectively in low level
assembly, like efficent interrupt handling or software rendering. It'd
be nice not to have to step out of the HLL environment to do this. C &
C++ can handle it, why not Lisp? I don't see the Lisp crowd as being
coders who accept language limitations ;)
John Connors
http://badbyteblues.blogspot.com
From: David Steuber
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <87d5tg1q6g.fsf@david-steuber.com>
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> Let me invert the question: Why shouldn't it?
>
> You'd need just a simple back end that can emit values into the machine
> language output of the compiler, plus maybe fixnum addresses and
> simple-array adresses.
>
> Ok, I'm assuming we are using a native compiler, but that info can be
> gleaned from *features* or the like.
>
> Once that is part of the standard, your assembler is just another
> Common lisp App - parser, lookup table, symbol table, yawn..
>
> There are things you can only do really effectively in low level
> assembly, like efficent interrupt handling or software rendering. It'd
> be nice not to have to step out of the HLL environment to do this. C &
> C++ can handle it, why not Lisp? I don't see the Lisp crowd as being
> coders who accept language limitations ;)
Before you can have a standard assembler, I think you need a standard
FFI. This is necessary to copy Lisp objects to machine objects and
call assembler routines which can just as easily use the system
standard C calling convention or some other calling convention.
Asslembler routines will need to be able to return information to the
Lisp which might as well be done via the FFI mechanism in the Lisp.
Assembler routines may also want to be able to call out to Lisp
functions meaning that the FFI will need to support callbacks.
Right now there are free Lisps which provide these capabilities. They
just aren't standardized.
Hmm. I may be wrong about the FFI need since SBCL VOPs don't use the
Alien stuff and I guess OpenMCL's LAP bits don't use FFI either. I
guess someone just needs to have a go at writing a portable embedded
assembler.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <87psxhlarg.fsf@qrnik.zagroda>
Pascal Bourguignon <····@mouse-potato.com> writes:
> I'll repeat: the point is that the same assembler source must be
> usable on the same processor whatever the Common-Lisp implementation.
How would the assembler access Lisp data? Different implementations
use different data representations.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
I'm thinking of sap-vector on SBCL, but I keep forgetting, that the
addresses of such things are not known at compile time in the world of
Lisp..doesn't the standard guarentee that a simple array is a
contigious hunk of memory somewhere and that fixnums are a reasonable
size for the machine (ie fit in a register)? That's all you need for
most assembler level work, really.
John Connors
http://badbyteblues.blogspot.com
From: Rene de Visser
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <d2e1bv$d1m$1@news.sap-ag.de>
"Marcin 'Qrczak' Kowalczyk" <······@knm.org.pl> wrote in message
···················@qrnik.zagroda...
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > I'll repeat: the point is that the same assembler source must be
> > usable on the same processor whatever the Common-Lisp implementation.
>
> How would the assembler access Lisp data? Different implementations
> use different data representations.
He just needs to switch to a lisp machine.
Then he has a lisp assembler. It's called lisp.
Rene.
That's the solution in an ideal world. A world where the LISP machine
is the industry standard and the PC is an obscure obsolete box touted
by a band of misfits who can out-code everyone else on the planet, and
have been for the last 20 years, but somehow still fail to get
noticed..
John Connors
http://badbyteblues.blogspot.com
From: Lars Brinkhoff
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <858y45jp55.fsf@junk.nocrew.org>
"Rene de Visser" <··············@hotmail.de> writes:
> "Marcin 'Qrczak' Kowalczyk" <······@knm.org.pl> wrote in message
> ···················@qrnik.zagroda...
> > How would the assembler access Lisp data? Different implementations
> > use different data representations.
> He just needs to switch to a lisp machine.
> Then he has a lisp assembler. It's called lisp.
I believe the Lisp Machines compiled Lisp to code for a lower-level
stack machine. (And the stack machine was implemented in microcode.)
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > I'll repeat: the point is that the same assembler source must be
> > usable on the same processor whatever the Common-Lisp implementation.
>
> How would the assembler access Lisp data? Different implementations
> use different data representations.
Use the FFI.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Right, UFFI is the best current working solution, but the advantage of
integrating assembler and HLL is that the optimiser can spot
optimisation opportunities that it would otherwise miss with FFI and
there is no function call overhead. That's why it's called "inline
assembler". And when you work in assembler, but defintion, you *do*
care that much about speed...
..actually something like this could probalbly done as a app that poses
UFFI extension, assembling into a bit of memory already reserved by the
UFFI. It wouldn't inline without some compiler extensions, obviously,
but at least the "standard" assembler would be there..
..am I mad?
John Connros
http://badbyteblues.blogspot.com
"JohnFredCee" <·····@yagc.ndo.co.uk> writes:
> 1> Is it just me or does working with FFI's rather invalidate some of
> the better points of working with lisp (ie suddenly you are working in
> a fragile environment, with segfaults a go-go and having to continually
> restart your repl? - until the lib stabilises, though?)
Well, even when you don't use FFI, your nice lisp application runs on
an OS written in C! (Unless you're rich enough and have enough time
to run it on a Lisp Machine).
> 2> Is there going to be a new standard? I want the mess with pathnames
> fixed, I'd also like inline assembler, a standard FFI, and threads.
> Finalisation would be nice. Plus the ability to refer to self in an
> :initform or :initarg. The ablilty to align vectors and structs in
> memory would be nice, too.
Start to write CLRFIs. http://clrfi.alu.org/
In the mean time, there are practical solutions to these problems in
the form of implementation specific extensions or libraries.
> 3> Can I still write my own VOPs as a micro-optimisation for CMUCL and
> SBCL? (x86)..
>
> 4> How many years does it take to get familiar with this langugage and
> not feel like a newbie?
Let me see, I've serriously started to use Common Lisp two years ago
and I'm still quite newbie... I'd count at least ten years.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
From: Sam Steingold
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <u4qeuximx.fsf@gnu.org>
> * Pascal Bourguignon <····@zbhfr-cbgngb.pbz> [2005-03-29 22:35:16 +0200]:
>
> Start to write CLRFIs. http://clrfi.alu.org/
I submitted one.
I never heard from them - other than "yes, you jumped through all our
hoops, the ball is on our side now".
If I am not alone, we could start an emotional support group
- "CLRFI authors neglected by the CLRFI editors".
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.dhimmi.com/> <http://www.honestreporting.com>
<http://www.mideasttruth.com/> <http://pmw.org.il/> <http://www.camera.org>
Never trust a man who can count to 1024 on his fingers.
From: Marco Antoniotti
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <V0B2e.63$fp1.90405@typhoon.nyu.edu>
Hi
the CLRFI "caretakers" have been bogged down by a number of problems
outside the CLRFI itself.
I agree that the CLRFI setup is not up to par yet. In particular I
believe that there are problems with the automation of several of the
steps involved. Plus, and more important, we still do not have a group
of editors ready to formally review the entries.
FOr that, and for the delay in answering to you, I apologize, also on
behalf of the other CLRFI "caretakers".
I saw at the time your submission (COMPILED-FILE-P) and, AFAIAC it was
ok. However, as I said, there is not yet a group of editors ready to
take care of the process.
My personal opinion, is that the ILC is the right place to get the ball
rolling again.
Cheers
--
Marco
Sam Steingold wrote:
>>* Pascal Bourguignon <····@zbhfr-cbgngb.pbz> [2005-03-29 22:35:16 +0200]:
>>
>>Start to write CLRFIs. http://clrfi.alu.org/
>
>
> I submitted one.
> I never heard from them - other than "yes, you jumped through all our
> hoops, the ball is on our side now".
>
> If I am not alone, we could start an emotional support group
> - "CLRFI authors neglected by the CLRFI editors".
>
>
>
From: Sam Steingold
Subject: Re: Random questions from a slightly less newbie lisper..
Date:
Message-ID: <uhditvuy9.fsf@gnu.org>
> * Marco Antoniotti <·······@pf.alh.rqh> [2005-03-30 12:07:01 -0500]:
>
> I agree that the CLRFI setup is not up to par yet. In particular I
> believe that there are problems with the automation of several of the
> steps involved. Plus, and more important, we still do not have a group
> of editors ready to formally review the entries.
why not put up _everything_ you received and let the public post
comments? (a la "an open review")
if you also let the author modify the submission to accommodate public
comments, the process might eventually take care of itself: the editors
will emerge from the public and all you will need to do is bless them.
(this is approximately the way cygwin package acceptance process works).
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.memri.org/> <http://www.mideasttruth.com/>
<http://www.openvotingconsortium.org/> <http://www.iris.org.il>
If your VCR is still blinking 12:00, you don't want Linux.
JohnFredCee wrote:
> 1> Is it just me or does working with FFI's rather invalidate some of
> the better points of working with lisp (ie suddenly you are working in
> a fragile environment...
that has been my experience. fortunately, I am mostly using stable C
libraries.
> 2> Is there going to be a new standard? I want the mess with pathnames
> fixed, I'd also like inline assembler, a standard FFI, and threads.
> Finalisation would be nice.
FFI and threads would rock. Not sure that is enough to recommence the
standards process.
Plus the ability to refer to self in an
> :initform or :initarg. The ablilty to align vectors and structs in
> memory would be nice, too.
>
> 3> Can I still write my own VOPs as a micro-optimisation for CMUCL and
> SBCL? (x86)..
>
> 4> How many years does it take to get familiar with this langugage and
> not feel like a newbie?
Different answers. I felt right at home in weeks, but going on ten years
I can still discover something and feel like a newby. I consider that a
feature, not a bug. Well, it might be a bug in me: I cannot bear to read
tech books straight thru.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> JohnFredCee wrote:
> > 1> Is it just me or does working with FFI's rather invalidate some of
> > the better points of working with lisp (ie suddenly you are working in
> > a fragile environment...
>
> that has been my experience. fortunately, I am mostly using stable C
> libraries.
>
> > 2> Is there going to be a new standard? I want the mess with pathnames
> > fixed, I'd also like inline assembler, a standard FFI, and threads.
> > Finalisation would be nice.
>
> FFI and threads would rock. Not sure that is enough to recommence the
> standards process.
We don't need to recommence a formal standard process.
What's needed is good quality CLRFIs that can be implemented
consistently by several "vendors" (both commercial and freedom sources).
The Internet was built only with RFCs...
Once a number of CLRFIs have been implemented and time-tested, in five
or ten years, a formal standard process could then officialize and
integrate the most interesting CLRFIs. (Perhaps a Common-Lisp-2010 or
Common-Lisp-2015?).
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?