3 ms·

> Writing portable scheme is almost impossible, and frowned upon. Jesus christ. I'm sure there are great, rational reasons for this. What were they? It's rea

> Writing portable scheme is almost impossible, and frowned upon. Jesus christ. I'm sure there are great, rational reasons for this. What were they? It's really interesting to think that the majority of our software platforms are A) Unix-derived and a bit of B) Windows, and both of those have pretty much taken over industry with Algol-derivatives (C, C++, Objective-C, Java...). I mean, it's news when a company says "We don't use the above!" With that in mind, it feels like Scheme is the like the Basques/Finns of the software world, a completely separate genealogical line that perdures to this day in small pockets here and there.

ThatGeoGuy 10y ago
Do keep in mind portable here is with regards to "between implementations" and not "per platform." Code between PyPy and CPython isn't guaranteed to be 100% portable (although they try), and in Scheme it's much the same way. And you shouldn't think in terms of C, C++, etc being portable. There's lots of code written for GCC that doesn't conform to an explicit C++ standard (C++11/14 try to change this, but still). In the same way, you're really writing to the standard of language your C/C++ compiler implements. It's hairy, but the fact that things are not portable is just given more visibility in Scheme. Reasons for this are probably varied, but it also has to do with the variation in how Schemes are implemented at the lowest level (think Guile vs. CHICKEN, just in terms of GC they're worlds apart). At the end of the day, some code can be written to be portable (see some SRFIs) but we usually don't worry about minor inconsistencies within the larger Scheme community.
- qwertyuiop924 10y ago
  Forget the GCs, let's talk about Cheney on the MTA! Now that's a difference in implementation. It's also why Chicken is A) freaking AWESOME!!! and B), totally sucks. But that's a story for another day...
