Does anyone here actually use Scheme for anything other than doing textbook exercises?
Does guile count?
>>1
The owner of the site does, which is why this place exists at all: https://fossil.textboard.org/schemebbs/home I can honestly say I have never used Scheme for anything more than simple scripts and textbook exercises though.
I use it with Common Music(S7). Wanting to use it more in future.
People probably use elisp the most.
I don't, lolol
>>2
Yes.
>>5
Elisp is not Scheme.
2 I have more than once got the impression that people think of guile as not-scheme? What is that about? Or is it a joke?
>>8
It's not purely scheme but a scheme like language pushed by gnu. You can find it in a lot of gnu tools.
The problem with calling it scheme like is how gnu is usually known as the opposite of simplicity but I haven't used guile enough to see if it has that many extensions compared to s7. I know it's userland utilities do compared to bsd and svr ones, tons of tools have more usage overlap and it's even more complicated.
>>9
*r7rs
>>8 but it seems much more in line with r7rs than say, MIT-scheme, Gerbil or Racket -not that there aren't some warts. And it seems like there are plenty of implementations like Chibi, STklos, Gauche, Chez, Chicken that in the same size neighborhood and have their own extensions. But GNU, that's true, that probably does go some way to explaining it. (I have to disagree with the idea that it's pushed by the GNU though, the idea that GNU is the official extension language of the GNU project is meaningless next to the mountain of Python bindings that GNU projects actually have.)
>>11
It can be expected of gnu to push out something completely compliant the first but not always. That knowledge probably isn't held by those pushing guile is not scheme seriously and not as a joke. I was pushing it as a joke though.
It's depressing gnu won't write it's own python 2 and python 1 implementation with gnu peps, python 2 has tachyon now since it will never die. There might be a python 1 implementation hidden somewhere on savanna though.
>>8
This is probably not the reason, but technically Guile supports multiple languages: https://www.gnu.org/software/guile/manual/html_node/Supporting-Multiple-Languages.html
>>12
Python-on-Guile exists, but I am unsure which version it targets: https://gitlab.com/python-on-guile/python-on-guile
>>13
When does pog get gpeps.
>>11-13
Found something funny about python 1.
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98
when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton
Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus
version 6.10.20. The same Norton Antivirus version doesn't have this problem on Windows 2000.
Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.)Why nobody uses Scheme? How can we make it more popular?
>>15
Finishing r7rs-large. A well designed, cross-platform, simple, modular, extendible scripting language, that can be compiled, and has multiple implementations to fall back on, is something a lot of people might find interesting.
Scheme is used, but people are not in-your-face about it. You might have several implementations on your computer and not know about it. Got a Mac or a Steelseries headset? You got a Scheme. Does *anyone* know what Cisco uses Chez for?
Less glorious, but supporting the point above: "TinyScheme was used as the core of Direct Revenue's adware, making it the world's most widely distributed Scheme runtime."
Does *anyone* know what Cisco uses Chez for?
I always assumed Cisco didn't even know they used it.
And chances are good they still don't know.
Why nobody uses Scheme? How can we make it more popular?
At least for me, I think a lot of this has to do with it being very difficult to write portable Scheme, especially if you want to interact with the outside world, or write something particularly efficient. There is this real dissonance of Lisp at once encouraging standardization, encouraging "the right thing", encouraging writing complete programs, and at the same time Scheme denying you the opportunity to write portable programs.
dissonance
I don't see it, what does that have to do with Lisp?
>>20
The dissonance is in the form of these contradictory beliefs which Scheme has as a product of its cultural inheritance as a member of the Lisp family of programming languages, and its belief that programming languages should be easy to implement (leading to under-specification and non-portable programs).
>>21
I hold the dim view that "portability" is largely a myth bolstered by the dominance of certain machine architectures and language implementations over alternatives. In that respect Scheme doesn't seem appreciably worse than C in being under-specified, but without any dominant implementations or even consensus among its users the ecosystem stayed fragmented while C's mostly coalesced around a handful of flagship implementations on x86.
More often than not, truly portable C results from contortions by the programmer to write for the lowest common denominator. For non-trivial programs, this is not usually something to aspire to.
>>22
This is a compelling argument, and I still need to think about it more. If I
understand correctly this is more of an argument against something like
standardized performance guarantees rather than standardized semantics and
syntax. So it might be that portability in a smaller sense would still be
virtuous, on the other hand this may be an ad hoc adjustment, which is not a
good sign for the truth value of a theory. Just to invoke a sort of stream of
consciousness this makes me think about sort of paradigm independent
programming like Fortress, and deductive optimisations like reduction
operations on lambda calculus. To what extent can optimisation exist without
referense to hardware, even if we include extremely dramatic deviations in
hardware? There is also this blurry line of how much influence protocols
should have over a language especially if we accept binary protocols, for many
tasks it would likely turn out that simply accepting the common representation
of a protocol would be more efficent than translating into a form which might
be more efficient due to hardware specific optimisations. Homogenous
representations of data structures seems like it would allow for a great deal
of reasoning about performance. This is likely another ad hoc modification
though.
>>23
sorry about the fill-paragraph, I usually correct this before sending but forgot.
>>21
In what sense is Scheme underspecified? Since at least R3RS, the specification even includes formal semantics!
>>25
Truthfully I have a fairly crude notion of this myself, but consider the following questions: What objects have the same memory location (eq? each other)? What order are internal definitions evaluated in, especially with regards to mutually recursive internal definitions? How large is the numeric tower? What compound data structures have copy-on-write versus mutable implementations? Can the way continuations are implemented make programs slower, even if they are used appropriately? How do you call foreign functions in Scheme? etc.
What objects have the same memory location (eq? each other)?
As far as I understand one location can only have one object.
What order are internal definitions evaluated in, especially with regards to mutually recursive internal definitions?
If you need a defined order of evaluation, you can use letrec*. Do you have any examples where this actually matters for mutually recursive definitions? I can't think of any.
How large is the numeric tower?
It has five levels, from top to bottom: number, complex, real, rational and integer.
What compound data structures have copy-on-write versus mutable implementations?
None of the standard ones have copy-on-write.
Can the way continuations are implemented make programs slower, even if they are used appropriately?
Yes, there are no performance guarantees in the standard.
How do you call foreign functions in Scheme?
There's no standard way to do it.
There's no standard way to do it.
AFAIK r7rs-large plans to standardize this.
>>27
Overall I think your response is valid. I do think the admission of the last point alone is enough to condemn many potentially portable Scheme programs. A tricky thing to think about is that of course you could simply claim that you should never used unspecified behavior but this is operating under the assumption that we always know when we are doing. Even when you have a great deal of experience with a language you sometimes make mistakes, and if there no indication in your implementation, or even several major implementations that you made an error you are unlikely to fix it. This discourages portable software.
As far as I understand one location can only have one object.
Well yes, but the issue is what is a distinct object then I suppose for example eq? is unspecified for lists, numbers, strings, characters, vectors and functions. Another example might be equal? which is unspecified for functions.
Do you have any examples where this actually matters for mutually recursive definitions?
SICP has some.
It has five levels, from top to bottom: number, complex, real, rational and integer.
What about polar complex numbers and quaterions, what happens when you mix real numbers and polar complex numbers?
None of the standard ones have copy-on-write.
This is fair from the perspective of >>22 but it is still questionable to me, the only major implementation with copy-on-write is for strings, I know Gauche has them, and I wouldn't be surprised if there were others.
AFAIK r7rs-large plans to standardize this.
Really? That'd be a game changer honestly.
>>29
Let's see those examples from SICP.
>>28,29
My bad, it's not explicity on the agenda. R7RS-large is split into multiple phases, listed here: https://small.r7rs.org/wiki/WG2Dockets/. FFI is not on the current agenda, but is planned to be discussed by future working groups: https://small.r7rs.org/wiki/ReassignedDocket/
Due to the modular nature of R7RS, this shoudln't be too much of an issue, though if someone were to suggest a SRFI for FFI, this might change?
>>31
That's too bad, in any case all the things they make mandatory over R7RS-small is a major step in the right direction: https://small.r7rs.org/wiki/MandatoryDocket/ (even if much of this was already standardized in R6RS)
>>30
sure, I think all but the last would be amenable to letrec, for the last, it's not even clear what it means.
;; From SICP Section 4.16
(define (f x)
(define (even? n) (if (= n 0) #t (odd (- n 1))))
(define (odd? n) (if (= n 0) #t (even? (- n 1))))
<rest of body of f>)
(define (solve f y0 dt)
(define y (integral (delay dy) y0 dt))
(define dy (stream-map f y))
y)
(let ((a 1))
(define (f x)
(define b (+ a x))
(define a 5)
(+ a b))
(f 10))>>33
Internal definitions are syntactic sugar for letrec in R5RS and letrec* in R6RS and R7RS-small. In the latter case, the order of evaluations is specified to go from left-to-right. Only your first example is mutually recursive, in which case the order does not matter. This is because letrec first creates fresh locations, which are captured by the closures during their evaluations. Once evaluated, they are assigned to the location, mutating the captured environment. If portability was the goal, the second example should have used let* and the third let.
The reason the standard says (eq? '(a) '(a)) is unspecified is because the implementation can choose to do common subexpression elimination on the parameters, which would transform it into something like this:
(let ((x '(a)))
(eq? x x))In this case the implementation is allowed to return #t. But notice that for (eq? (list 'a) (list 'a)) the implementation is required to return #f, because list always returns a fresh object and on distinct locations it must return #f.
C-f ~/resources/Revised^6-Report-on-the-Algorithmic-Language-Scheme.pdf
C-s internal definitions
Internal definitions are now defined in terms of letrec*.
You are correct, I learned this from SICP, but the information is quite evidentially outdated.
If portability was the goal, the second example should have used let* and the third let.
The second is mutually recursive no? Also if this is syntactic sugar for letrec* wouldn't these be portable anyway? This is actually very valuable information.
>>35
Another example would be if you implemented strings as ropes then you could have mutations of strings which share space. I wasn't trying to argue that the unspecified behavior was left in for no reason, simply that it was present.
>>36
You are right, I am just not paying attention. It should work with both letrec and letrec* without issues.
>>1
If you're asking about industry use, I have deployed CHICKEN programs in production. Other than that, I just use Scheme to write toy programs for my own use.
Where do I get a job as a Scheme programmer? Any of you hiring?
Scheme isn't particularly popular in the business world. This means it's very difficult to find a business that's actively hiring programmers for Scheme based projects.
>>40
With sleazy and negative names such as "scheme", "racket", "larceny", "chicken", and "guile", it's no surprise that Scheme is not particularly popular in the business world. Scheme may find some use in the seedier corners of the business world. For example, Scheme has attracted the likes of adware companies such as Direct Revenue that produce sleazy products in line with Scheme's branding.
No.
>>41
Are really you making the argument that the business world cares about sleazy names? Businesses wouldn't exist in the first place if the appearance of being negative was ever important to a business.
How can anyone trust a programming language that is based on swindles? Lisp's lists are made of "cons".
>>44
Drumpf supporters can.
Scheme is a minimal programming language good for creating minimal software. In other words, it is good for creating subpar, incomplete, idealistic, and/or impractical software in a one-person team. Examples of Scheme applications include textbook exercises and SchemeBBS.