101–110 of 112 posts
Since this is about a pre-alpha language, it would be helpful for future web searchers to have a date in the title.
Sorry to be a little off topic but I think search engines should penalize material that is not clearly marked with date of creation.
Earlier quoted context omitted.
"Rust-like LISP" The phrase was ambiguous. I meant a LISP w/ safe, memory model like Carp. There's already LISP's in the past and present for OS's. There's also projects that restrict the power of languages to get better efficiency in low-level work. So, more of the latter with Rust's memory model might be advantageous. The former with their flexibility could be built on top of that same language with a low-latency G…
> My recommendation to use one close to the metal like PreScheme with Rust-style safety that outputs C for LLVM attempts to address that. Wouldn't it be easier to develop a very basic OS core in Rust, and a simple Lisp 1.5 interpreter written in Rust as foundation for a full blown Lisp?
Earlier quoted context omitted.
Honest question: is immutability complicated in Clojure because it's hard, or because it's running in a virtual machine with no meaningful support for it? The Erlang VM has immutability deeply baked in, and it just works(™).
Erlang is typically used for problem domains (eg. fault-tolerant servers, network brokers & routers, message queues) where immutability fits the problem domain pretty well. If you want fault tolerance, you typically need to store all your state externally anyway so you can replicate it, and make all your logic stateless so you can restart & re-run it if a node fails. There are some problem domains - eg. GUI software,…
The solution has been to move it down the stack, as visible on all Apple, Google and Microsoft OSes, even on Qt.
It is there, making full use of the hardware in all performance critical code, but then the actual GUI code gets written in something else.
This project looks really good. I would love to have a clojure inspired lisp that's fast and doesn't require the JVM.
You might try Avian or Multi-OS Engine for embedding a JVM within your program. [0] https://github.com/ReadyTalk/avian [1] https://software.intel.com/en-us/multi-os-engine
Earlier quoted context omitted.
Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.
You might be thinking of the optimization for constant pool references: https://medium.com/@jlouis666/an-erlang-otp-20-0-optimizatio...
Very excited about Carp. In general I like the simplicity of Lisp but ironically I'm not a fan of dynamic typing. Carp may be a real innovation. A bit surprised though that the Carp C runtime functions are not namespaced. With names like `IO_println` there's a risk of clashes. Unless the compiler is doing some tricks to hide names?
Perhaps it's my OCD, but a Lisp with uppercase namespaces, etc. just rubs me the wrong way.
> Carp compiles to C...It also likely doesn’t matter much, because chances are your machine has a C compiler. Whether or not I can compile the code is only one of the many concerns to consider when picking between C and LLVM.
That’s quite true, but from the users perspective, it mostly doesn’t matter, at least in my mind. For people interested in the internals—which is an increasing amount of the user base—, and the people working on the compiler, it most definitely is a concern.
Earlier quoted context omitted.
> does not fit the Lisp philosophy... all the borrowing story comes from a basis mutability I found this to be a confusing statement until I realized you were talking about Clojure. Common Lisp condones mutation, and a borrowing model could be helpful for optimizing memory allocations.
You are right that a lot of Lisps consider themselves more procedural than functional and I was extrapolating Clojure there. (In my defense, the Scheme community is also very functional and immutable oriented)
Earlier quoted context omitted.
The selling point of lisp is macros, and macros alone. Different dialects will have different characteristics: Common Lisp is dynamically typed and usually makes heavy use of mutation, others like Lux are purely functional and statically typed. > wouldn't it just be Rust with parenthesis? That's pretty much what it is.
Yes, but will macros retain their power in a statically typed environment?