Wed Sep 3 04:45:31 EDT 2008
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:
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
> 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.
I've seen too many Schemers (present and ex) who express similar
> There are many other reasons why the Lisp languages are not used in
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
[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!
More information about the r6rs-discuss