Installation-wise, NixPkgs is fairly straightforward.
[1] Does anybody know how to ping Kartik Singh about the coroutines implementation in SBCL? Apparently, he made an experimental port of the green threads implementation from CMUCL, but I can't find it anywhere online, nor any obvious way to catch anyone involved. Is the mailing list the only way?
https://github.com/kartik-s/sbcl/blob/coroutines/src%2Fcode%...
Why is there so little interest in green threads/coroutines in CL community? cl-cont really isn't something to point to when asked about C10K problem... or yield/yield*... or async/await...
The first implementation doesn't need to be production-ready. And the maintenance burden (along with polishing the implementation and porting to other architectures) could be shared by a few people and done over time. Having a starting point in the form of CMUCL code (already adapted to SBCL!) is the perfect opportunity for everyone interested to chime in: enough voices in favor could convince someone capable to continue the work. Yet, there are literally just 3 comments under the ESL presentation video, and it's not mentioned anywhere else...
The first few steps would be building on top of this work and reaching out to the SBCL maintainers via the mailing list to see what it takes to get this merged in.
Shen uses a dependently typed Sequent-Calculus based Type System (SCTS). It uses type rules vs. type classes, and type checking is optional, you can turn it on or off. Haskell's type inference makes things a bit simpler, and is a battle-tested static type system with excellent type inference which lends itself better for functional programming and large-scale software engineering (for the moment). Shen's TC is more expressive, but requires more effort.
Aditya Siram has some old but goody YT videos on Shen.
I'm an idiot. I looked at this page: https://shenlanguage.org/TBoS/tbos.html many times, tried clicking on the table of contents, realized that chapter titles are not links, and went away thinking it's only the ToS for promotional purposes. I only realized that the page numbers are links just now. To my defense, they don't differ in color that much and lack the underline that often marks links. Still, a HUGE facepalm :D Thanks for mentioning this and making me realize my own stupidity :)
I made an attempt to fix that for eli: https://github.com/codr7/eli#type-checking
And maybe ask yourself why you felt saying so was important to you.
(the number (+ 35 7))
(+ 35 7)@NumericIt's like Unix pipes for functions:
(~> "hello"
(string-ref 1)
(char->integer))[1] https://github.com/ruricolist/serapeum/blob/master/control-f...
[2] https://github.com/ruricolist/serapeum/blob/master/REFERENCE...
First you will usually want to write small chunks of code, instead of a large soup.
Second, you can make intentional decisions with your use of newlines in order to highlight specific aspects of the code.
I find clojure more readable than most other languages… However, bad code stands out horribly (which is actually great if you have at least one experienced engineer in the team- I’d argue there’s nothing worse than bad code that looks normal). Just like anything else, writing good lisp takes some skill.
Your specific editor and its configuration will also have a big impact on your experience.
(defun foo (&aux bar baz)
(setq bar (quux)
baz (xyzzy))
...)Whatever is gained in exchange for this additional syntactical complexity may not be valued in the same way by everyone.
So that almost certainly explains that reaction.
(funcall #~s:gi/abc/def/ "Testing abc testing abc")
I know all the problems with reader extensions, really. I understand being cautious. But at some point, you gotta wonder: what's the point of the programmable reader when you're unwilling to add programs to it?
[1] Let over Lambda: https://letoverlambda.com/index.cl/guest/chap4.html
1> (regsub #/abc/ "def" "Testing abc testing abc")
"Testing def testing def"The problem is it's a walled garden, with its own quirky syntax; nothing that happens inside of loop is applicable outside, and the other way around.
The abstractions used in Calendrical Calculations sound good - and echo what I've seen elsewhere - so, based on your comment I'm now more likely to read it, so thank you for that.
The source code is available there.
Then you got all the life-improving goodies (in-{sequence,string,file,stream}, index-of-*, previous, etc...) that really add up to something.
Trivial example of breakage:
(iter (for i from 1 to 10)
(print (count i some-sequence)))Or is the documentation wrong?
Iterate, in (COUNT I SOME-SEQUENCE): Missing value for SOME-SEQUENCE keyword
WARNING:
COUNT appears to be used as an ITERATE clause keyword, in this sexpression: (COUNT I SOME-SEQUENCE).
This use is now deprecated and will cease to be supported in a future version. Please use the alternative keyword COUNTING instead. If you intended COUNT to be interpreted as a function call, instead of an ITERATE clause, you must find an alternative way of calling it, at present, perhaps by using FUNCALL or APPLY.
(iter (for i from 1 to 10)
(print (funcall #'count i some-sequence)))
But yeah, that's still not something I intend to use if they make you work around what should be plain Common Lisp.
(Using a literal list or vector gives a different error)
Still better than the loop abomination, IMO.
I had to rub my own eyes to believe that such a thing is possible.
It comes with over twenty useful clauses. Clauses are programmer-definable.
Clauses can combine in parallel or nested/cross-product iteration.