qwertyuiop924 10y ago
By nonportable, I assume you mean "between implementations", because that's where the nonportability is. And yes, there is. It has to do with scheme's origin. scheme originated in PL research (at the MIT AI lab) and was quickly pressed into service for education. As such, it has a strong userbase in academia. Those users need a language that was small, easy to implement, and powerful enough to express a wide variety of paradigms and concepts compactly. Meanwhile, Scheme users in the Real World, who want to Get Stuff Done, want that, but they also want things like OS interfaces, networking, module systems, FFIs, large standard libraries, etc. For many years, the approach the scheme standard took was to lay out the bare minimum required to be a scheme, and depend upon maintainers of various implementations to flesh it out. Furthermore, if the comitee couldn't agree on something, it went unspecified. This resulted in something akin to the unix situation, but worse: we had a family of languages named Scheme, but all but the simplest programs would inevitably depend on implementation-specific language extensions, and all the implementations extended the language in different directions. Furthermore, the academics need Scheme to be easy to implement, so it was: it was so simple any easy that anyone could implement it, and anyone did, resulting in a bevy of Scheme implementations of varying levels of quality, from "industrial strength" to "weekend hack". There are admirable efforts to write cross implementation packages (most famously, SLIB), but it's generally not recomended, because it's a PITA to do. R6RS tried to fix this, but... well, imagine that POSIX said, "we're trying to improve cross-system compatability, so you all have to implement Solaris Event Ports, Netlink, Streams, and the AIX sysadmin utilities to be considered POSIX. Just throw away whatever you were using instead of that." Needless to say, this did not go over well. R7RS tried to improve things by spliting the language into the traditional small core, and the larger stdlib, which you didn't have to implement to be scheme, but would hopefully improve interoperability between implementations. This seems to be working okay thus far, although the stdlib isn't done yet. We shall see...
shakna 10y ago
Portability between implementations is a nightmare, and you end up adopting only one. Its not overly different than the compatibility problems you hit between JPython, CPython, and IronPython. Most Scheme implementations are cross-platform, and most issues you run into are the "extras" each implementation adds in. Let me say this: most of my daily work involves programming in Scheme. We investigated a lot of the top contenders, and ran into some rather random issues. Gambit-C is damn fast. Its GC is amazing, and as the name implies, it cross-compiles to C. With a little tweaking, we got it running on some of the beefier Arduinos for some embedded work. Gambit includes custom namespaces for modules, which can make it easier to work with. However, documentation for Gambit is atrocious. Guile doesn't support native compilation. You could compile down to the object code, and then write a C-wrapper for it, but it's painful working that way. (Also: Guile doesn't support the (void) function! They renamed it for no obvious reason.) Chicken compiles down to native code, though its runtime is slightly slower than Gambit. It also implements a lot more SRFIs than Gambit, making it so you don't need to reinvent the wheel as much. However: the moment you add a package, Chicken can't compile statically anymore, and you need to build a distribution, and that gets rather hairy when you hit optional dependencies per platform. All that being said, my work, for reasons I'm probably not able to explicitly go into, involves writing code that both Chicken and Gambit-C can run, and it isn't overly difficult, though I did have to reimplement some libraries that only one or the other had. Yet, in Scheme-land, that's half a days work.
- qwertyuiop924 10y ago
  Neat. Yeah, it's a lot better than it used to be. Oh, by the way, as somebody who primarily uses Chicken, you forgot about the coolest part: Chicken is slower than Gambit, but it does Cheney on the MTA compilation, which means that call/cc is almost free. Given, there are some other tradeoffs, but it's still pretty cool. Also, what kind of job are you in where you're writing Scheme code? That's totally awesome!
  - shakna 10y ago
    Getting to use Scheme was almost an accident. We had a dual Python/C stack, where we basically had a prototype in Python, running for small clients, and then a better C one for embedded devices. We decided that was a bad idea, and went to rewrite the C for both consumer and embedded devices. However, the lack of progress had the manager investigating all kinds of things, like MicroPython. I had been playing around with Scheme in my spare time, and pointed out that Scheme was almost as fast as C, and almost as fast as Python for prototyping. They handed me a test to see if Scheme was suitable -> Rewrite our Python prototype in Scheme, within three weeks. Because of how consistent Scheme is, and how close Python's syntax is to it, it only took me three days. With the decent C output of Gambit's compiler, I wrote a script that modified it to work on our embedded devices as well, in another three days. The manager was sold, and our whole team moved to Scheme. I was very unpopular for a few months. As to the actual project? The little I can say, as it isn't launched yet, is that it's a kit designed for schools.

ThatGeoGuy 10y ago

Do keep in mind portable here is with regards to "between implementations" and not "per platform." Code between PyPy and CPython isn't guaranteed to be 100% portable (although they try), and in Scheme it's much the same way. And you shouldn't think in terms of C, C++, etc being portable. There's lots of code written for GCC that doesn't conform to an explicit C++ standard (C++11/14 try to change this, but still). In the same way, you're really writing to the standard of language your C/C++ compiler implements. It's hairy, but the fact that things are not portable is just given more visibility in Scheme. Reasons for this are probably varied, but it also has to do with the variation in how Schemes are implemented at the lowest level (think Guile vs. CHICKEN, just in terms of GC they're worlds apart). At the end of the day, some code can be written to be portable (see some SRFIs) but we usually don't worry about minor inconsistencies within the larger Scheme community.

qwertyuiop924 10y ago
Forget the GCs, let's talk about Cheney on the MTA! Now that's a difference in implementation. It's also why Chicken is A) freaking AWESOME!!! and B), totally sucks. But that's a story for another day...

qwertyuiop924 10y ago

