simulating local lexical variables with symbol macros
in [Lisp]
|
Prev: Mistake in the specification of rotatef ?
Next: [ann] LTK based libraries Runtime Library 3.0 and Gestalt Items 1.1
From: Tim Bradshaw on 21 Nov 2009 14:15 On 2009-11-21 14:47:36 +0000, dan(a)telent.net said: > I would be looking at Perl (which I know) or Ruby (which I don't much, > but I reasonably expect would be up to the job). Unless you expect to > be using unicode significantly, because the unicode in ruby 1.8 is Not > There Yet. Yes, ruby would be interesting. I think I only need to deal with Unicode in the sense that I'm (again, pragmatically) expecting configuration files which are XML and the parse of these might therefore throw Unicode at me by the nature of XML However I don't think I need to worry about that too much.
From: Andrew Reilly on 21 Nov 2009 17:54 On Sat, 21 Nov 2009 14:12:27 +0000, Tim Bradshaw wrote: > CCL is a fine CL (it's what I use day to day), but I need at least x86, > SPARC, Itanium, PA-RISC and POWER as targets (and > LInux/Solaris/HP-UX/AIX as platforms), which I suspect rules it out (and > probably rules out almost any native-code thing). > > Someone else suggested C: I am not up to writing complicated > security-sensitive code in C in which I have enough confidence (runs as > root on production systems where compromises are (a) very expensive and > (b) have my name somewhere in the "responsible people" chain). There > probably are people who can do this, but it is pretty hard I think. C is, never the less, the one common factor that will hit all of those targets. The other languages that you're considering (Perl and Python) work because they're interpreted by a portable C program. So: you could try other languages that are either implemented by C interpreters (Perl, Python, ruby, LUA, CLISP, many of the schemes) or compile with C as the intermediate language (ECL, many of the schemes (chicken and gambit seem to get good raps for this sort of thing)), or have a GCC back-end (besides C, C++ has all of the security issues that you're worried about, but gcc also has Pascal, Ada and Java front ends, which might fit the bill.) Cheers, -- Andrew
From: Rob Warnock on 21 Nov 2009 19:55 Tim Bradshaw <tfb(a)cley.com> wrote: +--------------- | They got beam round LHC last night, it looks like. +--------------- Even better, they got R.F. capture and stored beam for "several minutes"!! In both directions!! [...albeit only one at a time so far.] http://blogs.discovermagazine.com/cosmicvariance/2009/11/20/circulating-beam-in-lhc-imminent/ First collisions expected "soon"... -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Tim Bradshaw on 22 Nov 2009 06:11 On 2009-11-21 22:54:30 +0000, Andrew Reilly <areilly---(a)bigpond.net.au> said: > C is, never the less, the one common factor that will hit all of those > targets. The other languages that you're considering (Perl and Python) > work because they're interpreted by a portable C program. Yes. The platforms I'm aiming at all have OSs implemented largely in C, with some small amounts of assembler. Fortunately that does not mean *I* need to write C.
From: Juanjo on 22 Nov 2009 14:30
On Nov 19, 10:55 pm, Tim Bradshaw <t...(a)cley.com> wrote: > > Looks to me like the only Lisp option would be CLISP. [...and on a separate message...] > CCL is a fine CL (it's what I use day to day), but I need at least x86, > SPARC, Itanium, PA-RISC and POWER as targets (and > LInux/Solaris/HP-UX/AIX as platforms), which I suspect rules it out > (and probably rules out almost any native-code thing). What is wrong with ECL? It already runs on x86, SPARC, Itanium, and porting to the other two targets should be pretty easy. POSIX bindings are not yet implemented natively in lisp, but it allows you to embed C statements in Lisp code: http://ecls.sourceforge.net/new-manual/re14.html Juanjo |