On Feb 21, 2009, at 10:29 PM, Eli Barzilay wrote: > > Same argument as before. "I mean you learn to speak american in > school no? Why don't you use it then??"
I have no idea what you are saying here. > >>>> No. The point is that conforming to what other languages do is a >>>> very weak argument for Scheme, as it is _very_ different. >>> >>> Not when you get to talk to these other languages. When you >>> "talk" to xml or to a dll, case-sensitive symbols and identifiers >>> make things much more convenient. >> >> Why aren't you using strings? [...] > > That's a very naive question (it suggests that you didn't really try > it for a non-toy piece of code). It's naive because every attempt I > know at doing something like an FFI starts with using strings -- it > *is* the obvious first thing you'd think of. It's also naive because > using strings is so inconvenient. > > Just imagine writing some code that interfaces a large foreign > library, using only strings. One option is a very long sequence of: > > (define foo (get-foreign-function "foo")) > (define bar (get-foreign-function "bar")) > (define baz (get-foreign-function "baz")) This is what generators are for. And yes, I have done it before, and it was fine. So thank you for calling me naive, but I've never run into trouble with this. > and you *can't* automate this with a macro for the obvious reason. That's why you use a generator, which can examine all the names at once, use an algorithm for mapping them, and report any collisions, if any. > More than that, if you're unfortunate to have the foreign code provide > a "Foo", for example, as some constructor, you'll now need to: > > (define make-foo (get-foreign-function "Foo")) > > From now own you inherit a new problem -- you can't say this in the > documentation for your code: > > The whatchamacallit library provides all of the bindings of > libwhatchamacallit. See the whatchamacallit manual for a detailed > listing of the available functions. Yes, you report the algorithm for mapping the names. How is this different from name mangling in C++? When debugging you sometimes have to be painfully aware of the mangling. > > OK, so this approach fails, try the alternative -- use this: > > (foreign-call "Foo" 1 2 3) > > to apply a function. Painful. Next -- use this: > > (|Foo| 1 2 3) > > to apply a function. More pain. Only painful when there is an ambiguity, which your generator can decide. Yes, a macro is local. Hence it doesn't see the rest of the bindings and can't make global decisions. You are using the wrong tool. >>>> I'm not asking for new 'incompatibilities'. I'm just asking that >>>> the language not be changed spuriously. The hurdle should be >>>> very high. >>> >>> (I think that the amount of flames on this subject in any kind of >>> Scheme related forum pretty much guarantees that it was not a >>> "spurious" change.) >> >> It surely looks like it from where I stand. > > Do you seriously believe that some editor X sent an email to the rest > saying "how about we make it case sensitive", and after a quick round > of yawning emails just put it in the draft? Irrelevant. Whether they had a heated argument or rolled the dice doesn't matter. They did somethings seriously painful for everyone else. Again, I ask. Imagine the converse in C. Do you seriously think that any future standard that changed the case sensitivity of C would be accepted by anyone, no matter how heated the argument was intentionally? Why are Scheme users not respected the same way? > I don't think I've ever > seen a single schemer who wouldn't flame you for days about it if he's > on the other side or will tell you just how much he agrees with you if > he's on the same side. BTW, there's at least one editor who has > opposed case sensitivity (I'm pretty sure of that, but I'm too lazy to > grep my email). Also, you might find this: > > http://lists.r6rs.org/pipermail/r6rs-discuss/2006-November/ > 001093.html > > interesting. (The poll results page is still there.) Again, look at the analogous argument for C. Why are Scheme users worth less? >> Good, then don't bring them up. > > Um, you're the one who said that not conforming was a value in some > way. No. I didn't. I said that it was a non-goal and hence any argument for conforming is very weak. Please read what I wrote. >> At any rate, whether we want it to be or not, it is primarily a >> teaching language. We can change it in the hopes that it becomes >> the bulk programming language that Java or C++ is, but I strongly >> suspect that you wouldn't succeed, and you'd make it a worse >> teaching language in the process. Who would benefit? > > I fail to see the logic here. If it's "you're likely to fail in > getting Scheme to be more than a teaching language -- so don't try to > do so", then it's a bad point to make. You can try all you want, but don't make it a worse teaching language in the process. >>> So yes, it is a good language to teach -- and I continue to do so. >>> But it's a damn good language to use for the rest of your >>> professional life as a programmer, and keeping people as active >>> Scheme users is much more important to me. >> >> As much as I wish that what you say is true, it plainly isn't. > > *sigh* > > I've seen too many Schemers (present and ex) who express similar > self-fulfilling prophecies. It wasn't self-fulfilling 20 years ago. But it hasn't changed. If anything, it is less used for teaching now than it was in the early 90s. >> There are many other reasons why the Lisp languages are not used in >> industry. > > Yes, yes -- AI winter, perenofobia, "recursion is for geniuses" aka > "what? no loops?", "what? no classes?", macro-phobia, etc etc etc. > (Oh, and there are some myths that are happily dead, including "GC??" > and "Eight Megabytes and Constantly Swapping".) They are not dead. I run into them every day in industry. Very large hurdle. > "Teaching language" is definitely one of the more powerful myths that > has been plaguing Scheme in a very real way. (My guess would be that > Lisp in general would suffer from it too, if it weren't for Scheme to > take most of the hit instead.) Lisp never had that myth, even before Scheme became 'popular'. It was an 'AI' language. And Common Lisp has loops and classes, and recursion is not considered the primary structuring paradigm, etc. What failed? You can bring a horse to water, but you can't make it drink. For whatever reason, and as I said, we probably disagree on those two, the Lisp family of languages has never been popular with programmers as a whole. Don't blame the teaching myth on it. If anything, a language widely taught should have had an easier acceptance than one not exposed to as many people. >> Don't you think that it is far more likely that the commonalities >> between Common Lisp and Scheme (of which being primarily a teaching >> language is not one) had something to do with their lack of success >> as commercial languages? > > And if that's true, your concluding that we should all pack up and go, > right? I mean, why bother with R-any-RS, if it boils down to the > syntax used in a few fringe college courses? And IEEE standard just > for this? That might make sense only as a "hello world" example for > writing *real* standards. I'm not saying pack up and go. But don't do anything that hurts the one (partial) success that it has had. > (And BTW, this also explains (to me) the R2RS sentimentalism -- if > that's all there is to it, then we don't need much more than the > lambda calculus. Small is better, and extremely small is better.) Small is better because unless you factor things extremely well, the mental complexity grows as some non-linear power of the elements. Thus, fewer elements, leads to less mental complexity. If we wanted a large language, we could have adopted CLtL with minor changes -- they thought through many, many features, longer than the Scheme community has, and they were almost always already implemented and in active use. Smallness was part of the 'cuteness' of Scheme. 'Ma, look at how little makes a practical language'. I suspect that's one of the reasons many of us liked it. Fewer distractions/hurdles when thinking about something hard. > >> When I output things for other languages, I use strings, not >> symbols. When I use a foreign-language interface, I define the >> linkage using strings, not symbols. >> >> They never get in my way. Not once. > > See above, and > >> And remember, different languages have different rules for what >> constitutes an identifier. >> >> Would you then advocating changing the rules in Scheme so that >> it matched these external constraints? And which ones, then? > > in the rare case that there is an identifier syntax that is not > allowed in Scheme, having a macro generate an identifier through > `string->symbol' will work as usual -- but I'll need to use |...| to > access that binding. But in practice, can you name a popular language > that is used to create dynamic libraries with identifiers that are not > allowed in Scheme? (And no, C++ obfuscation is not a valid example.) C++ is valid. That's what a lot of industry uses. And your problems seem to be one sided. Imagine exporting a binding to other languages. Scheme allows (and often uses) '-' as a constituent of identifiers. Most other languages ('-' denotes infix subtraction) do not. You have to mangle one way anyway, as these other languages don't have a quotation mechanism to add a non-standard identifier. So I guess you are only interested in importing things into Scheme, and not exporting them out. Isn't that prima-facie evidence that you are not really considering Scheme a first-class language? And if you do, the problem exists both ways, so handle it in some way that takes care of it, and you are done. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