By nonportable, I assume you mean "between implementations", because that's where the nonportability is. And yes, there is. It has to do with scheme's origin. scheme originated in PL research (at the MIT AI lab) and was quickly pressed into service for education. As such, it has a strong userbase in academia. Those users need a language that was small, easy to implement, and powerful enough to express a wide variety of paradigms and concepts compactly. Meanwhile, Scheme users in the Real World, who want to Get Stuff Done, want that, but they also want things like OS interfaces, networking, module systems, FFIs, large standard libraries, etc. For many years, the approach the scheme standard took was to lay out the bare minimum required to be a scheme, and depend upon maintainers of various implementations to flesh it out. Furthermore, if the comitee couldn't agree on something, it went unspecified. This resulted in something akin to the unix situation, but worse: we had a family of languages named Scheme, but all but the simplest programs would inevitably depend on implementation-specific language extensions, and all the implementations extended the language in different directions. Furthermore, the academics need Scheme to be easy to implement, so it was: it was so simple any easy that anyone could implement it, and anyone did, resulting in a bevy of Scheme implementations of varying levels of quality, from "industrial strength" to "weekend hack". There are admirable efforts to write cross implementation packages (most famously, SLIB), but it's generally not recomended, because it's a PITA to do. R6RS tried to fix this, but... well, imagine that POSIX said, "we're trying to improve cross-system compatability, so you all have to implement Solaris Event Ports, Netlink, Streams, and the AIX sysadmin utilities to be considered POSIX. Just throw away whatever you were using instead of that." Needless to say, this did not go over well. R7RS tried to improve things by spliting the language into the traditional small core, and the larger stdlib, which you didn't have to implement to be scheme, but would hopefully improve interoperability between implementations. This seems to be working okay thus far, although the stdlib isn't done yet. We shall see...

shakna 10y ago

Portability between implementations is a nightmare, and you end up adopting only one. Its not overly different than the compatibility problems you hit between JPython, CPython, and IronPython. Most Scheme implementations are cross-platform, and most issues you run into are the "extras" each implementation adds in. Let me say this: most of my daily work involves programming in Scheme. We investigated a lot of the top contenders, and ran into some rather random issues. Gambit-C is damn fast. Its GC is amazing, and as the name implies, it cross-compiles to C. With a little tweaking, we got it running on some of the beefier Arduinos for some embedded work. Gambit includes custom namespaces for modules, which can make it easier to work with. However, documentation for Gambit is atrocious. Guile doesn't support native compilation. You could compile down to the object code, and then write a C-wrapper for it, but it's painful working that way. (Also: Guile doesn't support the (void) function! They renamed it for no obvious reason.) Chicken compiles down to native code, though its runtime is slightly slower than Gambit. It also implements a lot more SRFIs than Gambit, making it so you don't need to reinvent the wheel as much. However: the moment you add a package, Chicken can't compile statically anymore, and you need to build a distribution, and that gets rather hairy when you hit optional dependencies per platform. All that being said, my work, for reasons I'm probably not able to explicitly go into, involves writing code that both Chicken and Gambit-C can run, and it isn't overly difficult, though I did have to reimplement some libraries that only one or the other had. Yet, in Scheme-land, that's half a days work.

qwertyuiop924 10y ago
Neat. Yeah, it's a lot better than it used to be. Oh, by the way, as somebody who primarily uses Chicken, you forgot about the coolest part: Chicken is slower than Gambit, but it does Cheney on the MTA compilation, which means that call/cc is almost free. Given, there are some other tradeoffs, but it's still pretty cool. Also, what kind of job are you in where you're writing Scheme code? That's totally awesome!
- shakna 10y ago
  Getting to use Scheme was almost an accident. We had a dual Python/C stack, where we basically had a prototype in Python, running for small clients, and then a better C one for embedded devices. We decided that was a bad idea, and went to rewrite the C for both consumer and embedded devices. However, the lack of progress had the manager investigating all kinds of things, like MicroPython. I had been playing around with Scheme in my spare time, and pointed out that Scheme was almost as fast as C, and almost as fast as Python for prototyping. They handed me a test to see if Scheme was suitable -> Rewrite our Python prototype in Scheme, within three weeks. Because of how consistent Scheme is, and how close Python's syntax is to it, it only took me three days. With the decent C output of Gambit's compiler, I wrote a script that modified it to work on our embedded devices as well, in another three days. The manager was sold, and our whole team moved to Scheme. I was very unpopular for a few months. As to the actual project? The little I can say, as it isn't launched yet, is that it's a kit designed for schools.