dense-arrays
hy
dense-arrays | hy | |
---|---|---|
7 | 52 | |
23 | 4,778 | |
- | 0.6% | |
5.6 | 9.2 | |
about 1 month ago | 2 days ago | |
Common Lisp | Python | |
- | GNU General Public License v3.0 or later |
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.
dense-arrays
- dense-arrays: Numpy like array object for common lisp
-
Image classification in CL? Help with starting point
*I have not; I have a couple of WIP/alpha-stage libraries like dense-arrays and numericals that could be useful; once I find the time, I want to think about if these or its dependencies can be integrated into the existing libraries including antik mentioned by awesome-cl.
-
Machine Learning in Lisp
Personally, I've been relying on the stream-based method using py4cl/2, mostly because I did not - and perhaps do not - have the knowledge and time to dig into the CFFI based method. The limitation is that this would get you less than 10000 python interactions per second. That is sufficient if you will be running a long running python task - and I have successfully run trivial ML programs using it, but any intensive array processing gets in the way. For this later task, there are a few emerging libraries like numcl and array-operations without SIMD (yet), and numericals using SIMD. For reasons mentioned on the readme, I recently cooked up dense-arrays. This has interchangeable backends and can also use cl-cuda. But barring that, the developer overhead of actually setting up native-CFFI ecosystem is still too high, and I'm back to py4cl/2 for tasks beyond array processing.
-
polymorphic-functions - Possibly AOT dispatch on argument types with support for optional and keyword argument dispatch
Currently I have put successfully this to use at dense-numericals - which I created over dense-arrays after finding CL arrays to be not that suitable, as compared to numpy or julia. Now, dense-numericals relies on passing the array pointer to C functions. However, IIUC, this runs into issues for what if the GC moves the arrays while the computation is still not done; is this worry valid? I think I ran into this while running multithreaded tests on CCL, ending up in segfaults.
-
Confused about array runtime type checking in SBCL
Shameless unstable plug: I think it should be possible to provide type checking with a different backend that does not upgrade the types at https://github.com/digikar99/dense-arrays - the backend things are themselves unstable though.
-
Past, Present, and Future of Lisp
In semi-production, ideally the problems are best represented using state diagrams, but I don't see a way to comfortably represent graphs in textual formats. The best I see is list of lists, which doesn't feel significantly better than the spaghetti code it currently is (for instance this and this - but these are just about one function each in a larger system, so not totally worth a DSL, unless there existed a defacto state-diagram DSL which everyone could be expected to know.
hy
- A dialect of Lisp that's embedded in Python
-
How to Write a (Lisp) Interpreter (In Python)
Not exactly the same (doesn't embed into the source like this did), but I believe Hylang[0] is the best Lisp package available for modern Python.
[0] https://github.com/hylang/hy
-
Sapling: A highly experimental vi-inspired editor where you edit code, not text
Isn't that a bit what hy (https://hylang.org/) tries to do ? AIUI it is a lisp interacting directly with the AST of Python, allowing seamless interop: Python modules can be used from hy and vice versa, everything is transparent.
- Hylang, a Lisp dialect embedded in Python
-
Hissp
I’ve been keeping loose tabs on this and Hy[1] for a while, but I’ve had some trouble figuring out the major differences between them and the use-cases for either. Would love to see an in-depth comparison in the form of a blog post sometime (though maybe the answer here is to do the research and write one up myself).
1: https://hylang.org
- Hy
-
Ask HN: Is SICP/HtDP still worth reading in 2023? Any alternatives?
“Python is for scientists. Lisp is for engineers.”
Then what does that make Hy language?
https://hylang.org/
Re Languages with lots of example code and LLM’s
With translators or things like Hy lang, one could get the LLM’s to solve your problem in Python before converting it to another form. Then, you just need a translator. If lacking one, it’s easy to translate by hand.
The practicality of this concept will probably vary by use case. My experiments had GPT doing sketching, implementations, boilerplate, and even porting Python to Rust. A legally-clear LLM trained on multiple languages could probably be fine-tuned to do Python to LISP conversions. If not, Hy might be a stepping stone, too.
-
Sharing Saturday #469
You could say so: I've been maintaining the compiler since 2016 ;). Infinitesimal Quest 2 + ε (SQ) exists more to advance Hy than for its own sake.
- What if: python without commas
-
Best implementation of CL for learning purposes
If you are using Python - you might find Hylang (https://hylang.org) interesting.
What are some alternatives?
array-operations - Common Lisp library that facilitates working with Common Lisp arrays.
hissp - It's Python with a Lissp.
py4cl - Call python from Common Lisp
Fennel - Lua Lisp Language
numericals - CFFI enabled SIMD powered simple-math numerical operations on arrays for Common Lisp [still experimental]
babashka - Native, fast starting Clojure interpreter for scripting
py4cl2 - Call python from Common Lisp
eso-light-attack-weave - This is a macro for the game Elder Scrolls Online
cl-parametric-types - (BETA) C++-style templates for Common Lisp
Carp - A statically typed lisp, without a GC, for real-time applications.
specialization-store - A different type of generic function for common lisp.
hebigo - 蛇語(HEH-bee-go): An indentation-based skin for Hissp.