On Feb 21, Guillermo J. Rozas wrote: > >> I have no idea what you are talking about here. What starting > >> point? > > > > The fact that *most* "ordinary" people don't use a language with a > > notion of upper and lower case. > > But most of the world is learning English as well, which is largely > case insensitive.
Same argument as before. "I mean you learn to speak american in school no? Why don't you use it then??" > >> 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")) and you *can't* automate this with a macro for the obvious reason. 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. 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. > >> 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? 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.) > >>> So on one hand you argue for case-insensitivity because it's > >>> "what ordinary people are used to", and on the other you argue > >>> about for case insensitivity because it doesn't conforms to what > >>> "programmers in other programming languages expect"? > >> > >> No. Non-conformism is not a goal. Being different is not a > >> goal. But being the same is not a goal either. Thus changing > >> because other programmers expect it is not a goal. > > > > The two goals that matter to me wrt case-sensitivity have nothing > > to do with what other programmers expect. > > Good, then don't bring them up. Um, you're the one who said that not conforming was a value in some way. > 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. > > 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. > 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".) "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.) > 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. (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.) > I really think you are barking up the wrong tree, but in the > process, by (apparently) intentionally ignoring the one partial > success that Scheme has had, you may end up ruining it even for that > purpose. [This is important enough IMO that I'll reply to it separately.] > >> After all, programmers are used to each language having its own > >> peculiarities. > > > > Yes -- and designers are used to trying to get the amount of > > peculiarities smaller when not needed. > > Really? That has never been a goal of language design, as far > as I can tell. > > Otherwise, we may as well all use C or Java. Let's reduce the > peculiarities to the empty set! You must be using a different sense of "peculiarity" than I am. > 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.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
