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
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.
daniel.elia...@excite.com writes:
> 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.
So:
--------------------------------------------------
(defun fact (x) (if (< x 1)
1
(* x (fact (1- x)))))
(defun main ()
(format t "~A~%" (fact 100)))
--------------------------------------------------
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 C program with mpz:
============================================================
./mpz_fact
933262154439441526816992388562667004907159682643816214685929638952175999932 299156089414639761565182862536979208272237582511852109168640000000000000000 00000000
And this is just for *; there are 977 other symbols in CL…
> 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
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.
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?)
daniel.elia...@excite.com writes:
> 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?)
On 2012-04-26 15:51:00 +0000, daniel.elia...@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.
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.
Anthony Ventimiglia <ajve...@gmail.com> writes:
> 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.
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.
Anthony Ventimiglia <ajve...@gmail.com> writes:
> 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.
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.
On Wed, 25 Apr 2012 10:34:01 -0700 (PDT), Francogrex <fra...@grex.org> wrote:
> 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
On Thursday, April 26, 2012 11:48:22 AM UTC-7, Tim Bradshaw wrote:
> On 2012-04-26 15:51:00 +0000, daniel.elia...@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.
