Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Will, thanks for you long explanation! On Fri, May 9, 2014 at 7:59 PM, Rick Lyman lyman.r...@gmail.com wrote: flow.c:60:37: error: fields must have a constant size: 'variable length array in structure' extension will never be supported struct {any sym; any val;}

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
On Mon, May 12, 2014 at 08:06:57AM +0200, Alexander Burger wrote: The problem with this is that is horribly inefficient. The dynamic version myStruct bnd[length(x)]; simply decrements the stack pointer by length(x) * sizeof(myStruct) (which is a single machine instruction!), while the

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Jakob Eriksson
And this is an excellent example of PicoLisp going the extra mile. Instead of handling C as the lowest abstraction, going to the actual machine. I imagine other interpreted languages could be faster if designed with this attention to detail. On 12 maj 2014 08:24:13 CEST, Alexander Burger

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread andreas
And this is an excellent example of PicoLisp going the extra mile. Instead of handling C as the lowest abstraction, going to the actual machine. I imagine other interpreted languages could be faster if designed with this attention to detail. Exactly! Thank you Alex, for the insightful

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Christophe Gragnic
On Mon, May 12, 2014 at 8:06 AM, Alexander Burger a...@software-lab.de wrote: Hi Will, thanks for you long explanation! Right, and thanks to all for this interesting journey in the internals. The problem with this is that is horribly inefficient. I'm interested by a clang compatible version,

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Christophe, I'm interested by a clang compatible version, just to see what emscripten will make of it. For the sake of the experience I'm gonna try anyway. Nice! Probably much more interesting (and useful) would be to port the pil64 assembler to clang. I considered that initially, but

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
On Mon, May 12, 2014 at 5:40 AM, Christophe Gragnic christophegrag...@gmail.com wrote: I'm interested by a clang compatible version, just to see what emscripten will make of it. For the sake of the experience I'm gonna try anyway. chri, I'm also interested in a emscripten compiled

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Joe, struct {any sym; any val;} bnd[100]; ... It builds and runs. I don't see any obvious consequences yet. I would have assumed something like this would fail: (setq Z (make (for N 120 (link N This doesn't actually use any variable length array. You may instead try (be sure to set

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
Hi Alex, Thanks for the reply and the details. On Mon, May 12, 2014 at 9:56 AM, Alexander Burger a...@software-lab.dewrote: Alex, is there a reasonably safe upper bounds that can be used instead of it being determined dynamically? Hmm, what is safe? In any case you use the generality of

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Christophe Gragnic
On Mon, May 12, 2014 at 2:16 PM, Joe Bogner joebog...@gmail.com wrote: I was able to compile miniPicoLisp on windows under clang. I basically just replaced all instances of variable array initialization, such as: struct {any sym; any val;} bnd[length(x = car(expr))+3]; with //TODO struct

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
I added my changes to this repo: https://github.com/joebo/miniPicoLisp This commit has everything needed to build on clang on windows: https://github.com/joebo/miniPicoLisp/commit/e34b052bc9c8bd8fa813833294a5830a69ffb56e I'm using: C:\Users\jbogner\Downloads\miniPicoLisp\srcclang -v clang

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
On Mon, May 12, 2014 at 11:50 AM, Christophe Gragnic christophegrag...@gmail.com wrote: I just set up a repository on github (Alex being OK) and reported my issue here: https://github.com/Grahack/minipicolisp/issues/1 I think the main difference is your Makefile

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Jorge Acereda
Why not alloca()? El 12 May 2014, a las 16:31, Joe Bogner joebog...@gmail.com escribió: The proper solution is likely to use malloc/fre -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread William Cushing
Ah, I read too quickly, didn't notice/realize the length(...) subexpression was the variable part. If you don't have alloca, and you don't want to use assembler, and you don't want the overhead of malloc/free, and you don't want to, or literally can't, risk demons flying out of your nose:

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Christophe Gragnic
On Mon, May 12, 2014 at 7:03 PM, Joe Bogner joebog...@gmail.com wrote: I think the main difference is your Makefile Instead of: clang $*.c I'm doing this: $(CC) -w -c $*.c The -w suppresses warnings Great. It works now. I fixed the warnings and didn't add the -w flag though

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Will, If you don't have alloca, and you don't want to use assembler, and you don't want the overhead of malloc/free, and you don't want to, or literally can't, risk demons flying out of your nose: typedef char byte; byte hack[HACK_SIZE]; // hack is meant to remind one of stack byte *