new lisp translators?

[Francogrex]

I know of the lisp to js (parenscript) and lisp to Dylan (ltd) translators, any updates on "new" lisp to C translators. I'm of course interested in those that translate into the run-of-the-mill human readable C code that can be compiled and run without using external lisp libraries (so not ecl or thinlisp, those have been covered in previous topics). If anyone got any news please share here thanks

[daniel....@excite.com]

I assume such C code output would have all variables based on some generic pointer - then I guess point to some cell including a tag to indicate data type, then there's a library needed for arithmetic among types and other ops among types...

I don't think it's possible to get away from a run time support library, unless you strongly constrain the input Lisp code constructs..

Then there is also the need to support live symbols and have the symbol table live...

BUT - WHAT I DO HOPE- is that you could have a partitioned library wherein only those run time parts that are referenced in the code need be included. For instance, if the symbol table is not referenced in the code (no INTERN, no SYMBOL-NAME, or the like), then the live symbol table need not be included, and any symbols directly mentioned in the code could be optimized out, like muted to unique values instead of symbols, or something.

[Pascal J. Bourguignon]

So:

--------------------------------------------------
(defun fact (x)
(if (< x 1)
1
(* x (fact (1- x)))))

(defun main ()
(format t "~A~%" (fact 100)))
--------------------------------------------------

would translate to:

--------------------------------------------------
#include <stdio.h>

int fact(int x){
if(x<1){
return(1);
}else{
return(x*fact(x-1));
}
}

int main(void){
printf("%d\n",fact(100));
return(0);
}
--------------------------------------------------

Oops, already you have to use a library, C doesn't have I/O built-in.

Let's just ignore that:

============================================================
Running the C program:
============================================================
./c_fact
0

============================================================
Running the Lisp program:
============================================================
./fact
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
============================================================


To get the same result in C, you need to use yet another library, mpz,
and then the code is not maintainable anymore:

--------------------------------------------------
#include <stdio.h>
#include <gmp.h>

mpz_t one;

void fact(mpz_ptr r,mpz_srcptr x){
if(mpz_cmp(x,one)<0){
mpz_set(r,one);
}else{
mpz_t rr;
mpz_t x_minus_1;
mpz_init(rr);
mpz_init(x_minus_1);
mpz_sub(x_minus_1,x,one);
fact(rr,x_minus_1);
mpz_mul(r,rr,x);
mpz_clear(rr);
mpz_clear(x_minus_1);
}
}

int main(void){
mpz_t r;
mpz_t arg;

mpz_init(one);
mpz_set_ui(one,1);

mpz_init(r);
mpz_init(arg);
mpz_set_ui(arg,100);
fact(r,arg);
gmp_fprintf(stdout,"%Zd\n",r);
mpz_clear(r);
mpz_clear(arg);
return(0);
}
--------------------------------------------------

============================================================
Running the C program with mpz:
============================================================
./mpz_fact
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000




And this is just for *; there are 977 other symbols in CL…

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Tim Bradshaw]

Why is such a thing interesting? As someone else has pointed out it's
virtually impossible to translate a language like CL to run-of-the-mill
C because CL maps so poorly onto C (for stance something like (defun
foo (x y) (+ x y)) would require an enormous implementation in C).

To translate to readable C at all would really require a much
lower-level Lisp - one whose arithmetic mapped much more closedly onto
C's, for instance, as well as many other things (there are or were such
languages I think which were used to port bigger environments). But
even then, the question would be: why? I can see that Lisp systems
which used C as an intermediate language were at least once
interesting, and might still be to support very small embedded systems
(which might now be equivalent to the kind of departmental mini they
once were useful for), but those systems never produced readable C.

[daniel....@excite.com]

On Thursday, April 26, 2012 5:36:59 AM UTC-4, Tim Bradshaw wrote:
> To translate to readable C at all would really require a much
> lower-level Lisp - one whose arithmetic mapped much more closedly onto

> C's...


Yes, like Emacs Lisp. Or else you could say the translator uses native C numbers only when the types are so specified in CL, otherwise the translator does something like Pascal showed earlier.

Point is for the runtime to be minimally constructed - but that minimum could be huge depeding on features used in the Lisp source.

