121–130 of 164 posts
Earlier quoted context omitted.
SBCL does not create binaries per se, but dumps the program image. While it practically is a binary, it's not equal to an executable that a conventional compiler/linker produces.
I wonder why tree shaking is so ineffective. Is that because any symbol could be accessed dynamically at runtime?
Earlier quoted context omitted.
Don't forget, even 2 MB was still a somewhat inconvenient size when floppy disks were only at 1.44 MB capacity.
Floppy disks were well on their way out, and people were still complaining about a 2 MB footprint.
> And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable. Oh how the definition of "small" has changed. I actually would like to know how they managed to make something like this so big . To compare, LuaJIT is about 400 KB, and that includes the Lua standard library, a JIT almost certainly more advanced than Pixie's current one, an incremental GC, a…
Well, for comparison "Hello World" in Common Lisp, using SBCL on x64 Linux creates a ~70 Mb binary, but nobody would ever claim it's small :-) Unfortunately, for an arbitrary CL program it's impossible to tell for sure how much of the CL compiler and standard library it will need at run time, so SBCL takes the easy route and just includes everything. Some of the commercial Lisp compilers are a lot smarter at strippin…
Other examples of CL compilers not saving an image are ECL and WCL.
The ECL manual had the terminology a bit wrong, but it actually does not dump an image.
https://common-lisp.net/project/ecl/static/manual/ch34.html#...
WCL:
https://github.com/wadehennessey/wcl
> For example, the executable for a Lisp version of the canonical ``Hello World!'' program requires only 20k bytes on 32 bit x86 Linux.
Alas, this ambitious project appears to be not currently under active development. My largely uninformed armchair opinion as to why, is that the author is very performance-driven, and in the end it's very difficult to beat the JVM performance-wise. Lesson: if you want high-perf Clojure, you already have it on the JVM. Personally, I think there's room for a simple small native Clojure implementation where performance…
I'm generally in demand of small, quick startup, easy-to-embed languages that aren't Lua (I can't stand Lua; I feel like every time I've had to deal with Lua code was far more painful than reasonably possible). There's mruby and maybe a couple others. I was hoping Pixie might be another contender in that space, but it doesn't seem to be after all (or if it is, it's very poorly documented to that effect). I've been ti…
Alas, this ambitious project appears to be not currently under active development. My largely uninformed armchair opinion as to why, is that the author is very performance-driven, and in the end it's very difficult to beat the JVM performance-wise. Lesson: if you want high-perf Clojure, you already have it on the JVM. Personally, I think there's room for a simple small native Clojure implementation where performance…
I'm generally in demand of small, quick startup, easy-to-embed languages that aren't Lua (I can't stand Lua; I feel like every time I've had to deal with Lua code was far more painful than reasonably possible). There's mruby and maybe a couple others. I was hoping Pixie might be another contender in that space, but it doesn't seem to be after all (or if it is, it's very poorly documented to that effect). I've been ti…
Earlier quoted context omitted.
I'm generally in demand of small, quick startup, easy-to-embed languages that aren't Lua (I can't stand Lua; I feel like every time I've had to deal with Lua code was far more painful than reasonably possible). There's mruby and maybe a couple others. I was hoping Pixie might be another contender in that space, but it doesn't seem to be after all (or if it is, it's very poorly documented to that effect). I've been ti…
A list that I maintain might help you find one: https://github.com/dbohdan/embedded-scripting-languages . Personally, I am a fan of Jim Tcl ( http://jim.tcl.tk ), especially for when you need a small interpreter that knows how to interact with its Unixy environment (i.e., the file system, processes, sockets and UTF-8 text data) out of the box.
I'm the original author of pixie, and yeah, I'm a bit surprised to see this hit HN today. It should be mentioned that I put about a year of work into this language, and then moved on about a year or so ago. One of the biggest reasons for my doing so is that I accomplished what I was looking for: a fast lisp that favored immutability and was built on the RPython toolchain (same as PyPy). But in the end the lack of sup…
As a somewhat different data point, we've been developing pycket, an implementation of Racket on top of rpython, for the past 3 years, and while it faces many of the same challenges, we've been very happy with the results. The JIT can remove almost all of the intermediate data structures caused by the functional nature of the language, and we support tail calls and first class continuations. Overall, pycket is almost…
I use Gambit-C scheme for most of my scheme needs because of the speed, but it seriously lacks in libraries, that Racket has in abundance.
Earlier quoted context omitted.
To me Rebol/Red is more lisp than some other lisps out there. It doesn't have so much parens, true, but the idea of like code is data and DLS possibilities are huge things.
First I've heard of Red. Does it implement 'readable' [1] or is it a [parallel school of thought] (can't think of right phrase here but you get what I mean)? Also has anyone tried to create a 'readable' [1] flavour of Clojure yet? If not, why is that, do lispers consider all the parens to really not be a barrier? [1] http://readable.sourceforge.net/
When writing lisp your editor should help you at least a bit to make things enjoyable. They can help a lot, but doesn't have to help much; I found for myself that if the editor just highlights matching parens, I'll be very effective.
Earlier quoted context omitted.
In lisp eval does not take a string as its input, but a form , i.e. a linked list, containing the program to execute. Maybe you confuse it with JavaScript or Python eval (or the like) where the function both reads in a string and runs the program it parsed from that string. There are diverse functions to convert a string to a symbol in different lisps.
Perhaps i'm rusty. in this case (funcall #'+ 1 2 3) or the more scheme-ish (apply '+ '(1 2 3)) i think the symbol plus gets evaluated to # and then is called with 1 2 3 - CL will do apply, of course, not sure about scheme and funcall. I'm totally willing to accept my mental model is wrong, i don't have an interpreter handy. So if that's true, you run into this problem: (funcall (string->symbol "+") 1 2 3) (apply (str…
Treeshakers are generally used for application delivery in Lisp. When you do that, then one usually limits the amount of use of runtime dynamics. Typically you can tell the treeshaker what to remove or what to keep: the compiler, the symbol table, debugging info, etc etc.
Allegro CL and LispWorks have extensive facilities for this.
http://franz.com/support/documentation/10.0/doc/delivery.htm
http://www.lispworks.com/documentation/lw70/DV/html/delivery...
Earlier quoted context omitted.
First I've heard of Red. Does it implement 'readable' [1] or is it a [parallel school of thought] (can't think of right phrase here but you get what I mean)? Also has anyone tried to create a 'readable' [1] flavour of Clojure yet? If not, why is that, do lispers consider all the parens to really not be a barrier? [1] http://readable.sourceforge.net/
No, the parens don't constitute a barrier of any kind, really. Reading lisp fluently requires very consistent indentation, though. Then you see where an expr starts and where it ends (with nestings and all) without counting any parens whatsoever. When writing lisp your editor should help you at least a bit to make things enjoyable. They can help a lot, but doesn't have to help much; I found for myself that if the edi…
I have tried a structure editor for Haskell but I found it pretty counterintuitive. I wonder if structure editing just assumes a language with very little syntax.