Any thoughts on R7RS-large? Is it just what Scheme needs, or is it over ambitious? Will it lead to more fragmentation or help Scheme become more popular (both compared to Perl/Python and Common Lisp)? Does it betray it's history, or just interpret it differently?
Just to remind everyone, the reason it has been over 7 years since R7RS-small, is that not enough proposoals (SRFIs) are being created. Everyone can help accelerate it's development by commenting on drafts and maybe even writing your own (or comment here what you think should be standardized)!
In case you're not familiar with the situation, the scheme standardisation system or the general plan, watch: https://vimeo.com/311106780
R7RS-large is largely based on a misunderstanding.
>>2
elaborate
>>1 I do like the idea of being able to move back and forth between the big schemes and having much less implementation-dependent code. Since there is also r7rs.small and any scheme that implements that meets the standard, I don't see it as betrayal. (But then I learned Guile using a book written for Racket and am working on one written for MIT-Scheme)
I am curious to see what comes out of the yellow edition, which the guy in the video described on reddit as "the Yellow Edition featuring SYNTAX WARZ!" - I haven't done enough low-level macros to have strong feelings about it, but I have done enough scheme to know it's something people have strong feelings about. I think that was one of the big things people didn't like about r6rs- being forced to use syntax-case.
I'm doing my part.
>>2
heh
There is the idea that R6RS is too large and several people have the view that this makes it bad. Those thusly against R6RS incorrectly ascribe a view to those in favor of R6RS: "it is so large, these people who like R6RS must like large languages!"
This is the misunderstanding.
R7RS is split in a small and large because then it should please those who want a small language and also those who want a large language. But those people who want a large language are merely windmills. People in favor of R6RS like it for other reasons.
This misunderstanding is why there is an R7RS-large effort. Do your own research if you don't believe me.
(I hope this was clear and that nobody feels agitated. This anon has nothing against R7RS-large)
Windmills?
>>6
I'm not sure if anyone likes a language just because of it's size. "Large" is a very vauge category, and doesn't mean a lot. What some people want (and I do to) is not size for it's own sake, but completness, the ability to write useful and portable programms, not having to re-write the same basics over and over again.
>>8
There was a fairly interesting conversation not too long ago with a similar line of reasoning starting here: http://textboard.org/prog/167/19
I still haven't made up my mind about the arguments there. In any case I will make the argument here that if you're re-writing the same basics over and over again you're not programming right unless your standard is too small to have modules, or even load (even then you should probably just copy-paste). Also in light of Gödel I question trading consistency for completeness. ))
>>9
Better link: http://textboard.org/prog/167/19,21-24
>>9,10
I'm not sure, but I think that was my post.
>>10 I am very confused by the use of spoilers on this board.
>>11
It's possible 22 was but the rest were not.
>>13
No, I was thinking of 19. Either way, it's not important.
It looks like R7RS doesn't plan on standardising a FFI. That's pity, imo, since it will make it harder to implement portable, numpy like libraries in Scheme.
>>15
I was recently looking for a numpy-like library for Scheme (and lisps generally) and I was also disappointed with the lack of a standardized FFI, but I question that for this task it would be necessary to create a numpy in Scheme. Especially considering that Scheme does have standardized vectors and bignums, I seem to recall some implementations even use GMP directly, and many have efficient operations on bignums.
but I question that for this task it would be necessary to create a numpy in Scheme
I meant to say that I question that for this task (creating a numpy-like in Scheme) it (standardized FFI) would be unnecessary.
>>17
christ, I messed up again, I give up.
>>16-18
Wel it's necessary if you want to interact with some BLAS-like library.
>>19
That's fair, I guess a lot of people use numpy for performance, and see that as the primary feature.
>>16
Darkart, a library for chez, might be relevant if you're still looking to use numpy. https://github.com/guenchi/Darkart
A binary interface let Chez Scheme use Python, Lua, Ruby etc's library
This project is inspired by the Julia language. The FFI interface provided by Chez is used to embed the interpreter or JIT compiler of other languages into the Scheme program (CPython, Luajit etc) or to link the compiled object code with the C binary interface. (OCaml, Golang etc).
John Cowan: My resignation letter as R7RS-large chair
https://groups.google.com/g/scheme-reports-wg2/c/xGd0_eeKmGI/m/q-xM5fbuAQAJ
Daphne Preston-Kendal: WTF is going on with R⁷RS Large?
http://dpk.io/r7rswtf
autogynephiles everywhere :(
>>23
Begone.
>>22
Look! Schemers scheming schisms!
>>22
That's pretty sad. I will continue to do my work in R7RS-small until they finally ratify the large in 2050.
>>24 Doesn't the abnormal rise in autogynephilia and similar disorders of psychosocial retardation look quite dire in light of the mouse utopia experiments? https://www.smithsonianmag.com/smart-news/how-mouse-utopias-1960s-led-grim-predictions-humans-180954423/