> But
> even then, the question would be: why? I can see that Lisp systems
> which used C as an intermediate language were at least once

> interesting, and might still be to support very small embedded systems...


That is precisely my own interest, actually - then I could do coding and test benching on PCs, and being in Lisp would facilitate the test bench environments. Even substituting the PC test bench into the embedded environment (for instance when I/O is GbEthernet). Then gen code for the embedded processor.

If the embedded runtime could end up with a basic symbol table - perhaps read only with a subset of symbols included - supporting a REPL, then that could be even better for embedded debugging and/or system control.


> ... but those systems never produced readable C.

Personally, I don't care about readability as Francogrex mentioned; only automatic minimality.. (Is that a word?)

[Pascal J. Bourguignon]

Just use libecl.so

[Tim Bradshaw]

On 2012-04-26 15:51:00 +0000, daniel....@excite.com said:

> Personally, I don't care about readability as Francogrex mentioned;
> only automatic minimality.. (Is that a word?)

Tree shaking is how I'd think of it.

[Tim Bradshaw]

On 2012-04-26 15:51:00 +0000, daniel....@excite.com said:

> That is precisely my own interest, actually - then I could do coding
> and test benching on PCs, and being in Lisp would facilitate the test
> bench environments. Even substituting the PC test bench into the
> embedded environment (for instance when I/O is GbEthernet). Then gen
> code for the embedded processor.

I used to wonder about writing a Lisp syntax front-end for something
like C: so you'd actually *be* writing C, but you'd write it in sexps.
You could then have a runtime for it in your development enviromnent
but finally have the thing generate C for the target. I bet that has
been done in fact.

[Anthony Ventimiglia]

I should preface this with saying that as much as I would prefer to code in Lisp all the time, I find things like parenscript, cl-who, S-sql and clsql disgusting. I do however see how they can be useful to some people. For example javascript at this point is essentially the assembler language of web browsers, with a few big bonuses. It's basically standardized (unlike assembler which is specific to the processor) and it is a high level (and quite lisp like) language.

I hate that I see no real reason to do something like this, but what's the point of using Lisp to compile code into a language (C)that then has to be compiled and linked again? It may be a bit interesting (and masochistic) to undertake such a project, but not very useful. I could see if you wanted to build a lisp .so library with symbols exported in a way that they could be called from C code, similar to the way some parts of C applications are coded directly in assembler.

[Daimrod]

I like Postmodern to play with a PostgreSQL database from SLIME-REPL, I
find it way more nicer than the available REPL or an UI like phppgadmin.
Also, writing SQL queries with quasiquotation is much nicer than
concatenating strings.

I'm not (yet?) a big fan of Parenscript, though it makes the integration
of XHTML and Javascript consistent with cl-who or cl-markup.
i.e. I keep the View clean in s-exp and call .js written in plain Javascript.

[Pascal J. Bourguignon]

One real reason is that sexp programming lets you avoid SQL injection
(and similar bugs). Since sexps are always fully parenthesized, or more
exactly since manipulating sexps is actually manipulating a hierarchical
data structure, you don't have the problems you can have when
manipulating a linear data structure such as a string, where an
"ill-formed" string can change its own structural meaning.

[ddd]

For scheme have a look at:
http://people.csail.mit.edu/jaffer/Schlep/

[tar...@google.com]

On Thursday, April 26, 2012 11:48:22 AM UTC-7, Tim Bradshaw wrote:
> On 2012-04-26 15:51:00 +0000, daniel....@excite.com said:
>

> &gt; That is precisely my own interest, actually - then I could do coding
> &gt; and test benching on PCs, and being in Lisp would facilitate the test
> &gt; bench environments. Even substituting the PC test bench into the
> &gt; embedded environment (for instance when I/O is GbEthernet). Then gen
> &gt; code for the embedded processor.

>
> I used to wonder about writing a Lisp syntax front-end for something

> like C: so you&#39;d actually *be* writing C, but you&#39;d write it in sexps.

> You could then have a runtime for it in your development enviromnent
> but finally have the thing generate C for the target. I bet that has
> been done in fact.

Sort of.
See Stella: http://www.isi.edu/isd/LOOM/Stella