As an exercise in cross-compiling and working up makefiles, I've been
trying to bring a Lisp to life on our MIPS R3000 breadboard using
RTEMS- essentially a flat memory model, multithreaded RTOS. I
succeeded in hacking up Xlisp 3.04 and getting it to run, but would
prefer something more like CLISP.
Since the build host is x86 Linux and the target is a MIPS with a
"Posixy" but incomplete C library, to begin with, I'm not sure how to
solve the image dumping problem, which pretty much wipes out CLISP and
even xlisp-stat. The other problem is both of these by default
require a more complete POSIX environment than the RTOS can supply.
My preference is to end up with a somewhat "small" Lisp environment to
be linked in and invoked as a limited number of threads among a number
of others which together form the embedded application. IPC is to be
worked out at some later time. My goal is CL compliance first,
size/features/"efficiency" second.
If anyone has been down this road and might supply some hints, I'd
really appreciate it.
Thanks,
Greg Menke
Greg Menke <··········@mindspring.com> writes:
> As an exercise in cross-compiling and working up makefiles, I've been
> trying to bring a Lisp to life on our MIPS R3000 breadboard using
> RTEMS- essentially a flat memory model, multithreaded RTOS. I
> succeeded in hacking up Xlisp 3.04 and getting it to run, but would
> prefer something more like CLISP.
>
> Since the build host is x86 Linux and the target is a MIPS with a
> "Posixy" but incomplete C library, to begin with, I'm not sure how to
> solve the image dumping problem, which pretty much wipes out CLISP and
> even xlisp-stat. The other problem is both of these by default
> require a more complete POSIX environment than the RTOS can supply.
>
> My preference is to end up with a somewhat "small" Lisp environment to
> be linked in and invoked as a limited number of threads among a number
> of others which together form the embedded application. IPC is to be
> worked out at some later time. My goal is CL compliance first,
> size/features/"efficiency" second.
>
> If anyone has been down this road and might supply some hints, I'd
> really appreciate it.
>
> Thanks,
>
> Greg Menke
Have you checked ECLS <http://ecls.sourceforge.net/> and librep
<http://librep.sourceforge.net/>? I have no idea if they will be of
any help to you, just wanted to make sure you haven't missed
them. (librep doesn't purport to be a CL, though.)
Good luck,
Edi.
Ah, I mis-remembered ECLS- I knew of it but somehow thought it was
more "Lisp-like" instead of trying to be real CL. I'll give it a
closer look.
Thanks,
Gregm
>
> Have you checked ECLS <http://ecls.sourceforge.net/> and librep
> <http://librep.sourceforge.net/>? I have no idea if they will be of
> any help to you, just wanted to make sure you haven't missed
> them. (librep doesn't purport to be a CL, though.)
>
Greg Menke <··········@mindspring.com> writes:
> Ah, I mis-remembered ECLS- I knew of it but somehow thought it was
> more "Lisp-like" instead of trying to be real CL. I'll give it a
> closer look.
>
> Thanks,
>
> Gregm
>
>
> >
> > Have you checked ECLS <http://ecls.sourceforge.net/> and librep
> > <http://librep.sourceforge.net/>? I have no idea if they will be of
> > any help to you, just wanted to make sure you haven't missed
> > them. (librep doesn't purport to be a CL, though.)
> >
Although I have no personal experience with it, you might want to have a look
at ThinLisp as well. It allows you to develop on a lisp platform and generate a
platform-neutral C program from the lisp code. It's at:
http://sourceforge.net/projects/thinlisp/
--
Bill Clementson
·······@attbi.com writes:
> Although I have no personal experience with it, you might want to
> have a look at ThinLisp as well. It allows you to develop on a lisp
> platform and generate a platform-neutral C program from the lisp
> code. It's at: http://sourceforge.net/projects/thinlisp/
Thin Lisp is not Common Lisp. It may look and feel like Common Lisp
in some ways, but it is missing a significant amount of essential
functionality. For example, it has no garbage collector, no bignums,
no complex numbers, and does not detect overflow in arithmetic
operations. If you want to compute "without a net" you may as well
compile all your code with (optimize (speed 3) (safety 0)).
In article <···············@panix3.panix.com>, Carl Shapiro
<········@panix.com> wrote:
>Thin Lisp is not Common Lisp. It may look and feel like Common Lisp
>in some ways, but it is missing a significant amount of essential
>functionality. For example, it has no garbage collector, no bignums,
>no complex numbers, and does not detect overflow in arithmetic
>operations.
Anorexia LispOSa.
On 08 Dec 2001, Edmund Weitz wrote:
[...]
> Have you checked ECLS <http://ecls.sourceforge.net/> and librep
> <http://librep.sourceforge.net/>? I have no idea if they will be of
> any help to you, just wanted to make sure you haven't missed
> them. (librep doesn't purport to be a CL, though.)
Having attempted to do some non-trivial work with REP and, more
specifically, the Sawfish window manager built on top of it, I would
hesitate to recommend it to anyone.
It's got all the real-world functionality of Scheme without the language
purity. Not that I am biased or anything. ;)
I found that it's module system was very nice to work with and that the
REPL was reasonably well done.
Compared to Common Lisp, though, it lacked the distinction of function
and variable bindings, encouraged the '(define (foo bar))' and
'(define foo)' notations, which are more ambiguous[1] and felt ...
clunky to work with.
`define' comes directly from Scheme, incidentally, so the semantics from
there apply.
I actually found working with Scheme to be a more pleasant experience.
It had, at least, ideological purity throughout, unlike REP which felt
very much like Emacs Lisp trying very hard to become Scheme...
OTOH, I am not an 313773 Lisp hacker or anything, and I had a less than
fun time working in Sawfish for anything non-trivial, so I may be biased
on the topic.
Daniel
Footnotes:
[1] to my Emacs and Common Lisp trained eyes, at least.
--
We close our eyes and look in opposite direction.
We ignore the threats and hope they'll go away.
We refuse to pay attention to the dangers we create
in the name of our fathers we kill our children.
-- Covenant, _Theremin_
Daniel Pittman <······@rimspace.net> writes:
> Having attempted to do some non-trivial work with REP and, more
> specifically, the Sawfish window manager built on top of it, I would
> hesitate to recommend it to anyone.
>
> It's got all the real-world functionality of Scheme without the language
> purity. Not that I am biased or anything. ;)
Oh no, not at all.
> Compared to Common Lisp, though, it lacked the distinction of function
> and variable bindings, encouraged the '(define (foo bar))' and
> '(define foo)' notations, which are more ambiguous[1] and felt ...
> clunky to work with.
>
> `define' comes directly from Scheme, incidentally, so the semantics from
> there apply.
There are reasons in Scheme for how the 'define' notation works.
Specifically,
(define foo <whatever>)
is syntactically equivalent to
(set! foo <whatever>)
within any scope[1]. Thus
(define foo (lambda (x) <...>))
is just set!ing foo to be some function that takes x and does
something. The more odd
(define (foo x) <...>)
notation is a shorthand for definitions as in the preceding example.
This notation (sometimes called 'MIT-style define') is recursively
equivalent, but I don't remember the proof offhand -- ask on
comp.lang.scheme. So there is a reason for it, but to the non-Schemer
it looks weird.
LibREP is guilty of pretending to the Scheme throne if it uses this
notation, mostly because I'd guess that its semantics don't allow for
the recursive equivalence of the two notations, ie that the latter is
just a syntactic hack in the reader.
> I actually found working with Scheme to be a more pleasant experience.
> It had, at least, ideological purity throughout, unlike REP which felt
> very much like Emacs Lisp trying very hard to become Scheme...
Indeed. If you want a real Scheme-based window manager try SCWM
(http://scwm.sourceforge.net) which uses Guile with windowing
extensions, and has an extension that implements constraits applicable
to the arrangement and management of windows. It's also extremely
stable and very extensible. I've used it continuously for the last
three or four years with only the very occasional problem.
[1]: Not sure offhand whether the define == set! relation is true
below the top level, but I think it is. Correct me if I'm wrong.
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
On 16 Dec 2001, James A. Crippen wrote:
> Daniel Pittman <······@rimspace.net> writes:
[...]
>> `define' comes directly from Scheme, incidentally, so the semantics
>> from there apply.
>
> There are reasons in Scheme for how the 'define' notation works.
> Specifically,
>
> (define foo <whatever>)
>
> is syntactically equivalent to
>
> (set! foo <whatever>)
>
> within any scope[1].
It's lexically scoped in libREP Lisp, FWTW. This would suggest that
either (a) I misunderstood how (define (...)) works in Scheme (likely)
or (b) libREP isn't like Scheme either, which wouldn't shock me. :)
[...]
>> I actually found working with Scheme to be a more pleasant
>> experience. It had, at least, ideological purity throughout, unlike
>> REP which felt very much like Emacs Lisp trying very hard to become
>> Scheme...
>
> Indeed. If you want a real Scheme-based window manager try SCWM
> (http://scwm.sourceforge.net) which uses Guile with windowing
> extensions, and has an extension that implements constraits applicable
> to the arrangement and management of windows.
I tried to try this, because I got sick to death of the bugs is SawFish
and didn't have the stomach, heart or level of masochism to fix it
myself. I would prefer to port it to CL or something.
Sadly, my efforts at getting SCWM to work ended in tears: the lowest
level graph toolkit has become relatively non-free, making the
constraints toolkit more difficult to build than I had time for.
This, in turn, removed the motivation to try SCWM. I like the idea of a
Lisp under my WM, because it's /that/ critical to my user experience,
but wasn't strongly motivated by Scheme on it's own.
> It's also extremely stable and very extensible. I've used it
> continuously for the last three or four years with only the very
> occasional problem.
Cool. Actually, if you happened to have the source for the STL-based
graph toolkit and sent it to me privately, at this address, I would be
grateful.
That aside, I didn't note a big contributed code base: where did I miss
it?
Daniel
--
Quidquid latine dictum sit, altum viditur.
Daniel Pittman <······@rimspace.net> writes:
> Cool. Actually, if you happened to have the source for the STL-based
> graph toolkit and sent it to me privately, at this address, I would be
> grateful.
I don't actually use the constraints. So I don't have that. But I'm
perfectly happy without the constraints.
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
Daniel Pittman <······@rimspace.net> writes:
> This, in turn, removed the motivation to try SCWM. I like the idea of a
> Lisp under my WM, because it's /that/ critical to my user experience,
> but wasn't strongly motivated by Scheme on it's own.
Have you checked out Eclipse? <http://ww.telent.net/cliki/eclipse> I
think I had it running once, but I'm happy enough with WindowMaker
that I don't need to spend my time futzing with other WMs. People
with more prone to being interested in things like WMs and/or people
who aren't happy with their WM may be more interested, though.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Daniel Pittman <······@rimspace.net> writes:
> On 16 Dec 2001, James A. Crippen wrote:
[Scheme/lisp-based window managers]
> > Indeed. If you want a real Scheme-based window manager try SCWM
> > (http://scwm.sourceforge.net) which uses Guile with windowing
> > extensions, and has an extension that implements constraits applicable
> > to the arrangement and management of windows.
>
> I tried to try this, because I got sick to death of the bugs is SawFish
> and didn't have the stomach, heart or level of masochism to fix it
> myself. I would prefer to port it to CL or something.
>
> Sadly, my efforts at getting SCWM to work ended in tears: the lowest
> level graph toolkit has become relatively non-free, making the
> constraints toolkit more difficult to build than I had time for.
>
> This, in turn, removed the motivation to try SCWM. I like the idea of a
> Lisp under my WM, because it's /that/ critical to my user experience,
> but wasn't strongly motivated by Scheme on it's own.
There's also GWM, a fairly old experiment in WM development (the
target was to produce a Wm that was easy to give new behaviours at
need and also do taht "run time"). It uses a lisp-like language named
WOOL and comes with a fairly good library of stuff you can look at and
play with.
//Ingvar
--
(defmacro fakelambda (args &body body)
`(lambda ,args (labels ((me ,args ,@body)) (me ,@args))))
(funcall (fakelambda (a b) (if (zerop (length a)) b (format nil "~a~a"
(aref a 0) (me b (subseq a 1))))) "Js nte iphce" "utaohrls akr")
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> There's also GWM, a fairly old experiment in WM development (the
> target was to produce a Wm that was easy to give new behaviours at
> need and also do taht "run time"). It uses a lisp-like language named
> WOOL and comes with a fairly good library of stuff you can look at and
> play with.
WOOL is actually an OOish language. It's not Common Lisp but it is a
Lisp. I used it for a while before I converted to SCWM. GWM was
pretty good for its time but I don't think it's currently maintained.
There was IINM an attempt to bring WOOL more into line with CL, but I
have no clue where that work went.
Similar possibilities would be extending say ECL with CLX and some
window management extensions. That would get you in the same
direction if you wanted a truly CL-based window manager (which I'd
love to have). SCWM would be a good place to start with for primitive
design because they've had to do the same thing, graft the WM
primitives into an existing language implementation (rather than how
GWM did, which was build a language around the WM primitives).
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
On 16 Dec 2001 19:33:35 -0900, James A Crippen wrote:
> There are reasons in Scheme for how the 'define' notation works.
> Specifically,
> (define foo <whatever>)
> is syntactically equivalent to
> (set! foo <whatever>)
> within any scope[1].
Assuming you mean semantically equivalent, no it isn't. I'm pretty
sure that `set!' even at top-level isn't legal unless a `define' has
already been evaluated for that variable (though implementations may
allow it anyway, just as Common Lisp implementations generally define
top-level SETQ to do something more or less useful); i.e., it's like
DEFPARAMETER in CL, but without special variables.
At other-than-top-level scope, `define' is only allowed at the
beginning, where it's essentially equivalent to wrapping the following
code in a LABELS form in Common Lisp (but it's single-namespace, so
you can define variables as well as functions this way...I'm not sure
whether if you have two `define' forms they're supposed to act like
they're in the same LABELS-like form (I don't recall what Scheme calls
its version of LABELS...letrec, maybe? Or letrec-something) or one
inside the other; ISTM either way is broken: you'd want them in the
same one if they're defining functions, so they can call each other,
but you wouldn't want that if they're defining variables because then
the order of evaluation isn't defined in Scheme...)
--
Cogito ergo I'm right and you're wrong. -- Blair Houghton
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
In article <··············@mycroft.actrix.gen.nz>,
Paul Foley <·······@actrix.gen.nz> wrote:
>
>At other-than-top-level scope, `define' is only allowed at the
>beginning, where it's essentially equivalent to wrapping the following
>code in a LABELS form in Common Lisp (but it's single-namespace, so
>you can define variables as well as functions this way...I'm not sure
>whether if you have two `define' forms they're supposed to act like
>they're in the same LABELS-like form (I don't recall what Scheme calls
>its version of LABELS...letrec, maybe? Or letrec-something) or one
>inside the other; ISTM either way is broken: you'd want them in the
>same one if they're defining functions, so they can call each other,
>but you wouldn't want that if they're defining variables because then
>the order of evaluation isn't defined in Scheme...)
It doesn't matter what the order of evaluation is in
the implementing Scheme, because the values are
assigned to the variables in a sequence
of assignments, not as the arguments to an imagined
lambda-expression (as for 'let', say).
(let ()
(define x 9)
(define y x)
;
(list x y))
is operationally like
(let ()
(let ((x 'dont-care)
(y 'dont-care))
(set! x 9)
(set! y x)
;
(list x y))
The order of evaluation of the two 'dont-care's in the
'let' may change across Scheme impls, but that doesn't
affect the result of the expression in any of them.
--d