ferocity
coalton
ferocity | coalton | |
---|---|---|
7 | 84 | |
6 | 1,011 | |
- | 3.8% | |
2.6 | 8.4 | |
almost 2 years ago | 6 days ago | |
Java | Common Lisp | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ferocity
-
Java JEP 461: Stream Gatherers
The advantage of the static import DSL is that it is more composable: anyone else can define operators that interoperate with my operators without the complexity of the scheme linked above not to mention more generality. This goes not just for the low level operators like "filter" that you might want to supplement but the many more operators you can write that are implemented out of mine.
I prototyped an API that works in the same direction as streams by having something like
https://paulhoule.github.io/pidove/apidocs/com/ontology2/pid...
in that it wraps all Iterables returned by my methods and has not just the teardown facility but also all the operators attached as instance methods which lets you write the chaining style you ask for that I know is in demand.
If I was going to go any further on pidove it would have involved more use of code generation and this system
https://github.com/paulhoule/ferocity
which was supposed to be a code generator for writing code generators, and it could code generate stubs that would let you write expression trees in Java as S-expressions and build them up into methods and either compile the code to real Java source code or execute the methods by evaluating the expression tree in place.
Like common LISP you can write syntactic macros in that that metalanguage because an Expression> can be evaluated at compile time, one of quite a few concepts like "quoting" that I encountered in that spike.
The idea was ferocity would get to the point where it synthesizes a more complete and perfect pidove.
-
TypeScript please give us types
but you can't have an overload that takes two differently parameterized expressions, this lets you write Java code in a lisp-like syntax that can be metaprogrammed on:
https://github.com/paulhoule/ferocity/blob/main/ferocity-std...
that project got me thinking a lot about the various ways types manifest in Java and I made the discovery that when you add Expression types you practically discover an extended type systems where there are many things that are implied by the existence of ordinary Java types.
-
Overinspired?
I find this alien to my point of view. On the other hand, my side projects aren't driven by FOMO but are more like the "special interests" of autistic people.
Most of the time I have three side projects going on, maybe two of which are really getting the attention they deserve and one that is languishing. (See my profile to see about my current three.) Occasionally I get inspired to spend 1-4 weekends on some sudden inspiration, of which
https://github.com/paulhoule/pidove
came to completion but
https://github.com/paulhoule/ferocity
probably won't. The project I'm working the hardest on now is something that I was baffled that it didn't exist 18 years ago but felt compelled to do something out because of the Twitterinsanity last December and it turned out the technological conditions right now make it the perfect time to work on.
-
Typed Lisp, a primer (2019)
I have hacked off and on on this
https://github.com/paulhoule/ferocity
which lets you write extended Java in a lispy syntax. It generates stubs for the standard library and other packages you choose, unerasing types by putting them into method names. It works pretty well with IDEs but there are still problems w/ type erasure such that some kinds of type checking can't be done by the compiler working directly on the lispy Java, probably I wouldn't implement newer features such as pattern matching that are dependent on type inference to work, though lambda definitions are feasible if you give specific types.
The 'extended' bit was almost discovered instead of invented in that it is pretty obvious that you need quote and eval functions such that you can write lispy Java programs that manipulate Java expressions. Said expressions can be evaled at runtime with a primitive interpreter or incorporated into classes that are compiled w/ Javac. The motivation of the thing was to demonstrate Java-embedded-in-Java (an ugly kind of homoiconicity) and implement syntactic macros from Java which I think that prototype proves is possible but there is a lot more to be done on it to be really useful. Enough has been implemented in it right now in that you can use it to write the code generator that builds stubs. It might be good for balls-to-the-walls metaprogramming in Java but I think many will think it combines all the worse features of Java and Lisp.
-
Byte Magazine: Lisp
There is this project
https://github.com/paulhoule/ferocity/
which I might finish up when I'm done with the report I'm writing. It is possible to create Java expression trees with trees of static method calls that look a lot like S-expressions and stick them together into statements, methods and classes.
You should be able to do the same tricks people do with LISP macros and it could work code generation miracles but it would have that "LISP curse" problem in spades.
The plan is to generate a code generator that is sufficient to generate the full DSL implementation (ferocity0) and use that to generate the full implementation (ferocity.)
I have some tests for ferocity0 writing .java files to get fed to javac and for ferocity0 running expression trees with a primitive interpreter. Already the type system is enriched over the type system because interpreted ferocity0 can handle Java expressions as a type at run time so you get issues like quoting and unquoting in LISP.
-
What Happened to Lambda-the-Ultimate.org
Internal or external?
I think Java is just fine for internal DSLs, see
https://www.jooq.org/
I was also hacking on this project
https://github.com/paulhoule/ferocity/
which was about making Java homoiconic. Namely in ferocity you can write
Expression literal = of("Hello World");
-
The Number Guessing Game Written in YAML as Lisp Interpreted with Python
You could process that Expression in a few different ways, for instance you could evaluate the tree using reflection or you could turn the tree into source code and compile it with javac.
Going down that path I found it was more about discovery rather than invention. That is, you will discover the issues that come up around quoting in LISP and develop some answers to them. Also for the exercise to be interesting at you will get into an execution model that is a bit bigger than the original language : for the metaprogramming to be fun at all you want to be able to write Expressions that manipulate Expressions so you end up introducing types that don't really exist in the base language. These are almost trivial to handle using the primitive interpreter style but could be more of a challenge to compile to source code.
Some source code is here
https://github.com/paulhoule/ferocity
It's been a long time since I worked on it and I need to see if I have more notes explaining the plan behind it, but the idea was to develop "ferocity0" which was a version of the DSL that was good enough to build stubs for some of the language and a large part of the standard library, and then use code generation techniques to create "ferocity1" which would be like "ferocity0" but would cover 100% of the Java language.
My current side project is being sidelined by supply chain problems so I might go back into that one.
coalton
-
How to Write a (Lisp) Interpreter (In Python)
It's still… not the same. In CL (and specially with SBCL), we get compile time (type) errors and warnings at the blink of an eye, when we compile a single function with a keystroke (typically C-c C-c in Slime).
And there's also been improvement, see Coalton for a ML on top of CL. (https://github.com/coalton-lang/coalton/)
-
Typing Haskell in Haskell
For the parenthetically inclined among us, there's also an implementation in Coalton: <https://github.com/coalton-lang/coalton/tree/main/examples/t...>
-
Embracing Common Lisp in the Modern World
Common Lisp has bad marketing (even OCaml has Twitch streamers and "influencers" now), and bad support for general editors, both of which make it a non-starter for most curious people who have an afternoon to try something. But behind all that is magnificent activity for those who got over the initial potential energy barrier. Just to give some examples:
1. SBCL, the most popular open source implementation of Lisp, is seeing potentially two new garbage collectors. One of them is a parallel collector written by a university student (!!) which blows my mind.
2. SBCL has better and better support for deploying Liwp as a C-compatible shared library, using SBCL-LIBRARIAN. It makes it play nicer with other applications in C and Python.
3. Coalton is another exciting development that allows a Haskell type system and "Lisp-1" functional programming in Common Lisp. That means type classes (or traits), something Lisp hasn't really had a proper notion of, and full type inference. Persistent sequences based off of RRB-trees were recently merged, and interestingly, they're implemented purely in Coalton [1]. That means Clojure-like seqs.
It's interesting to see users of Lisp generating the above ideas and libraries, not a special in-group of committees, "official" developers, etc.
[1] https://github.com/coalton-lang/coalton/blob/main/library/se...
-
Steel – An embedded scheme interpreter in Rust
Use an editor that auto-inserts parens and that indents the code correctly. Now nothing bad can happen. And the parens are used to edit code structurally.
re typing: Coalton brings Haskell-like typing on top of CL. https://github.com/coalton-lang/coalton/ Other lisps are typed: typed racket, Carp… and btw, SBCL's compiler brings some welcome type warnings and errors (unlike Python, for instance).
-
Show HN: Collaborative Lisp Coding on Discord
If you like type safety, this project would be perfect for using https://coalton-lang.github.io/ so your REPL supported Common Lisp out of the gate.
-
A fully-regulated, API-driven bank, with Clojure
Agree that you can use types to express and prove logical properties via compiler; it can be a fun way to solve a problem though too much of it tends to frustrate coworkers. It's also not exactly "low cost"; here's an old quip I have in my quotes file:
"With Scala you feel smart having just got something to work in a beautiful way but when you look around the room to tell your clojure colleague how clever you are, you notice he left 3 hours ago and there is a post-it saying use a Map." --Daniel Worthington-Bodart
> On the contrary, they're still the most effective technique we've found for improving program correctness at low cost.
This is not borne out by research, such as there is any of any quality: https://danluu.com/empirical-pl/ The best intervention to improve correctness, if not already being done, is code review: https://twitter.com/hillelogram/status/1120495752969641986 This doesn't necessarily mean dynamic types are better, just that if static types are better, they aren't tremendously so to obviously show in studies, unlike code review benefit studies.
My own bias is in favor of dynamic types, though I think the way Common Lisp does it is a lot better than Python (plus Lisp is flexible enough in other ways to let static type enthusiasts have their cake and eat it too https://github.com/coalton-lang/coalton), and Python better than PHP, and PHP better than JS. Just like not all static type systems are C, not all dynamic type systems are JS. Untyped langs like assembly or Forth are interesting but I don't have enough experience.
I don't find the argument that valuable though, since I think just focusing on dynamic vs static is one of the least interesting division points when comparing languages or practices, and if we're trading experience takes I think Clojure's immutable-by-default prevents more bugs than any statically typed language that is mutable by default. It's not exactly a low cost intervention though, and when you really need to optimize you'll be encouraged by the profiler to replace some things with Java native arrays and so on. I don't think changing to static types would make a quality difference (especially when things like spec exist to get many of the same or more benefits) and would also not be a low cost intervention.
Last quip to reflect on. "What's true of every bug found in the field? ... It passed the type checker. ... It passed all the tests. Okay. So now what do you do? Right? I think we're in this world I'd like to call guardrail programming. Right? It's really sad. We're like: I can make change because I have tests. Who does that? Who drives their car around banging against the guardrail saying, "Whoa! I'm glad I've got these guardrails because I'd never make it to the show on time."" --Rich Hickey (https://www.infoq.com/presentations/Simple-Made-Easy/)
-
Coalton to Lispers without a background in ML-like languages
Coalton seems great, I love the idea. This issue seems problematic, though: https://github.com/coalton-lang/coalton/issues/84
-
Compiler Development: Rust or OCaml?
> Lisps can be very flexible, but they usually lack static type safety, opening a wide and horrible door to run-time errors.
People should do basic research before writing something silly like this. Qualifying your statement with 'usually' is just a chicken sh*t approach. Common Lisp and Racket have optional strong typing, leaving the responsibility and choice to the developer. Common Lisp is great for implementing compilers. You also have thing like Typed Racket and Coalton. The latter is comletely statically typed ala MLTON
https://github.com/coalton-lang/coalton
-
Why I Still Lisp (and You Should Too)
Have you checked out Coalton? It allows static typing a la Haskell within Common Lisp. Fully interoperable with CL, including through SLIME etc.
-
Common Lisp for large software
I've not regretted using Common Lisp for large, professional projects. However, I started Coalton so that some parts of a Common Lisp project can have strong, static, strict types—reaping benefits of compile-time errors and increased efficiency when I need it, without having to rewrite everything.
What are some alternatives?
reflect-metadata - Prototype for a Metadata Reflection API for ECMAScript
awesome-lisp-companies - Awesome Lisp Companies
pidove
hackett - WIP implementation of a Haskell-like Lisp in Racket
paip-lisp - Lisp code for the textbook "Paradigms of Artificial Intelligence Programming"
racket - The Racket repository
phel-lang - Phel is a functional programming language that transpiles to PHP. A Lisp dialect inspired by Clojure and Janet.
cl-cookbook - The Common Lisp Cookbook
rakudo - 🦋 Rakudo – Raku on MoarVM, JVM, and JS
babashka - Native, fast starting Clojure interpreter for scripting
hissp - It's Python with a Lissp.
unseemly - Macros have types!