Slashdot Mirror


Draft Scheme Standard R6RS Released

Watson Ladd writes, "The new version of the official Scheme standard has been released as a draft (PDF)." From the draft: "[This] report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have an exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including imperative, functional, and message passing styles, find convenient expression in Scheme."

235 comments

  1. Hurray! by Anonymous Coward · · Score: 5, Funny

    (I (for one (welcome (our new (Scheme (overlords.))))))

    1. Re:Hurray! by Lachryma · · Score: 3, Funny

      shouldn't this be
      (welcome '(I ((for one))) '(overlords (our new Scheme)))
      ?

    2. Re:Hurray! by menkhaura · · Score: 2

      Forth mixing with are not you?

      --
      Stupidity is an equal opportunity striker.
      Fellow slashdotter Bill Dog
    3. Re:Hurray! by drgnvale · · Score: 0, Flamebait

      No, the original reads more like lisp and scheme code than your garbage.

    4. Re:Hurray! by WilliamSChips · · Score: 2, Informative

      Functions in Forth are at the end, in Lisp are at the beginning.

      --
      Please, for the good of Humanity, vote Obama.
    5. Re:Hurray! by Anonymous Coward · · Score: 0

      (welcome ((for one) I) (overlords ((Scheme new) our)))

    6. Re:Hurray! by sickofthisshit · · Score: 1

      No, it should be something more like

      (welcome? I (make-new-overlord us 'Scheme))
      --> T

    7. Re:Hurray! by sickofthisshit · · Score: 1

      Urgh. It should return #t. Sorry, Schemers.

  2. 142 page PDF... by LiquidCoooled · · Score: 1

    I will post comment after reading (give me a few days)

    Who knows enough to condense it into a few sentences?

    --
    liqbase :: faster than paper
    1. Re:142 page PDF... by starfishsystems · · Score: 1
      Who knows enough to condense it into a few sentences?

      You're joking, of course. It's a language specification.

      If you insist on having a condensed version, it would read:

      "This is a specification for the Scheme programming language. [specification deleted]"
      --
      Parity: What to do when the weekend comes.
    2. Re:142 page PDF... by brilinux · · Score: 1

      Well, I have the old on on me right now; it is about 50 pages... I really hope that they do not turn it into ... something that is not Scheme...

    3. Re:142 page PDF... by drgnvale · · Score: 1

      Well, the R5RS was only 50 pages, as has been noted, and could be read in a couple of hours, and digested within a week. I haven't read the new one yet, but I'm told the extra bulk comes from standard libraries, which it is very nice to see added to scheme. If only Common Lisp could grow like this...

    4. Re:142 page PDF... by Anonymous Coward · · Score: 0

      You could have read about this a few days ago. Sites like Digg, Reddit, and Google Groups, and the mailing lists of essentially every Scheme implementation, were carrying this news. Of course, it's nearly a week old now, so it's posted about here at Slashdot.

    5. Re:142 page PDF... by Anonymous Coward · · Score: 0

      So why are you even here?

      Oh, right: you're an idiot troll.

    6. Re:142 page PDF... by convolvatron · · Score: 1

      i think there is some danger of that. section 7 in particular i found
      very disturbing, writing unix-style script execution syntax into
      the language. its clear that they are going for pragmatism and adoption
      rather than the clarity that was present in the earlier definition.

      frankly really i wish they had just stuck to core+sfri (and left
      hygenic macros as an sfri)

    7. Re:142 page PDF... by John+Nowak · · Score: 3, Insightful

      This is only distributing until you remember that almost every implementation has to implement something similar, often in a way that's slightly different and incompatible with everything else. I'll agree that there is a danger, yes.

      However, I personally feel that R6RS is nearly at the perfect point. It is still very heavily leaning towards simplicity and clarity, but includes the bits that everyone ends up implementing anyway in non-standard ways. The truth is that modern unix systems are ugly, i/o is complicated, and a lack of a standard macro system (see the syntax-case variants) is horribly annoying. R6RS does reflect all of this, but I think trying to cleanly negate issues is far better than simply ignoring them. There are a few things that I think overreach, but I'm very happy with 95% of the additions. This is a standard we can make use of for the next 10-20 years.

    8. Re:142 page PDF... by jelle · · Score: 1

      "Who knows enough to condense it into a few sentences?"

      Here is comes: you'd be better off using the whitespace programming language: http://compsoc.dur.ac.uk/whitespace/

      It would result in better readable and maintainable code.

      --
      --- Hindsight is 20/20, but walking backwards is not the answer.
    9. Re:142 page PDF... by alienmole · · Score: 1

      Which things do you think overreach? Just curious.

    10. Re:142 page PDF... by alienmole · · Score: 1

      The language definition part of R6RS is still about 50 pages. The rest is libraries and other stuff.

    11. Re:142 page PDF... by John+Nowak · · Score: 2, Interesting

      For one, I'm not sure unicode should be mandatory. I believe it should be described as a recommended component, but not necessary to call your language R6RS-compliant. Would I use a Scheme without unicode support? No, but for some applications and on some systems it isn't necessary. It is great to standardize on an interface, so all that do implement it (and most will) will do it compatibly, but it shouldn't be mandatory. Other things that should probably be recommended by not required are exceptions and the hygienic macro system (although R5RS was no better on this point). I'm less sure about the macro system being recommended instead of required actually. Section 7 should be strictly optional. It already is in a way, but this should be more explicit. The I/O portion of the library is huge -- It does a lot, and is quite flexible. That's great, but it is a rather onerous implementation requirement, and should be recommended, not required... and maybe even broken up into two pieces. Finally, I'm not sure I agree with keeping mutable pairs (set-car!, set-cdr!), but again this is no different from R5RS. The rest of my things are trivial... 'when' and 'unless' aren't needed. Ultimately, anything that makes R6RS significantly harder to implement should be moved from "required" to "recommended". R6RS-compatible scheme can then clearly say which of the five or so "recommended" groups of functionality they suppose; In reality, probably most will support all five, but for some Schemes it just doesn't make sense to do so.

    12. Re:142 page PDF... by Anonymous Coward · · Score: 0

      It will be more maintainable than Scheme and Lisp if it's coded in Caml Light.

    13. Re:142 page PDF... by alienmole · · Score: 1

      Thanks for the reply. On the question of required vs. recommended features, it seems to me that if R6RS is to have much meaning as a standard, it should require as much as possible, within reason. Otherwise, you can't write serious R6RS-compliant programs - you can only write R6RS-compliant programs for implementations which support X, Y & Z optional features. In environments where some R6RS features don't make sense, they'll of course be omitted, but it doesn't make much sense to dilute the requirements for other implementations because of that. I don't think a single standard can cater to all the needs - look at Java, with J2ME, J2SE, J2EE etc. I also don't think whether something is hard to implement should affect anything by itself - the language isn't designed for the implementor's convenience, although aspects of it may be simple enough that it sometimes seems that way.

    14. Re:142 page PDF... by John+Nowak · · Score: 1

      Scheme, as a pedagogical language, should keep the implementors' convenience in mind.

    15. Re:142 page PDF... by alienmole · · Score: 1

      The implementor's convenience should only be a pedagogical issue if you're teaching how to implement Scheme. Afaik, courses that teach how to implement Scheme always teach a simplified subset anyway, so that wouldn't really change with R6RS.

      I see a separate issue with the elegance of the language, which often correlates with simplicity of implementation. But I don't think requiring some implementation complexity, particularly in libraries, in the interests of supporting portable code, is a bad thing. Scheme isn't purely a pedagogical language.

    16. Re:142 page PDF... by John+Nowak · · Score: 1

      Certainly true in large part. I think much of this comes down to an issue of aesthetics for users.

  3. Qs by Anonymous Coward · · Score: 0

    Does using scheme make sense when building a windows GUI application? What about a web application? System scripts? Back end to a database?

    Is it more or less powerful than, say, C++, Java, or Python?

    1. Re:Qs by CRCulver · · Score: 4, Informative

      The GNU project adopted Scheme (with the Guile interpreter) as its official scripting language. Applications are not meant to be written in Scheme, but applications can expose functionality to the user through a Scheme interface. That is to say, plugins for extensible applications could be written in Scheme. The Gimp is one of the most noteworthy applications with a Scheme interface, and much of the lower-level functionality of GNU Lilypond is reached with Scheme.

    2. Re:Qs by brilinux · · Score: 2, Informative

      Hmmm... you will need libraries and such for that, though some people do use Scheme for all of those things (see http://www.plt-scheme.org/ and http://www-sop.inria.fr/mimosa/fp/Bigloo/). I have personally used it for web applications, though I usually use common lisp and ocaml for that. In fact, if you are looking for an alternative to C++, Java, or Python, I must recommend OCaml. Look at this book. In fact, I wrote an interpreter for R5RS in OCaml...

    3. Re:Qs by RAMMS+EIN · · Score: 2, Interesting

      ``What about a web application?''

      Scheme's first-class continuations are actually a very good match for web programming, where a user can re-submit an old form at any time. Basically, with languages that lack call/cc, you will have to break up your application in little pieces to account for this, whereas call/cc allows you to structure your application like a regular one, and the language implementation will deal with the issues.

      When it comes to practicality, it all depends on the implementation. The Scheme report is (deliberately) very minimal, and you can't write many Real World programs using only standard Scheme. However, implementations often provide features and libraries that make Scheme practical for real projects, to some extent.

      ``Is it more or less powerful than, say, C++, Java, or Python?''

      It depends what you mean by "powerful". In the programming language community, the answer would likely either be "Scheme is more powerful", because its constructs are very flexible (e.g. it has first-class functions and continuations, which the languages you mention lack or only have to a limited extent), or "No", because all these languages are Turing-complete and thus can do everything the others can.

      However, outside the programming language community, the question probably refers not just to the language, but also to the libraries, and there Scheme could reasonably be said to lose out to at least Java. On the other hand, there are Scheme implementations that can call Java code, and thus access everything that is available for Java...

      --
      Please correct me if I got my facts wrong.
    4. Re:Qs by portmapper · · Score: 1

      > However, outside the programming language community, the question probably refers not just to
      > the language, but also to the libraries, and there Scheme could reasonably be said to lose out
      > to at least Java.

      Without extensive libraries, most programming languages are not very useful for many
      common tasks.

    5. Re:Qs by Anonymous Coward · · Score: 0

      Chicken Scheme is also quite nice. Compiles to C code, has a lot of libraries, and is supported by things like SWIG, so it's (relatively) easy to call functions written in C/C++.

    6. Re:Qs by RAMMS+EIN · · Score: 1

      ``Without extensive libraries, most programming languages are not very useful for many common tasks.''

      True, but that's neither here nor there. A language can make an excellent text processing, web programming, scripting, etc. language without needing extensive libraries.

      --
      Please correct me if I got my facts wrong.
    7. Re:Qs by Goaway · · Score: 1

      Here, let me help you parse the replies to your questions:

      No, no, no, no, no, no and no.

    8. Re:Qs by grumbel · · Score: 1
      Does using scheme make sense when building a windows GUI application?

      Short subjective answer: No

      Scheme is a nice language and has some very interesting properties, so learning it is well worth it, but its really not the lanuage that you would want to use for your daily work, for that it simply lacks a lot of convenience features (++a becomes (set! a (+ a 1)) and it also lacks standardization bejoint its very core, which means that every Scheme implementation comes with its own set of libraries for all kinds of jobs, even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.

      In terms of 'power', yes its more powerfull, with macros I can do a heck of cool stuff that isn't possible in most other languages, but then those tricks seldomly result in readable code and you can get very similar effects with much cleaner tools like Rubys blocks, generators and similar things provided by other language.

      To make it short, Scheme is for most part an academic language, worth learning it is, worth using not so much.

    9. Re:Qs by bidule · · Score: 1

      (define-macro (increase! var . rest)
          `(begin
                  (set! ,var (+ ,var ,(if (null? rest) 1 (car rest)))) ,var))

      (increase! a)
      (increase! a (+ 1 2))

      Obviously you could use (++ a), but that is not important.

      --
      ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
    10. Re:Qs by John+Nowak · · Score: 4, Insightful

      but its really not the lanuage that you would want to use for your daily work, for that it simply lacks a lot of convenience features (++a becomes (set! a (+ a 1))

      This just shows a lack of fundamental understanding of how one typically writes Scheme programs. If you're incrementing variables to the point where that becomes a concern, you're completely misusing the language.

      even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.

      Again, this shows you have no experience with the language, or you've been using it horribly wrong. There's no reason you should ever need a for loop in Scheme. If you're going to use Scheme as mostly imperative language, you're better off with Python or similar.

    11. Re:Qs by bidule · · Score: 1


      I have worked on a database modeler and a complete IDE under Windows. It was a bastardized Scheme with objects, but still...

      So I have to say: done, done, maybe, maybe. And yes, if only for the ability to execute any code while stopped in the debugger.

      --
      ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
    12. Re:Qs by Anonymous Coward · · Score: 0
      The Gimp is one of the most noteworthy applications with a Scheme interface

      That explains a thing or two...

    13. Re:Qs by Abcd1234 · · Score: 1

      Sure, if you enjoy rolling your own FastCGI/HTML generation/string processing/database interface/ libraries.

      Languages without extensive first/third parties libraries are useless. And languages like Scheme and Lisp are particularly crippled because they don't even have a standard extension mechanism. I say this having explored the idea of rolling some interesting applications in Lisp... why would I spend half my time writing libraries when I could switch to Perl/Python/Ruby/C/C++/Java/etc and just get things done?

    14. Re:Qs by RAMMS+EIN · · Score: 2, Interesting

      ``Languages without extensive first/third parties libraries are useless.''

      I won't argue this point further. I've already stated that languages without _extensive_ libraries can still be useful in specific domains. I still stand by that view.

      ``And languages like Scheme and Lisp are particularly crippled because they don't even have a standard extension mechanism.''

      Huh? The package system is a standard feature of Common Lisp. R6RS may standardize a module system for Scheme (although this is not certain yet); in the absence of that there is SLIB, which provides a de-facto standard mechanism.

      --
      Please correct me if I got my facts wrong.
    15. Re:Qs by Abcd1234 · · Score: 1

      Huh? The package system is a standard feature of Common Lisp.

      Ah, sorry, as I recall it was the foreign function interface that varied from implemention to implementation.

      As for your first statement, sure, any language can be tailored to be useful in a particular domain. Can you name such a domain for Scheme? I can't.

    16. Re:Qs by Talchas · · Score: 1

      [even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions]

      Umm, lots of stuff yes, for loop, no. R5RS specifies the syntax do, which is basically a for loop. For example

      (do ((vec (make-vector 5))
           (i 0 (+ i 1)))
          ((= i 5) vec)
        (vector-set! vec i i))

      Produces #(0 1 2 3 4) and is equivalent to

      int[] arr = new int[5];
      for(int i = 0; i !=5; i++){
        arr[i]=i;
      }
      return arr;

      --
      As the Americans learned so painfully in Earth's final century,free flow of information is the only safeguard against...
    17. Re:Qs by RAMMS+EIN · · Score: 1

      ``As for your first statement, sure, any language can be tailored to be useful in a particular domain. Can you name such a domain for Scheme? I can't.''

      Ah, but I was only refuting your claim that no language can be useful without extensive libraries. I wasn't talking about Scheme, specifically.

      If you do want examples of what Scheme has been successfully used for, well, some examples:

        - As a vehicle for teaching the fundamentals of programming, programming languages, and computers (see, for example, SICP and the courses based on it)
        - As an extension language (in festival, for example)
        - I've used Scheme for a few projects: a text processing language (transforming text with embedded code to multiple output formats), a sudoku-solver, a network simulator, an HTML-generation library. I've also used it to prototype algorithms that I later implemented in Java.
        - Other people have implemented mail filters, web frameworks, wiki's, theorem provers, and probably countless other things in Scheme

      And, of course, when you look beyond the standardized core language and consider the implementations, you can find some more impressive examples, like DrScheme (at least, I think that's written in MzScheme).

      --
      Please correct me if I got my facts wrong.
    18. Re:Qs by WilliamSChips · · Score: 1

      DrScheme is written in MzScheme.

      --
      Please, for the good of Humanity, vote Obama.
    19. Re:Qs by countach · · Score: 1

      You could define a ++ macro, but most Scheme programmers, who are functional programming zealots would consider it bad style.

      Yes Scheme is a fine langauge for writing Windows gui programs, or at least it would be if it wasn't so hard to find a top notch development environment and professional cross platform gui toolkit that is ready to pick up and use.

    20. Re:Qs by smallpaul · · Score: 2, Interesting

      Given the fact that Guile is more than just Scheme and that Scheme has very little traction as a scripting language, Guile is essentially "yet another scripting language" in competition with Python, Ruby and the rest. At one point there was a pipe dream that other languages would be compiled to Guile but that never materialized. In retrospect, Guile was a huge mistake for the FSF. Despite their long-term investment in Guile, Python is more popular for programming Gnome than Guile is. If the translation concept had worked then Guile might have been a reasonable project. But as your post demonstrates, since development actually began, Guile has essentially been just another Scheme implementation.

    21. Re:Qs by grumbel · · Score: 1

      I know do, but I hardly ever used it, since its pretty much unreadable, beside from that it just demonstrates the throuble with Scheme, in Ruby I can write (0..5).to_a in Python I can write range(0,5) in Scheme I have to write:

      (do ((vec (make-vector 5))
                (i 0 (+ i 1)))
              ((= i 5) vec)
          (vector-set! vec i i))

      or

      (let loop ((i 0)
                            (lst '()))
          (if (vector (reverse lst))))

      or similar equally obscure constructs. I know that I could fix it with a simple macro, but again, thats kind of the point, I have to fix all the flaws of the language myself, in Ruby and Python simple stuff works out of the box, in Scheme it doesn't.

    22. Re:Qs by grumbel · · Score: 1
      There's no reason you should ever need a for loop in Scheme.

      How else would you write this?

      for i in xrange(1,10):
      print i

      Sure I can sometimes use recursion, but for such simple jobs it really doesn't lead to readable code.

    23. Re:Qs by eraserewind · · Score: 1

      Yeah, GNU applications are mandated to be written in C, which (as a C programmer) I find a highly strange choice. They even expressly mandate against C++, which for appliction programming, while far from ideal, is worlds better than plain old C. So just because GNU mandates something doesn't necessarily make it a good idea. (like using a language that non CompSci students have difficulty with as the "end user" scripting interface).

    24. Re:Qs by John+Nowak · · Score: 1

      First of all, that's not exactly a fair comparison -- You're using an xrange, and scheme does not have a similar thing out of the box (although there are certainly SRFIs that cover this). You're also omitting the function declaration -- You'd need this in Python (or similar), but not for the example. You do need it for the Scheme example though, which makes it look artificially long. Below is much nire fair way to compare a python-like language compared to scheme.

      def numprint:
              for i = 1 while i = 10:
                      print i
                      i = i + 1
      numprint

      (define (loop i)
          (cond ((= i 10)
                    (display i)
                    (loop (+ i 1)))))
      (loop 1)

      Not really much of a difference, is there? It is still unbalanced because the Scheme function takes an argument, so it could count from 2, 3, 4, etc. Really, the python-like example should be this to match:

      def numprint(n):
              for i = n while i = 10:
                      print i
                      i = i + 1
      numprint

      In short, yes, the python version is much smaller... when you use high level constructions not available in R5RS. Big deal.

    25. Re:Qs by John+Nowak · · Score: 1

      Sorry... those = things should be =. My key is rather stuck today.

    26. Re:Qs by be-fan · · Score: 1

      First, Common Lisp does have a standard packaging/module mechanism. Moreover, there are a ton of libraries available for Common Lisp, as well as interfaces to C libraries.

      --
      A deep unwavering belief is a sure sign you're missing something...
    27. Re:Qs by be-fan · · Score: 1

      How is 'do' any more obscure than '(0..5).to_a'. What the hell does the latter even mean?

      --
      A deep unwavering belief is a sure sign you're missing something...
    28. Re:Qs by chthon · · Score: 1

      Or incf and decf.

    29. Re:Qs by hanwen · · Score: 1
      The Gimp is one of the most noteworthy applications with a Scheme interface, and much of the lower-level functionality of GNU Lilypond is reached with Scheme.

      Although, curiously, GIMP uses the SIOD interpreter rather than GUILE.

      BTW, RMS doesn't want to use GUILE for Emacs, which makes me wonder if he's serious about GUILE as the Gnu extension language.

      --

      Han-Wen Nienhuys -- LilyPond

    30. Re:Qs by Abcd1234 · · Score: 1

      Huh, no kidding? Well, maybe you should tell reddit.com (one of Paul Graham's spinoffs). Because, you see, they switched from Lisp to Python a while back (sorry, I can't find the original block entry). And why? Because, to quote:

      "If Lisp is so great, why did we stop using it? One of the biggest issues was the lack of widely used and tested libraries. Sure, there is a CL library for basically any task, but there is rarely more than one, and often the libraries are not widely used or well documented."

      So, sure, there may be tons of libaries, but who wants a library that's poorly documented, poorly tested, and may not even work on your CL implementation?

      Moreover, in addition to the ffi, things like sockets and threads, which I think we can all agree are important, aren't standardized across implementations, which just makes things harder.

      Now, is this a problem with the language? No, it's the implementations. But the fact is that until you can grab a library off the net and drop it into your Lisp implementation of choice (assuming they've implemented the standard) and hit the ground running, it will, like Scheme, Smalltalk (my poison of choice), and others, remaining a niche language.

      Unfortunately, this is, in part, also an issue of critical mass. Unless you can get people using your language, there won't be high quality, well tested modules for it. OTOH, Perl, Python, and Ruby have all proved it's possible... 'course, it helps that the people running those projects aren't sequestored in ivory towers (well, okay, Guido just deigns to join us down here, occasionally).

    31. Re:Qs by swdunlop · · Score: 1

      That is because the great albatross of legacy EMACS code is written for elisp -- which is dynamically scoped instead of Scheme's lexical scope.

    32. Re:Qs by be-fan · · Score: 1

      It's not such a simple dismissal. Reddit is an online, web-based program. Lisp is missing something in these areas, because Lisp is a pre-web phenomenon language. Most of the people who learned it did so before the web became a big thing, and as a result they're often not working in web-related tasks, and thus not creating web-related libraries. The same could be said for C, really. Python has better, easier-to-use, easier-to-drop-in libraries for a lot of web related programming than C, but that doesn't mean that C has unusably few libraries.

      Whether Lisp has sufficient libraries for your task depends on your task. It also depends on your budget. A lot of the best Lisp libraries are in implementations like Allegro and Lispworks. Their price is very reasonable for a commercial outfit, but often out of the range of hobbyists and OSS programmers.

      --
      A deep unwavering belief is a sure sign you're missing something...
    33. Re:Qs by TheRealFoxFire · · Score: 1

      See for example SISCweb.

    34. Re:Qs by grumbel · · Score: 1
      How is 'do' any more obscure than '(0..5).to_a'. What the hell does the latter even mean?

      (0..5)
      defines a range,
      .to_a
      is a method call (Ruby is an OO language) that converts the range to an array and returns it. If I would want to let it print the numbers I could write:
      (0..5).each{|i| puts i}
      which would be analog to
      (for-each (lambda (x) (display x)(newline)) '(0 1 2 3 4 5))
      . The part where Ruby gets interesting is if you have to chain methods, ie. if you want to sort and map the Array before printing it
      (0..5).map{|i| -i*i}.sort.each{|i| puts i}
      while in Scheme you would write
      (for-each (lambda (x) (display x)(newline)) (sort (map (lambda (x) (- (* i i))))))
      Now ok, this might simply be a taste issue, but I find the way in which I can write those map/sort stuff in Ruby much more natural and easier to read then in functional languages, since in Ruby everything is in the natural order, things you do first are left, things you do later on the right, while in Scheme everything is the other way around. This especially becomes an issue with longer chains, add to that Schemes () syntax and you end up with something that isn't really all that readable anymore.
    35. Re:Qs by DragonWriter · · Score: 2, Insightful
      even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.


      Isn't a central point of Scheme that it is properly tail-recursive, functional programming language? While I'm not all that familiar with Scheme, wouldn't you usually use a recursive function rather than a for-loop in such a language?

      A for-loop isn't a task, its a construct that is natural in the idiom of certain languages for accomplishing certain tasks. Its not the idiomatic way to approach those tasks in all languages, though.
    36. Re:Qs by namekuseijin · · Score: 1

      "You're also omitting the function declaration -- You'd need this in Python (or similar)"

      not at all! it's a scripting language! You don't need no stinking declarations! ;)

      anyway:

      (for-each (lambda (x) (display x)(newline)) '(1 2 3 4))

      for-each is part of the R5RS standard library and of course can be fully emulated in terms of a recursive function wrapped in a macro for syntax sweetness...

      you can also emulate python's print:

      (define (print . args)
      (define (loop ls)
      (if (null? ls) (newline)
      (begin (display (car ls))
      (loop (cdr ls)))))
      (loop args))

      as well as a range function that returns a list:

      (define (range a b)
      (if (= a b) '()
      (cons a (range (+ a 1) b))))

      so, now, you're code looks almost like Python's one

      (for-each print '(range 1 10))

      oh, ok, Scheme doesn't have a simple for, so let's do it:

      (define-syntax for
      (syntax-rules (in ->)
      ((for i in ls -> cmd ...)
      (for-each (lambda (x) (cmd x) ...) ls))))

      so, again:

      (for i in (range 1 10) -> print)

      I could go on and on and end up having a completely customized Scheme.

      With some effort, you can redefine for-each so that it takes iterators rather than lists. Or both. Remember, Lisp is a programmable programming language.

      --
      I don't feel like it...
    37. Re:Qs by Anonymous Coward · · Score: 1, Informative

      >>even trivial tasks like a for-loop you have to either code yourself or rely on non-portable extensions.

      WRONG!

      From the R5RS documentation:
              'Do' is an iteration construct. It specifies a set of variables to be bound, how they are to be initialized at the start, and how they are to be updated on each iteration. When a termination condition is met, the loop exits after evaluating the s. ...

      (do ((vec (make-vector 5))
                (i 0 (+ i 1)))
              ((= i 5) vec)
          (vector-set! vec i i))

      http://www-swiss.ai.mit.edu/~jaffer/r5rs_6.html#SE C36

    38. Re:Qs by grumbel · · Score: 1
      While I'm not all that familiar with Scheme, wouldn't you usually use a recursive function rather than a for-loop in such a language?

      Of course you could write it via recursion, but does that lead to simpler or better readable code? I don't think so. Some problems are just linear in nature and a standard for loop is an easy and well readable way to solve those problems. Even Scheme has its for-each looping construct, since always using recursion would just get very ugly in such cases. However since Scheme lacks support for generators, function overloading or OO, the for-each construct stays rather limited, it doesn't even work with vectors, but only with lists, so you are kind of stuck.

      One of the beauties of Scheme is of course that I now could start writing macros, functions and stuff to fix all those short commings. In Scheme a for-each construct isn't magic, its something you can easily build yourself. But for a lot of simple problems it just gets very annoying if you have to implement half the programming language yourself, which is the reason why I stopped using Scheme for serious work, its just requires more effort then worth it.

    39. Re:Qs by Talchas · · Score: 1
      in Ruby I can write (0..5).to_a in Python I can write range(0,5) in Scheme I have to write:
      and
      How is 'do' any more obscure than '(0..5).to_a'. What the hell does the latter even mean?
      (0..5)
      defines a range,
      .to_a

      is a method call (Ruby is an OO language) that converts the range to an array and returns it. If I would want to let it print the numbers I could write:

      (0..5).each{|i| puts i}
      which would be analog to
      (for-each (lambda (x) (display x)(newline)) '(0 1 2 3 4 5))
      . The part where Ruby gets interesting is if you have to chain methods, ie. if you want to sort and map the Array before printing it
      (0..5).map{|i| -i*i}.sort.each{|i| puts i}
      while in Scheme you would write
      (for-each (lambda (x) (display x)(newline)) (sort (map (lambda (x) (- (* i i))))))
      Now ok, this might simply be a taste issue, but I find the way in which I can write those map/sort stuff in Ruby much more natural and easier to read then in functional languages, since in Ruby everything is in the natural order, things you do first are left, things you do later on the right, while in Scheme everything is the other way around. This especially becomes an issue with longer chains, add to that Schemes () syntax and you end up with something that isn't really all that

      As you say, you could also do #(0 1 2 3 4 5). Also in languages like C/C++ or Java you have to do something equivalent to what you have to do in Scheme, and if you were doing it a lot in any of them, you would write a function to make it about as simple as in Ruby or Python. In Ruby or Python, there are a lot of nice shortcuts like this built in.

      Second, about the ()s, are they really that much worse than (0..5).map{|i| -i*i}.sort.each{|i| puts i}? In there you have the (a..b) range notation, procedure calls via '.', and two closures with {...} enclosing the body and |...| enclosing the arguments.

      Third, if you were using (display x) (newline) a lot, you should really (define println (lambda (x) (display x) (newline)), which simplifies the scheme examples to:

      (for-each println '(0 1 2 3 4 5))
      (for-each println (sort (map (lambda (x) (- (* i i))) '(0 1 2 3 4 5))))

      Which (ignoring the need to define the whole list outright) is not really any worse than the Ruby.

      Finally, about the inside-to-out instead of left-to-right, its definitely different and it definitely requires a time of adjusting. I'm not sure whether I think its worse or not.

      --
      As the Americans learned so painfully in Earth's final century,free flow of information is the only safeguard against...
    40. Re:Qs by DragonWriter · · Score: 1
      Of course you could write it via recursion, but does that lead to simpler or better readable code?


      Better readable to whom? To someone whose spent 20 years mostly working with imperative languages? Clearly not. To someone whose spent the same time working with functional languages? Probably. To someone whose never touched a computer? Probably depends on the particular problem being addressed.

      If you are calculating the Nth Fibonacci number, a recursive process (at least to me) seems more natural than an iterative one; if you are stepping through a list and transforming each member in a common way, an iterative description seems more clear (particularly a for-each kind of approach.) At any rate, with a functional language its usually fairly easy to define both C-like for loops and for-each loops, though they often aren't core language function (though where they aren't, they are usually core library features.)

      And, ultimately, I think that's the beauty of functional languages: control structures that imperative languages either have or don't have as language features become library features that you can define, add, and often extend as you need. If I want a more robust control structure in a functional language, I can build it like I would any other function. If I want a more robust control structure in C, my options are more limited.

      There is a reason why popular languages like Java and C# are incorporating functional features: its hard to beat them for expressiveness and adaptability, which are important in practical applications. Scheme and other similarly "pure" languages (heavily focussed on one paradigm, more than is usually necessary or even desirable in many uses) are important, I think, both for their use in narrow domains, and for the concepts which migrate from them into more generally-used languages, not as general replacements for the more widely-used languages.
    41. Re:Qs by Anonymous Coward · · Score: 0
      (for-each (lambda (x) (display x)(newline)) '(1 2 3 4))
      The common idiom for writing '(1 2 3 4) is SRFI-1's "iota" function. (iota 4 1) will give you the list '(1 2 3 4).
    42. Re:Qs by grumbel · · Score: 1
      Second, about the ()s, are they really that much worse than (0..5).map{|i| -i*i}.sort.each{|i| puts i}? In there you have the (a..b) range notation, procedure calls via '.', and two closures with {...} enclosing the body and |...| enclosing the arguments.

      Yes, the () are much worse for that exact reason, in other languages you have =, {}, (), || and friends, all do their special jobs and are easy to spot with the eye, since they simply look different from each other. In Scheme on the other side everything is (), especially with macros this gets confusion since you can't even be sure how something will get evaluated or if it gets evaluated at all, you can't even tell if its a macro or a function without looking it up.

      The throuble with Scheme isn't its lack of power, but simply that it has to much of it. Python, Ruby and Co. on the other side take a tiny bit of Schemes power and pack it into a human readable syntax, one that has dedicated syntax for dedicated constructs, an assignment looks different from a for loop and from a function call, in Scheme on the other side everything looks the same, only difference is the first name after the ().

    43. Re:Qs by grumbel · · Score: 1
      Better readable to whom? To someone whose spent 20 years mostly working with imperative languages?

      To absolutly everybody, guess why Scheme has a for-each and why don't do a (let loop (l lst) ...code... (if (not (null? l)))(loop (cdr l))) each time you need to iterate over a list. Recursion is great for some algorithms, but lots of programming code aren't algorithms from the next best algorithm books, but simply library calls patched together. If I want to sort a list these days I write sort(lst) and don't start writing a recursive quick sort algorithm.

      At any rate, with a functional language its usually fairly easy to define both C-like for loops and for-each loops

      Which again is my point, the throuble isn't that you can't define them, but that you have to define them. Scheme simply provides far to little in that area.

      Scheme and other similarly "pure" languages (heavily focussed on one paradigm, more than is usually necessary or even desirable in many uses) are important,

      Yes, they are important, but mostly for academic study, I have yet to see a "pure" language that has any larger relevance in the real world.

    44. Re:Qs by namekuseijin · · Score: 1

      thanks, man.

      and if someone doesn't like the stupid name:

      (define range iota)
      --
      I don't feel like it...
    45. Re:Qs by Procyon101 · · Score: 1

      It has nothing to do with zealotry. The reason mutable solutions should be avoided is because as long as you don't use them, your code is trivially parallelizable. The moment you mutate something, all code that touches that mutation must be run serially. This is a massive performance hit when you move your code to clusters and multi-core machines.

      All machines are rapidly becoming multi-core, so this will become an issue very soon in every problem domain, not just high performance computing.

    46. Re:Qs by alexo · · Score: 1


      Will we see a .NET implementation of R6RS?

    47. Re:Qs by Anonymous Coward · · Score: 0

      The Scheme zealots have their way of doing things, but listening to them does a disservice to you if it makes you avoid scheme.  In particular, if I found myself doing lots of increments in my code, I would write:

        (++ a)

      Almost exactly like you would in C/C++/Java/JavaScript.

      And if I thought it was more readable to use an explicit for loop, I would write:

        (for i in (range 1 10)
           (print i)
        )

      Just like you would.  Now the implementation of "++", "for", and "range" is left as an exercize for the reader.  That's the cool thing with Scheme - you can add new language constructs to turn it into *ANY* kind of programming language.  The functional only weenies who typically advocate Scheme are missing out on the rest of the spectrum.

    48. Re:Qs by Procyon101 · · Score: 1

      ;; Since you used a convienience function, I will define the same function
      (define xrange
        (lambda (min max f)
          (cond ((min >= max) '())
                      (else (f min)
                                  (xrange (+ 1 min) max f))))) ;; Now I will use it just like you did:
      (xrange 1 10 display)

  4. Thith ith awethome by brilinux · · Score: 1

    Actually, I have been carrying around R5RS with me for a while; it will be nice to suck down more print quota on r5r6 (when it is released). Scheme is quite a fun language, though as far as Lisps go, I do prefer Common. Still, for people who want to learn how to program, I generally tell them to start out with Scheme, usually using the PLT stuff, and to look at SICP.

    1. Re:Thith ith awethome by drgnvale · · Score: 1

      I don't know... maybe because they want them to understand programming concepts without having to learn a complicated syntax? Maybe they want them to see how first class functions make building extendable programs easier? Maybe there is a reason MIT and other top universities also start people off with scheme? I wish I had started out with scheme and not basic, I probably wouldn't have hated programming for so long if I had.

    2. Re:Thith ith awethome by brilinux · · Score: 1

      Because it is a small language, and one which will teach them the essentials of how to think about programming and structuring programs without the burdens of many heavier languages. And remember that I said "first language", and not "only language". While it may not be "useful" if they go into a programming career, I think that it helps to establish good reasoning and thought processes for when they do pick up other languages later.

    3. Re:Thith ith awethome by Anonymous Coward · · Score: 0

      I agree. Mind you, this was the early to mid-90's, but I first learned BASIC, Pascal, C, and then moved on to Scheme.

      Learned Scheme first is just not advisable, in my mind.

    4. Re:Thith ith awethome by John+Nowak · · Score: 1

      Scheme is a great language for teaching how to program. Knowing that is far more important than knowing the details of any particular language... these things can be picked up as needed.

    5. Re:Thith ith awethome by Dogun · · Score: 1

      Scheme syntax, while uncomplicated, is a brain-melting mess.

      Anyhow, BASIC was not the language I had in mind when I said "relevant." There are other languages out there that are at least as featureful as scheme - and more coherent of specification - that are more interesting from an engineering perspective. If you want a formal theoretical computer science background, I can understand the reason to make use of the lambda languages, but as most people learning a language couldn't give a rats ass, scheme would be the last language I teach someone.

      As far as MIT and top universities starting off with scheme, perhaps you haven't considered that the original creators and proponents of scheme might still be around and somewhat biased as to their creation? Emulation drives Berkeley and other schools to adopt similar curricula, but that doesn't mean there's a coherent reason why scheme is chosen over other languages.

    6. Re:Thith ith awethome by be-fan · · Score: 1

      The main reason would be to learn programming, instead of focusing on a language.

      People who learn C or Java get caught up in the specifics of the language, and have a hard time thinking about the underlying concepts. They think in terms of pointers and blocks of memory, instead of values and functions.

      There is a reason Scheme is taught as the first language at places like MIT, where their job is to make computer scientists, not code monkeys.

      --
      A deep unwavering belief is a sure sign you're missing something...
    7. Re:Thith ith awethome by chthon · · Score: 1

      Yes. And could you go smaller than SIOD ?

    8. Re:Thith ith awethome by Anonymous Coward · · Score: 0

      I hate to break it to you, but pointers and blocks of memory ARE values and functions. And when you understand how that works, you can write a compiler.

      Being a recent product of MIT, I'm telling you that as best I can tell, the reason it's taught there is that it's taught there. A tradition.

      There are people who would disagree with me, and they're welcome to. But I really just don't see the point.

    9. Re:Thith ith awethome by Anonymous+Brave+Guy · · Score: 1

      The main reason would be to learn programming, instead of focusing on a language.

      People who learn C or Java get caught up in the specifics of the language, and have a hard time thinking about the underlying concepts. They think in terms of pointers and blocks of memory, instead of values and functions.

      Speaking as someone with an academic CS background, who now writes high performance maths libraries for a living: while I see where you're coming from, I think the approach is backwards.

      Bit-twiddlers have real-world skills that can be used to write useful programs. People with more appreciation of the theory tend to produce better designs. These are obviously complementary skills.

      But for teaching them? I'd rather take someone who learned several real-world languages and built an understanding of the theoretical concepts based on the similarities and differences between those languages, than someone who learned the theory from the top but doesn't understand why programming with neat higher-order functions may cause a horrendous performance hit because they have no idea what's going on under the hood.

      All CS courses should teach these concepts, but IMHO they should conclude with an extensive "programming concepts" course after they've learned the basics of assembler, C, some functional language, some OO language, etc. At that point, aside from everyone having more programming experience generally, the students will have a base of knowledge to help them appreciate the similiarities and differences, rather than just quoting the textbook in an exam.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    10. Re:Thith ith awethome by be-fan · · Score: 1

      I see your point, but what I've experienced is that learning C or assembler first makes it very difficult to focus on the higher level concepts afterwards. Your brain becomes programmed to think of things first in terms of registers, pointers, etc, and you have to struggle to think of things more generally.

      What I would say, however, is that every CS program should include a course in compilers, where students write own down to the code generation, preferably for a modern machine like x86. Unlike learning ASM (which you'll have to to do this anyway), it won't just teach you the performance characteristics of the machine instructions, but will teach you exactly how high-level language constructs map to the machine.

      And of course, a class in profiling and debugging should be required, and I'm astonished that there usually isn't even one in the program. With modern super-scaler processors, where the generated ASM has only a vague resemblence to what is actually being executed, skill with a profiler is absolutely essential in tracking down bottlenecks, etc. It also teaches some intuition about where performance bottlenecks tend to lie, which avoids the tendency I've seen among many C programmers to avoid useful abstraction even in non-critical regions of code.

      --
      A deep unwavering belief is a sure sign you're missing something...
    11. Re:Thith ith awethome by Procyon101 · · Score: 1

      This just reiterates what a classic SICP is, as the book (and MIT's 6.001 for which it is a text) has the beginning programmer first learn the higher order concepts, then use them to implement a register machine emulator, then write an interpreter for scheme in the simplified ASM including 2 choices of garbage collectors, and finally has the student write a simple compiler for scheme to his register machine implementation. From this one course they not only gain the higher level understanding of CS concepts, but understand the underlying performance issues AND have first hand experience with (and hopefuly now inuitive understanding of) universal computation and Lambda calculus.

      I can't see this kind of introduction being done with any other language. Scheme is perfect because of it's regular syntax and extremely simple core implementation. Maybe you could do it with purer Lambda calculus, but I think you'd spend too much time on scaffolding up anything useful, whereas scheme starts you off with just enough to be productive.

  5. For Language Enthusiasts by RAMMS+EIN · · Score: 4, Informative

    Scheme is a language that every programming language enthusiast should know. Being both simple and flexible, it's suitable for communicating and explaining all kinds of concepts. A lot of books and papers are about Scheme or use Scheme for examples or teaching (see Readscheme.org). Scheme also pioneered some of the concepts in modern programming languages (such as lexical scoping), as well as several uncommon features (such as hygienic macros and first-class continuations). There are many Scheme implementations, some tiny, some slow, some fast, some with extensive libraries, some which interface to other programming languages, etc. etc.

    --
    Please correct me if I got my facts wrong.
    1. Re:For Language Enthusiasts by TheRaven64 · · Score: 3, Informative
      Scheme is a language that every programming language enthusiast should know.

      No, it (or some other Lisp dialect) is a language that every programmer should know. Every programmer should know Lisp, Smalltalk, and either C or some dialect of assembly language (ideally both). As a bonus, they should also know Haskell and Prolog. Once you know these languages, it is trivial to pick up any other. I would also recommend Erlang; not because it's a particularly good example of anything, but just because it's a real joy to work with.

      --
      I am TheRaven on Soylent News
    2. Re:For Language Enthusiasts by brilinux · · Score: 2, Interesting

      While we are on this bit, I would recommend an ML, either SML or OCaml, perhaps even in place of Haskell (Haskell's syntax can be easily argued to be either better than or worse than ML's, and anything you can so in Haskell (including type-classes and lazyness) can be done in ML, so while I do use Haskell, I generally recommend one of the MLs as a well-typed, type-inferring functional language to know (OCaml if they are more systems/applications oriented, and SML if they are more theory oriented or just curious).

    3. Re:For Language Enthusiasts by ramunasg · · Score: 1

      In other words, every programmer should know main programming paradigmas - imperative, functional, logic, object orientated. And a handful of calculis like CSP (which erlang concurrency primitives are based upon) :)

    4. Re:For Language Enthusiasts by oohshiny · · Score: 1

      Being both simple and flexible, it's suitable for communicating and explaining all kinds of concepts.

      Scheme is an extremely cumbersome language for experienced computer scientists to communicate ideas: Scheme lacks many concepts (e.g., exceptions, threads, records, associative data structures) that are widely used for communicating ideas. That may be justifiable for a teaching language, but it makes Scheme too cumbersome for most other purposes.

      Scheme also pioneered some of the concepts in modern programming languages (such as lexical scoping),

      That statement mostly demonstrates how unfamiliar you are with the history of programming languages.

    5. Re:For Language Enthusiasts by masklinn · · Score: 1

      exceptions

      meh

      threads

      yeah right whatever

      records

      can be trivially replaced by lists

      associative data structures

      such as hashes?

      While these aren't into the RnRS themselves (they don't have many reasons to be there either, anyway), saying that Scheme somehow "lacks" these concepts mostly shows that you don't know the language at all.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    6. Re:For Language Enthusiasts by John+Nowak · · Score: 1

      R6RS has exceptions and records. It has continuations, and some implementations provide threads (this is not something that belongs in the standard). It has hash tables. Also, the GP stated he recommends PLT, which already has all of these.

    7. Re:For Language Enthusiasts by masklinn · · Score: 1

      And it sure looks like I should've read the R6RS status report before posting this, because all of these are either filed under "features to be added" or "Work in Progress" (with references to the related SRFIs)

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    8. Re:For Language Enthusiasts by TheRaven64 · · Score: 1
      In other words, every programmer should know main programming paradigmas - imperative, functional, logic, object orientated.

      Definitely, but learning the paradigm is not quite the same as having it re-inforced by learning a concrete example. And a lot of people these days seem to be being taught things like Java and C++, and told that they are Object Oriented (a quote from Alan Kay: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.")

      And a handful of calculis like CSP (which erlang concurrency primitives are based upon)

      Definitely CSP. Probably Lambda Calculus (I hated it, but it's quite useful), and possibly Pi Calculus.

      Bah! I haven't quite finished my PhD, and I'm already complaining about what they teach undergraduates these days...

      --
      I am TheRaven on Soylent News
    9. Re:For Language Enthusiasts by bidule · · Score: 1


      Here Scheme has the same failing as the C language. The C++ language does not define threads either. If you skim through the srfi, you'll find that most if not all of these issues are "standardized", but outside the language itself.

      --
      ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
    10. Re:For Language Enthusiasts by EchoNiner · · Score: 1

      I agree with most, but would add a nice solid OO programming language. These concepts are very important with the stage that we are in with software development. A good understanding of something like Java (I chose this over C++ only because of its more strict OO nature, although something like Ruby might be a better example) helps understand the benefits that OO can provide in terms of code re-use and sharing in terms of interfaces and object heirarchies towards building code that is built from properly tested and secure codebases.

    11. Re:For Language Enthusiasts by Abcd1234 · · Score: 1

      I agree with most, but would add a nice solid OO programming language

      So, did you miss him mentioning Smalltalk, or have you just never heard of it? Please *please* tell me you just missed it...

    12. Re:For Language Enthusiasts by Poeir · · Score: 2, Insightful

      I'm with you on the recommendation of learning Erlang, but not for the same reason you are. The vast majority of new systems are at least dual core today. Most people run at least two programs, often meaning that one program can run entirely on one core, and another program runs on another core. Intel recently announced quad-core CPUs, and the first prototypes have got into a few people's hands. It looks like as time goes on, instead of upping the clock speed, the number of cores will increase. Most programming languages in use today, make it hard to do concurrency (or at best, don't make it easy), but Erlang was designed as a concurrent language from the get-go. I am inclined to say that the next generation of effective languages will be similar to Erlang, in their ability to support concurrency, and that programmers who don't get used to writing in some form of concurrent languages will be left behind.

      --
      Sigs are like bumper stickers.
    13. Re:For Language Enthusiasts by feijai · · Score: 1
      There are many Scheme implementations, some tiny, some slow, some fast, some with extensive libraries, some which interface to other programming languages, etc. etc.

      IMHO, this is precisely why Scheme has failed to catch on in the Lisp community. There really isn't a standard: there are a series of standards and a whole lot of RFIs, and every Scheme system implements its own subset. It's amazingly frustrating building a portable Scheme program. Common Lisp has fewer, more stringent standards, and is much more compatable across implementations. A lack of standard socket libraries notwithstanding. :-( Compare this to Python or Ruby or Java or Perl, where there is not only a standard, but a benchmark program which every implementation must be bug-for-bug compatable with. That's when you start seeing real portability.

    14. Re:For Language Enthusiasts by RAMMS+EIN · · Score: 1

      ``IMHO, this is precisely why Scheme has failed to catch on in the Lisp community. There really isn't a standard: there are a series of standards and a whole lot of RFIs, and every Scheme system implements its own subset.''

      I'd say you get the general gist, but I can't really agree with your wording. There really is a standard. And yes, it is very minimal, but that's deliberate: the idea has been that something only gets standardized once everybody agrees on the way to do it, and implementations are left free to implement everything else the way they deem best. I think that's a perfectly reasonable principle, even if it does have the effect of fragmenting the community.

      ``Compare this to Python or Ruby or Java or Perl, where there is not only a standard, but a benchmark program which every implementation must be bug-for-bug compatable with. That's when you start seeing real portability.''

      Actually, no. Most of these languages don't _have_ a standard, only an implementation. Anything professing to be an implementation will try to be compatible (bug for bug) with that implementation, but I think experience shows that that goal is not always achieved. I would say that comparing, e.g., Ruby and Scheme is comparing apples and oranges, just like comparing Windows and "Linux" is. To get meaningful comparisons, you could do something like comparing Ruby and MzScheme, or Windows and Ubuntu.

      --
      Please correct me if I got my facts wrong.
    15. Re:For Language Enthusiasts by RAMMS+EIN · · Score: 1

      ``Scheme is an extremely cumbersome language for experienced computer scientists to communicate ideas: Scheme lacks many concepts (e.g., exceptions, threads, records, associative data structures) that are widely used for communicating ideas.''

      It depends on the level at which you want to communicate, I guess. The advantage Scheme has over many other languages it that it doesn't lock you into a particular way of doing things. For example, if you _want_ throw-catch style exceptions, you can easily implement them in Scheme, but if you want a more flexible Scheme, you can easily implement that, too. Contrast this with, e.g., Java, which has throw-catch style exceptions built into the language, but makes it a lot harder to implement a different way of exception handling (e.g. one with restarts, like Common Lisp has).

      ``That statement mostly demonstrates how unfamiliar you are with the history of programming languages.''

      So you're saying Scheme did not pioneer all the things I said it did. Could you enlighten me as to where I went wrong, and which languages did pioneer these things?

      --
      Please correct me if I got my facts wrong.
    16. Re:For Language Enthusiasts by oohshiny · · Score: 1

      So you're saying Scheme did not pioneer all the things I said it did. Could you enlighten me as to where I went wrong, and which languages did pioneer these things?

      Algol 60 had lexical scoping and predated Scheme by many years.

      It depends on the level at which you want to communicate, I guess. [...] For example, if you _want_ throw-catch style exceptions, you can easily implement them in Scheme, but if you want a more flexible Scheme, you can easily implement that, too.

      At issue is not what Scheme has, at issue is what it lacks. Many languages have call/cc or equivalent constructs. Scheme, however, lacks a standard vocabulary to talk effectively about many common constructs, and defining everything yourself doesn't solve that. Using Scheme to talk about computer science is like trying to talk about philosophy using a first year high-school French vocabulary.

      Also, there have been plenty of exception systems discussed in the literature; I'm not aware of any of them that were first described in Scheme. Usually, they are described in English and pseudo-code, and implemented in C or assembly.

    17. Re:For Language Enthusiasts by oohshiny · · Score: 1

      Here Scheme has the same failing as the C language.

      Yes, it does. What's your point?

    18. Re:For Language Enthusiasts by RAMMS+EIN · · Score: 1

      ``Algol 60 had lexical scoping and predated Scheme by many years.''

      Thanks for the correction. What about the other features I mentioned? Was I right about those?

      ``At issue is not what Scheme has, at issue is what it lacks.''

      That may be how you want to frame the discussion, but I won't go along with that. Many things that are ostensibly lacking from Scheme can be added, whereas things that are included can't be taken away. See my earlier comment about exceptions.

      ``Many languages have call/cc or equivalent constructs.''

      From the top of my head, I can name Scheme, Ruby, and SML/NJ. Which ones did I miss?

      ``Scheme, however, lacks a standard vocabulary to talk effectively about many common constructs, and defining everything yourself doesn't solve that.''

      It does, however, give you insight in how they are implemented, and how they could be implemented. That can be useful, too. This is what I meant when I said it depends on what level you want to talk about things.

      ``Using Scheme to talk about computer science is like trying to talk about philosophy using a first year high-school French vocabulary.''

      Which has disadvantages, but also advantages. For example, you can learn all of Scheme very quickly, meaning you can establish a common basis for discussion quickly. Once you have that, you can start talking about higher level concepts. The fun part is that you can usually take Scheme up to higher level concepts much quicker than with many larger languages. Look at SICP, for example: it teaches Scheme, functional programming, imperative programming, data structures, lazy evaluation, interpreters and compilers, and it all fits in one course.

      ``Also, there have been plenty of exception systems discussed in the literature; I'm not aware of any of them that were first described in Scheme. Usually, they are described in English and pseudo-code, and implemented in C or assembly.''

      Maybe it depends on the environment you're in. I learned a lot about programming, languages, and implementation from people who knew Scheme, so, naturally, we used Scheme for examples a lot. I know other people who use Java for examples a lot (or actually pseudo-Java; they usually leave out the type annotations).

      --
      Please correct me if I got my facts wrong.
    19. Re:For Language Enthusiasts by Clover_Kicker · · Score: 1

      Heh. Which of those will help you learn APL?

    20. Re:For Language Enthusiasts by pilkul · · Score: 1

      Once you know these languages, it is trivial to pick up any other.

      I call bullshit. How about SQL (navigational language) or Clik (parallel-programming oriented language)?

      Anyway, putting aside the fact that you neglected several paradigms, in the real world it takes much longer to master all the minor technicalities of a language than the basic idea of it. You're like that linguist who claimed to have learned Japanese after watching a single subtitled movie. Yeah, he understood it was a subject-object verb language and its set of phonemes, but that doesn't amount to much in practice.

    21. Re:For Language Enthusiasts by pilkul · · Score: 1

      Wait, forget about my mention of Clik, reading up on it I see Erlang is also a concurrent-based programming language.

    22. Re:For Language Enthusiasts by oohshiny · · Score: 1
      That may be how you want to frame the discussion, but I won't go along with that.

      We're discussing this claim:

      Scheme is a language that every programming language enthusiast should know. Being both simple and flexible, it's suitable for communicating and explaining all kinds of concepts.


      That's the claim I disagree with: you can be an educated computer scientists or language enthusiast these days and never bother with Scheme.

      Thanks for the correction. What about the other features I mentioned? Was I right about those?

      I'm not sure what you mean by "right". Scheme may have been the first to implement hygienic macros or call/cc (certainly not continuations), but those features just haven't turned out to be particularly influential. APL is probably a more influential and important language for "language enthusiasts" than Scheme.
    23. Re:For Language Enthusiasts by feijai · · Score: 1
      Compare this to Python or Ruby or Java or Perl, where there is not only a standard, but a benchmark program which every implementation must be bug-for-bug compatable with. That's when you start seeing real portability.

      Actually, no. Most of these languages don't _have_ a standard, only an implementation.

      Hmmm, both Python and Java have formal specifications easily found on the web. So your usage of "most" requires some... mathematical flexibility. But granted, I'm not sure if either Ruby of Perl have specs.

      I still think my main point hasn't been addressed: Scheme has failed to catch on because there's no hegemon. No formal spec that everyone must implement and is sufficient for most real programming tasks (no need for RFIs like -- holy cow -- hash tables). And no reference implementation that anyone and everone can recompile on their own system, spreading the goodness rapidly. Instead we're stuck with lots of independent, widely varying Scheme implementations, mutually incompatable on which crazy subset of crucial RFIs they implement, and some of which implement R5, some R4 or IEEE, some have the full numerical tower, some don't, some have full continuations, some don't, on and on.

    24. Re:For Language Enthusiasts by bidule · · Score: 1
      Scheme is an extremely cumbersome language for experienced computer scientists to communicate ideas: Scheme lacks many concepts[...]


      What you said there is meaningless. This is my point.

      You are reducing a language to its mere definition, without taking into account libraries. I could say "C/Java is an extremely cumbersome language" and it would be just as true (or wrong). I developped application in C++ for 10+ years, and in LISP-like for 5 years. I have concrete knowledge of these issues. Heck, I can fart through my hat too. <grin>

      So what is your silver-bullet language that is so easy to use?
      --
      ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
    25. Re:For Language Enthusiasts by renoX · · Score: 1

      > Every programmer should know Lisp, Smalltalk, and either C or some dialect of assembly language (ideally both)

      At school we learned Lisp (among other languages), I have never used it afterwards and frankly while I understand that a language with such simple syntax is very powerful, its current impopularity is probably because programmers prefer programming langage with human friendly syntax so it will probably remain a "mostly-dead" language forever so I'm not convinced about the usefulness of learning it.

      Also why only Smalltalk? Me I learned OO with Eiffel: Meyer's book is very good.

    26. Re:For Language Enthusiasts by Anonymous Coward · · Score: 0

      Well, in as far as SQL is a *declarative* language, I would think Prolog would help there. And I see you already found the Erlang-Clik connection.

      And while knowing these languages doesn't mean that there is *no* work in picking up a new one, it does put you far enough ahead that you can focus on those 'minor technicalities' of the language.

    27. Re:For Language Enthusiasts by killjoe · · Score: 1

      "Most programming languages in use today, make it hard to do concurrency (or at best, don't make it easy), but Erlang was designed as a concurrent language from the get-go."

      While concurrency is important in some applications by far the vast majority of all applications involve CRUD operations against a database. Erlang (and lots of the other "cool" languages) suck at that. I mean suck really bad not just suck a little.

      This is why languages like VB and PHP are so popular and Lisp, ML, Haskell, and erlang are super small nice products.

      If you are designing a language you want lots of people to use then start with a good database support library and a good GUI toolkit which makes it easy to work with databases (see Ruby and ROR).

      --
      evil is as evil does
    28. Re:For Language Enthusiasts by RAMMS+EIN · · Score: 1

      ``you can be an educated computer scientists or language enthusiast these days and never bother with Scheme.''

      Ah, yes. Certainly.

      ``I'm not sure what you mean by "right".''

      Just asking. Since you knew I was wrong about lexical scoping, I thought perhaps you would be able to educate me about the others as well.

      ``Scheme may have been the first to implement hygienic macros or call/cc (certainly not continuations), but those features just haven't turned out to be particularly influential.''

      True, but the point of mentioning those is that they are things that Scheme pioneered. Even if the conclusion of that work is "these features are useless", that makes Scheme relevant for language enthusiasts. In case of call/cc and hygienic macros, they are also at the heart of Scheme's ability to naturally express various programming paradigms; e.g. there are no looping or parallel execution constructs in Scheme, but you can implement them.

      --
      Please correct me if I got my facts wrong.
    29. Re:For Language Enthusiasts by oohshiny · · Score: 1

      True, but the point of mentioning those is that they are things that Scheme pioneered.

      I think it's misleading to say that "Scheme pioneered" either feature. The original hygienic macros paper used both Scheme and Pascal as example languages. And call/cc was merely a particular choice of syntax, but the concept of continuations existed in many environments.

      What Scheme "pioneered" was to use a small set of very powerful primitives as the basis for high-level language design. Unfortunately, that has turned out to be a complete failure: not only did it fail to catch on, R6RS is now a bigger standard than ISO Lisp, and arguably a worse design. If Scheme has any relevance at all today, it's as an example of how not to design a language.

    30. Re:For Language Enthusiasts by RAMMS+EIN · · Score: 1

      ``And call/cc was merely a particular choice of syntax, but the concept of continuations existed in many environments.''

      Do you have any examples of this?

      ``What Scheme "pioneered" was to use a small set of very powerful primitives as the basis for high-level language design. Unfortunately, that has turned out to be a complete failure:''

      It's still useful for reasoning about programs and program transformations, and could simplify language implementations. I'd much rather work on a compiler for a language with a small core than one with a large core, but perhaps that's just a matter of personal preference.

      --
      Please correct me if I got my facts wrong.
    31. Re:For Language Enthusiasts by TheNumberless · · Score: 3, Funny

      Be careful man. It's not wise to leave unbalanced parentheses in a Slashdot post in general, but in an article about Scheme, it's damn near suicidal!

    32. Re:For Language Enthusiasts by oohshiny · · Score: 1

      Do you have any examples of this?

      Coroutines, threads, and generators usually keep the environment and permit returning to the point of call. Actually, so does setjmp, which you can give unlimited extent with just a little bit of effort in most C implementations.

      It's still useful for reasoning about programs and program transformations,

      There are tools and languages for doing just that, and Scheme isn't it.

      and could simplify language implementations.

      There have been good Scheme compilers for 20 years; what successful languages (I don't mean AI micro languages) have been implemented on top of Scheme in that time? In contrast, look at the large number of languages that have been implemented on top of the JVM and even the CLR.

    33. Re:For Language Enthusiasts by oohshiny · · Score: 1

      I forgot to mention: call/cc actually was discovered in the context of Algol 60. See here: Peter J. Landin: A Correspondance between ALGOL 60 and Church's Lambda Notation, CACM Vol. 8, No 2 pp 89-101 & No 3 pp 158-165 (February & March 1965) 12.

    34. Re:For Language Enthusiasts by DragonWriter · · Score: 1
      While concurrency is important in some applications by far the vast majority of all applications involve CRUD operations against a database.


      I don't know that that's the vast majority of all applications, but its certainly a huge portion of the market. But then, lots of languages do that well.

      Erlang (and lots of the other "cool" languages) suck at that. I mean suck really bad not just suck a little.


      Considering Erlang's origin, that's not surprising; perhaps the most important role that languages like Erlang play outside of their own focussed domain is that the implementation of features in such specialized languages often inspires the implementation of similar features in more general languages.

      Switching back to Scheme and functional languages (its true of concurrency features, too, I think, though its more clear for functional features), you see a lot of that recently with functional features being added to newer interations of popular languages.
  6. Veni, Vidi, Parenthesi by FlyByPC · · Score: 1

    ..."I came, I saw, I programmed in LISP." This is interesting, but what I'd like to see is a dual-core-optimized dialect of QBasic that will handle obscenely large arrays without kvetching.

    --
    Paleotechnologist and connoisseur of pretty shiny things.
    1. Re:Veni, Vidi, Parenthesi by Anonymous Coward · · Score: 0

      Try "ceci n'est pas UNE sig". It's UNE signature (just like it was UNE pipe).

    2. Re:Veni, Vidi, Parenthesi by Sterling+Christensen · · Score: 1

      but what I'd like to see is a dual-core-optimized dialect of QBasic that will handle obscenely large arrays without kvetching.
      FreeBASIC. http://www.freebasic.net/ It's no more optimized for dual-core than C is, but it runs as fast as the equivalent C code compiled with -O0 (it doesn't optimize yet). Compiles to asm like C does (no bytecode, no VM) and usually beats other BASICs in benchmarks. It handles arrays as large as C can. And of all the modern BASICs it's the closest to QBasic, able to run many nontrivial (including graphical) QBasic programs unmodified. Here's an IDE for it if you're interested: http://fbide.freebasic.net/

    3. Re:Veni, Vidi, Parenthesi by Sterling+Christensen · · Score: 1

      Ooops, with
      's this time:

      but what I'd like to see is a dual-core-optimized dialect of QBasic that will handle obscenely large arrays without kvetching.
      FreeBASIC. http://www.freebasic.net/

      It's no more optimized for dual-core than C is, but it runs as fast as the equivalent C code compiled with -O0 (it doesn't optimize yet). Compiles to asm like C does (no bytecode, no VM) and usually beats other BASICs in benchmarks. It handles arrays as large as C can. And of all the modern BASICs it's the closest to QBasic, able to run many nontrivial (including graphical) QBasic programs unmodified.

      Here's an IDE for it if you're interested: http://fbide.freebasic.net/

    4. Re:Veni, Vidi, Parenthesi by FlyByPC · · Score: 1

      Merci bien. Ce n'est pas la première fois que je me trompe ainsi. (Les langues étrangères sont difficiles pour nous Américains, vous savez...)

      --
      Paleotechnologist and connoisseur of pretty shiny things.
    5. Re:Veni, Vidi, Parenthesi by FlyByPC · · Score: 1

      Thank you! You have just made an IT dinosaur very very happy!

      --
      Paleotechnologist and connoisseur of pretty shiny things.
    6. Re:Veni, Vidi, Parenthesi by cervo · · Score: 1

      Woah, Basic with pointers and dynamic memory allocation, now that is scarey!!!!!

  7. lightning000rod@hotmail.com by Anonymous Coward · · Score: 0

    lightning000rod@hotmail.com

  8. Re: cursion by mrogers · · Score: 1

    ((((((((comment this) below) jokes) programming) functional) all) place) please)

  9. New features? by RPoet · · Score: 5, Funny

    I've never heard about this language, but hopefully the new version will help it keep up with the latest innovations in programming languages, such as codeblocks and Web 2.0.

    Yours truly,
    Fictional stereotypical teenage Ruby fanatic.

    --
    "Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
  10. Scheme and Common Lisp... by mav[LAG] · · Score: 2, Informative

    are both tools of beauty that have taught me more about programming and problem-solving than all other languages combined. SICP and PAIP are both classics in this regard that everyone should rush out and get now.

    It's just such a pity that, since they're both standards which anyone can implement, lots of people do, and as a result, finding one you like and then getting it to talk to other languages and libraries can be a very frustrating experience. And languages like Python with one canonical implementation driven by a BDFL and with exceptional library support are just getting more Lisp-like, which can't be good news for for a renaissance in Lisp or Scheme. Pity really, since I really like 'em both...

    --
    --- Hot Shot City is particularly good.
    1. Re:Scheme and Common Lisp... by mitchskin · · Score: 1

      If anything, python is getting less lisp-like. Guido wants to get rid of lambda, map(), filter() and reduce() in Python 3000.

    2. Re:Scheme and Common Lisp... by masklinn · · Score: 1

      Nope, he had some desire to but finally decided against it.

      Lambdas stay in, and the worst that can happen to map, filter and reduce would be to be moved to a standard package instead of being in the global namespace (akin to imap and ifilter in the iterable module)

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    3. Re:Scheme and Common Lisp... by Anonymous Coward · · Score: 0

      I studied LISP as a freshman at MIT, when the class was taught by Sussman. Frankly, it was used to teach incredibly bad habits of un-debuggable handwaving with its "layers of abstraction" approach, and the common practice of handing off big chunks of core tasks as "clouds" with ill-defined behavior, incredible resource wastage, and unpredictable results.

      Writing a program in one line was considered the height of programming elegance, even if it was illegible and unintelligible to anyone else. Recursion and self-reference were goals of the course, rather than being properly considered as powerful but computationally expensive operations prone to infinite loops and bogging down anything powerful in unnecessary garbage collection.

      LISP failed commercially and developmentally for good reasons: garbage collection has remained a dangerous problem, and while much good programming was done in it, it remains intractable for portability and performance. (If you've ever tried porting EMACS to a new platform, you know exactly what I mean.)

      I admit that LISP and its variants are fundamental to much of modern computer science, but the handling of "humors" and "demons" was once fundamental to medicine. That doesn't mean we should go back to using it except for historical study.

    4. Re:Scheme and Common Lisp... by larry+bagina · · Score: 1

      *sniff* *sniff* smells like troll spirit...

      Tail recursion is no more expensive than iteration. Using scheme or lisp, it is much easier to mathematically prove your code correct. Infinite loop == shitty programmer.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

  11. What's with naming these days? by Anonymous Coward · · Score: 0

    I swear the people coming up with tech names these days are just trying to confuse everybody. I mean, come on... Scheme?? That's just as bad as calling the new Half-Life Engine "Source". A scheme is something which is used in programming, as is the source code. Why can't they call it something unrelated to technology so that people don't get confused by the scheme of a Scheme data set just like people got confused with the source for Source was stolen.

    1. Re:What's with naming these days? by RPoet · · Score: 1

      The name "Scheme" was picked in the 1970s, so I wouldn't say Scheme joins Source in "today's" bad naming practices.

      --
      "Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
    2. Re:What's with naming these days? by siride · · Score: 2, Informative

      From Wikipedia: "Scheme started as an attempt to understand Carl Hewitt's Actor model.[1] Scheme was originally called "Schemer", in the tradition of other Lisp-derived languages like Planner or Conniver. The current name resulted from the authors' use of the ITS operating system, which limited filenames to two components of at most six characters each. Currently, "Schemer" is commonly used to refer to a Scheme programmer."

    3. Re:What's with naming these days? by frank_adrian314159 · · Score: 1

      And the name itself has a very interesting history.

      In 1969, Terry Hewitt, at the MIT AI Lab, published a program called PLANNER, which used embedded high-level procedural knowledge to represent plans and used backtracking as a major source of control structuring. In the early seventies, McDermott and Sussman published CONNIVER, another program that used the concept of "continuations" to provide control flow. These systems comprised the proto-history of most logic programming languages, but were woefully innefficient. In the mid-seventies, Guy Steele (who was working with Sussman) constructed another system that embedded planning knowledge procedurally (including the retention of continuations), but could be implemented efficiently (thus the focus on proper tail-recursion, simplicity, etc.). Extending the various names given the previous system, he called this one "SCHEMER". The OS in use at the MIT lab at that time truncated filenames to 6 characters, so the user would type the command "SCHEME" (the "R" being elided by the file system) and the shortened name stuck.

      --
      That is all.
  12. rather perl by losec · · Score: 0

    I rather program in an modern language that has invented closures and anonymous functions, like perl.

    1. Re:rather perl by brilinux · · Score: 1

      (lambda (parent) (display (list parent 'is 'this 'a 'joke?)))

    2. Re:rather perl by losec · · Score: 0

      $a = sub { "yes"; }; print &$a;

  13. Tail Recursion by RAMMS+EIN · · Score: 5, Informative

    For those of you who don't know what "properly tail recursive" means, a quick explanation. Consider the following code:

    (define (f x) (x x))
    (f f)

    This defines a function, f, which takes one argument, x, which should be a function (yay, first-class functions!), and calls x upon itself. Then, it calls f on f.

    Of course, this will cause f to call f upon itself. Again. And again. Infinite recursion!

    Now, proper tail recursion means that if a function call returns in tail position (meaning it is the last thing the surrounding function does before it returns), the activation frame for the surrounding function is replaced by that of the function it calls. Contrast this with normal recursion, where a _new_ activation frame would be created for the called function.

    Tail recursion makes the example code above run in bounded memory...looping forever. :-)

    --
    Please correct me if I got my facts wrong.
    1. Re:Tail Recursion by Anonymous Coward · · Score: 0

      Y man, Y?

    2. Re:Tail Recursion by Watson+Ladd · · Score: 1

      Not bounded memory. It just has to run forever. If the system has an infinite amount of memory, that memory can be consumed by the recusion and that is propert tail recursion. Not that that would matter at all in reality.

      --
      Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
    3. Re:Tail Recursion by StonyUK · · Score: 1

      It's good because it won't crash by exhausting the runtime's stack space. Instead it will just loop forever.

    4. Re:Tail Recursion by RAMMS+EIN · · Score: 1

      I think you missed the joke. I'm sure the parent was referring to the Y combinator.

      --
      Please correct me if I got my facts wrong.
    5. Re:Tail Recursion by Anonymous Coward · · Score: 0

      You got your facts right.
      -The anonymous poster, who is quite aware that the GP's comment was not actually the Y-combinator, but could not resist.

    6. Re:Tail Recursion by leshert · · Score: 1

      I think that in this case, "proper tail recursion" is just an inexact and fuzzy way of saying "supports proper tail-call optimization" and "supports proper recursion".

      For example, C specifies "proper recursion" but most implementations do no tail-call optimization, and so they suffer from the performance characteristics you mention.

      Obviously, if the function itself consumes memory, then yes--even a language and implementation that performs tail-call optimization will consume infinite memory. But if a language and implementation do perform proper tail-call optimization, then calling an infinitely-recursive function that uses a tail call should not in-and-of-itself consume unbounded memory--that's what tail-call optimization is all about.

    7. Re:Tail Recursion by WilliamSChips · · Score: 1

      I think you mean: "Y I man, Y I?"

      --
      Please, for the good of Humanity, vote Obama.
  14. Re: cursion by RAMMS+EIN · · Score: 1

    (let loop ()
            (display "> ")
            (write (eval (read)))
            (newline)
            (loop))

    --
    Please correct me if I got my facts wrong.
  15. Another language developed for compilers by kanweg · · Score: 0


    Despite having written/co-authored 2 booklets on programming (AppleScript for Absolute Starters and Become an X-coder), I've never mastered programming and I keep an eye out for easy to learn language, allowing me to focus on the programming instead of on keeping straining my brain with the grammar side of it. One of the earliest languages I learned was Pascal, which wasn't that bad, but doesn't appear to be as popular as it used to be (TurboPascal and all). But Scheme looks like one of the many programming languages developed for parsers and compilers, instead of for the people. Programming languages should be easy to read for humans too.

    Recently I read about a programming language (Python?) where global variables and local variables had a different starting thingie ($ and, I forgot). Now things like that DO help to make sure you're not a writer of a collection of bugs.

    Bert
    Just the number of parentheses rules out Scheme for me

    1. Re:Another language developed for compilers by shobadobs · · Score: 1

      That's because you're an idiot. The parentheses are not a problem at all when reading code.

    2. Re:Another language developed for compilers by John+Nowak · · Score: 1

      , I've never mastered programming and I keep an eye out for easy to learn language, allowing me to focus on the programming instead of on keeping straining my brain with the grammar side of it.

      Just the number of parentheses rules out Scheme for me

      You're missing out then on the language with perhaps the easiest grammar in existence.

    3. Re:Another language developed for compilers by Anonymous Coward · · Score: 0

      Thank you for posting that comment. I've been meaning to pick up a reference on XCode, and I now know what I should avoid like the plague.

      Anyways, to say Scheme was developed 'for parsers and compilers' is a bit off the mark. Yes, the language syntax makes it very easy to parse, and yes, it's very easy to write little compilers using macros, but this is hardly the motivator for the language's development. The language actually very closely follows the lambda calculus, making it good for reasoning formally about programs written in the language. Anyways, as a practical matter, once you start using lisp, the syntax becomes a strength rather than a weakness.

      Also, I think you are thinking of Perl when you so eruditely comment on the use of 'different starting thingies' to distinguish variables. If this is the case, I think it is safe to say that you are among the first to accuse Perl's syntax of being conducive to writing bug-free code.

    4. Re:Another language developed for compilers by PostPhil · · Score: 1

      Despite starting out with the usual languages of my generation, such as Basic, Pascal, C, and C++, I eventually chose Python as the jack-of-all-trades for my programming for the reason you mentioned. It is human-friendly rather than focusing on saving clock cycles, and I wanted to be able to work from one language for almost everything (it has bindings for almost everything). It's kind of a strange coincidence that Scheme was Slashdotted today, as I was browsing websites for learning LISP or Scheme as well. Maybe it's just intuition, but my gut feeling is that the simplicity of LISP/Scheme will help me re-think programming, as they say. My end goal is to improve my Python programming, and perhaps use Bigloo Scheme to write compiled programs for the JVM, .NET, and C that I will use in coordination with Python.

      But I would be careful about being too quick to judge Scheme as a human-unfriendly language. There are lots of parentheses to type, but to me that doesn't hurt the readability because its uniformity maintains the same "flow" throughout the program. It's all just lists using parentheses. Normally, I would hate parentheses being a Python programmer, but at least Scheme doesn't require semicolons and tons of other types of brackets and dots and slashes, and so the elegance of parentheses-only makes up for the extra typing. From what I've seen so far, readability is more a matter of knowing the names of the procedure calls and keywords, so it has more to do with being unfamiliar with the language.

      By the way, you must be thinking of a different language than Python. Python doesn't require a $ as a prefix for anything at all. Global variables are either already global or you use the "global" keyword. Perl uses a $ in front of variables, but if you want to avoid "straining your brain with the grammar side" and use a simple and readable language, I sincerely hope you aren't thinking of Perl. Not that it's a bad language, but readability is a deliberate effort in Perl that isn't really encouraged by the syntax itself.

    5. Re:Another language developed for compilers by HiddenL · · Score: 2, Insightful

      Actually, Scheme/LISP was designed for "correctness" rather than for ease of compiler implementation. Take for instance something like

      x = y + 1;

      in C. That doesn't actually mean "x = y + 1" it means "x = y + 1 (mod 2^32)". Why is it done this way? Because it is a lot easier for a compiler designer to implement integers if they are always a fixed number of bits.

      On the other hand, Scheme does it the correct way, so that (set! x (+ y 1)) actually does what it looks like it does. This is one of the reasons C compilers took off in the 70s while lisp compilers stagnated. I suggest you read the paper "Worse is Better"

      ---
      Your resident MIT student

      PS. Don't take this as support for Scheme. I hate Scheme.

    6. Re:Another language developed for compilers by WilliamSChips · · Score: 1

      You're thinking of Ruby and it's nothing, @, and @@ for local, class and global vars, but I don't remember which is which because I don't actually program in Ruby and I read this from the c2 wiki.

      --
      Please, for the good of Humanity, vote Obama.
    7. Re:Another language developed for compilers by DannyO152 · · Score: 1

      Look for DrScheme or Lisp in a Box, whether you want the Scheme or Common LISP flavor, respectively. DrScheme has Scheme tutorials among its help resources. I think Practical Common LISP (APress) is a good book for introducing LISP among those in print, and fortunately, I picked up Paul Graham's LISP books at the time they were current (and I was then looking to understand AutoLISP [once I was young]). Graham's texts are not for beginners, but once you get a sense of how Common LISP works, they provide perspectives that Practical Common LISP don't. I've been seeing used and out of print classic texts on LISP from the 90s showing up at the computing book store in Hollywood (CA); though once I see them, I grab them. "The Little Schemer" is also very illuminating about recursive thinking and bottom up problem solving; though it is written from a Scheme perspective, the approaches apply to LISP.

      I also use KDevelop (multi-language) and the parentheses seem manageable. My experience suggest that getting lost in the parentheses is a sign to refactor.

    8. Re:Another language developed for compilers by Geoffreyerffoeg · · Score: 1
      But Scheme looks like one of the many programming languages developed for parsers and compilers, instead of for the people. Programming languages should be easy to read for humans too.

      "Easy to read" and "Easy to write" are two entirely different things. Take the example of getting the 2nd element of the list 1, 3, 5, 7.

      AppleScript is going to be something like "the second element of {1, 3, 5, 7}." Easy enough to read.
      11:18: syntax error: Expected class name but found identifier. (-2741)
      Let's try "the second item of {1, 3, 5, 7}".
      3

      So how was I supposed to know that the English word "item" works but the equally English word "element" doesn't?

      Now let's try Lisp/Scheme: "(cadr (list 1 3 5 7))". I know that works, because that's practically the only way to write it. (The other ways are fully equivalent.)
      3

      To someone who's never seen Lisp or Scheme, "cadr" makes no sense. But there are only a few keywords like that in Scheme. And as far as syntax, the (almost) only special characters in Scheme are the two parentheses, and the space of course. You won't have to worry if a list uses braces or curly brackets. If a pointer-to-a-pointer-to-a-class uses *ptr->fn() or (*ptr)->fn() or (*ptr->fn)(). Whether a "char const *" has its address or value constant. Why "display dialog 'foo'" "button returned of the result" works but "button returned of display dialog 'foo'" doesn't. Whether it's "display dialog" or "show dialog", "button returned" or "button pressed". If you're allowed to use another indentation style without messing up your code.

      It's very difficult in Scheme to write something you don't mean. That's why the parentheses are there. And if you indent approximately every parenthesis (except for, say, small math), it isn't that bad. Take this, for example. Let a, b, and c be numbers, and plus-or-minus be either + or -, depending on which result you want.
      (define (quadratic-result a b c plus-or-minus)
          (/ (plus-or-minus
                (- b)
                (sqrt (- (* b b) (4 a c)))
            )
            (* 2 a)
          )
      )
      Admittedly a little harder to read, but there's no way I messed up precedence, thanks to the prefix (Polish) notation and parentheses. Now if I had glomped the whole thing together as (/ (+ (- b) (sqrt (- (* b b) (4 a c))))), then yes, the parentheses would be a problem. But not properly indented like they are.
    9. Re:Another language developed for compilers by chthon · · Score: 1

      But Scheme looks like one of the many programming languages developed for parsers and compilers, instead of for the people. Programming languages should be easy to read for humans too.

      Like COBOL, you mean ?

    10. Re:Another language developed for compilers by Anonymous Coward · · Score: 0

      Actually, I think you meant:

      (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))))

      because Scheme (usually) won't let you define a procedure named '4.

      I also think the above layout is preferable to the indented version (it makes more sense to this scheme programmer). YMMV if you're the kind of programmer who'd break this expression into several statements in an Algol-family language.

    11. Re:Another language developed for compilers by Geoffreyerffoeg · · Score: 1

      Ah, sorry. Yes, I missed the operator there.

      And yes, for someone who knows Scheme, your layout makes more sense. But the GP in particular said the parentheses turned him off - I'm just demonstrating that as far as the control structures, the parentheses in a Lisp-family language are essentially the same as other braces and the conventional indentation in an Algol-family language. It's just the GP's familiarity with indentation that makes him prefer that to parentheses.

  16. That's a bald assertion. by Estanislao+Mart�nez · · Score: 1

    [...] reducing the number of primitives by creating a can of worms like CALL-CC is not good design.

    Please argue for this point.

    1. Re:That's a bald assertion. by oohshiny · · Score: 0

      Please argue for this point.

      Well, from the point of view of design, the lack of standard threading and exception facilities in Scheme seems to have resulted in a lot of incompatibilities between different Scheme code. That's one of the reasons I stopped using Scheme.

      The real question is: how did the Scheme designers ever demonstrate that their design decisions (call/cc or otherwise) were good ones?

  17. Description of differences here by billstewart · · Score: 2, Informative
    If you RTFA and follow a few obvious links, you get to The R6RS Status Report which gives a relatively concise overview of the changes from R5 to R6.


    Since Scheme wasn't the one of the versions of LISP that I learned back in the dark ages, I couldn't really follow the subtleties of which changes are really significant, but it looks like it would make sense if you were following Scheme.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  18. Library System by StupidEngineer · · Score: 1

    Yay, they standardized on a library system!

  19. Lisp syntax has great cognitive advantages by Estanislao+Mart�nez · · Score: 5, Insightful

    But Scheme looks like one of the many programming languages developed for parsers and compilers, instead of for the people. Programming languages should be easy to read for humans too.

    Lisp syntax certainly does not attempt to look like the combination of English text and mathematical formulas that most languages shoot for, but this in fact has many advantages. The idea of making a language look like that doesn't change the fact that the language will work in a way very different from English or mathematical notation; your previous knowledge of those things will not necessarily help you reason about your code, and at worst, may confuse newcomers by tempting them to apply analogies that don't hold. And to achieve that "look" for your language, you always end up giving it a really complex and inflexible syntax, whose users are not going to have any systematic knowledge of. (Do you know many people who can give you a BNF grammar for Java, or tell you the exact precedence rules for it?)

    Lisp makes no pretence at looking like English or mathematics. You're certainly expected to understand the syntax rules of the language more than in "friendlier" ones, but these rules are far, far simpler, and you can actually reason them through. Remember, Scheme oooks regularly include a section that shows you how to write a Scheme interpreter in one page of Scheme code; basic knowledge of how Scheme itself works is considered to be elementary Scheme knowledge.

    That is, what I'm saying is that compared to other languages, Lisp dialects demand that you understand the language itself far more, but this is a good thing, which will make you program way better. Why? Because you're going to be able to reason about the execution of your program far better than your average Java programmer.

    Plus, you can do macros.

    1. Re:Lisp syntax has great cognitive advantages by Anonymous Coward · · Score: 0

      exact precedence rules for [java]

      How exactly is List/Scheme any better in this sense?

      basic knowledge of how Scheme itself works is considered to be elementary Scheme knowledge

      A real eyeopener, isn't it. But not in the way you meant. Practically nobody gives a damn how compiler works. With a good reason.

      Scheme is incomprehensible to humans - it has no syntax whatsover besides parentheses. People are extremely bad at reading them. For me some even slightly more complicated lisp statement is impossible to parse as I cannot remember where every parenthesis is matched. Not even with an editor capable of showing them, not to mention books.

      And don't get me started on the reverse-reverse Polish notation ...

    2. Re:Lisp syntax has great cognitive advantages by DragonWriter · · Score: 1
      Scheme is incomprehensible to humans - it has no syntax whatsover besides parentheses.
      Its clearly not incomprehensible to humans, otherwise humans couldn't read or write code in it, and they clearly do both. Further, being almost syntax-free doesn't mean being unreadable: REBOL doesn't have much more in the way of fixed syntax than Scheme (being a somewhat less pure functional language with a loosely similar idiom), but is (generally) very readable (though, of course, you can make it unreadable, since you roll your own obscure and unreadable syntax just as easily as creating clear and expressive constructs.)
  20. Um. by Estanislao+Mart�nez · · Score: 2, Informative

    ;;;
    ;;; Macro to increment a variable by one.
    ;;;
    ;;; Usage:
    ;;;
    ;;; (define a 5)
    ;;; (inc! a)     ; a is now 6
    ;;;
    (define-syntax inc!
      (syntax-rules ()
        ((inc! x)
         (set! x (+ x 1)))))

    Not that idiomatic Scheme code will do this very often.  Langauges like Java or C use "++a" most often for loop indexes.  Looping in Scheme is typically driven off data structures.

  21. ML vs Haskell by jefu · · Score: 1

    SML or OCaml are great lenguages, but if you're going to learn a functional language, Haskell is a great place to start. First because the syntax is very clean (I never quite liked the "let rec" bit) but also because in both SML and OCaml it is too easy to slip back into imperative styles. Haskell makes that substantially more difficult, which means to use it well you really, really have to get the whole functional programming idea.

  22. So what's new? by sco08y · · Score: 1

    I notice that r6rs has a lot more editors than r5rs, and another author...

    Which isn't surprising. r6rs is twice as long as r5rs which had the entire table of contents on the first page.

    I'm glad to see that a lot of the slib stuff is being merged into scheme, and that they're making a lot of progress on number types. r6rs is laying out a lot more information on ADTs, IO and Unicode support.

    The explanation of continuations is still as clear as mud. How are they so easy in Python and so hard in Scheme?

    1. Re:So what's new? by alienmole · · Score: 1

      What do you mean about continuations being so easy in Python, considering that Python doesn't have first-class continuations? Are you talking about Stackless Python?

      Keep in mind that R6RS is a language definition aimed largely at Scheme implementors. It's useful for users, too, but it's not supposed to be a tutorial, particularly not for concepts like continuations, or hygienic macros.

  23. Re:Isn't it amazing... QWZX by masklinn · · Score: 0, Flamebait

    There is a reason that C and C++ derived languages dominate the industry.

    Because managers are stupid fucks and don't know any better?

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  24. complicated syntax is readable and error-resistant by r00t · · Score: 0, Flamebait

    Humans deal best with languages in which form matches function and there is a bit of redundancy.

    Sure, you can go too far. Perhaps perl and C++ do.

    In something like C or Pascal, a block is normally rather distinct from an expression. Humans rely on visual pattern recognition to read code. Scheme delibrately avoids anything that would be useful for pattern recognition.

    With Scheme, it all becomes a blur. Every line is like every other line.

  25. Re:Isn't it amazing... QWZX by Anonymous Coward · · Score: 0

    Yeah, because every peon is clamoring for Scheme and Smalltalk, while the ev1l managers are forcing C and Java on them. ::rolls eyes::

  26. R6RS is not Scheme yet by oohshiny · · Score: 1

    Well, I'm glad that we seem to agree that it is necessary (though not sufficient) for a language to have exceptions and threads in order to be a good language for communicating concepts in computer science. Right now, Scheme is defined by R5RS, and R5RS lacks those. That's one of the many reasons for Scheme's failure to catch on (contrary to popular opinion, syntax is probably not one of them; after all, XML and Perl succeeded despite their syntax).

    Whether R6RS will be a good language for communicating concepts in computer science remains to be seen. From what I see in the draft standard, R6RS is a very different language from R5RS. I think R6RS ceases to be a good language for its original purpose (teaching), and it still remains a poor language for grown-up use (although for different reasons than before).

    It's a real shame that the bungling of the Scheme and CommonLisp designers have effectively killed the entire Lisp family of languages. The world could really benefit from a nicely designed Lisp.

    1. Re:R6RS is not Scheme yet by John+Nowak · · Score: 1

      I wasn't agreeing with you. As for what "Scheme is defined by", it doesn't matter: You program with implementations, not standards. R6RS is also not much different from R5RS at all -- It is mostly library additions. This should make teaching easier, as one can show off hash tables to students without first requiring they import some module or use some specific implementation. Furthermore, Scheme, as it is now, can be a very good "grown-up" language (whatever that means). See Chicken Scheme and its large number of bindings for networking, graphics, sound, et cetera.

    2. Re:R6RS is not Scheme yet by msuzio · · Score: 1

      I can't say I agree with that. Where in the world would you get that idea? Threads and exceptions are nice, but so many programs of considerable value can be written without ever touching those concepts that they are not fundamentals in any way.

      I don't at all get your point(s). Especially knocking data structure support in Scheme -- that would have to be the fundamental structure of the entire language, isn't it? Lists and atoms are, well, kind of it, and everything else can be built from those (and often already are, via slib for example).

    3. Re:R6RS is not Scheme yet by oohshiny · · Score: 2, Insightful

      As for what "Scheme is defined by", it doesn't matter: You program with implementations, not standards

      We're not discussing whether Scheme is a good language to program in (that's a separate debate), we're discussing whether it's a good language to communicate ideas in, as the GP claimed.

      Furthermore, Scheme, as it is now, can be a very good "grown-up" language (whatever that means).

      It means that programmers and computer scientists find other languages more useful for communicating their ideas and getting their work done.

      See Chicken Scheme and its large number of bindings for networking, graphics, sound, et cetera.

      Implementations of Scheme with excellent bindings have existed for two decades, yet one new language after another has overtaken Scheme: Perl, Python, Tcl, Java, Ruby, C#, PHP, the list goes on. Evidently, people really don't want to use Scheme.

    4. Re:R6RS is not Scheme yet by oohshiny · · Score: 1

      Lists and atoms are, well, kind of it, and everything else can be built from those (and often already are, via slib for example).

      Brainfuck is an even more minimal language than Scheme but that doesn't make it a better language. Good language design isn't about choosing a minimal set of primitives, it's about choosing a good set of primitives.

    5. Re:R6RS is not Scheme yet by John+Nowak · · Score: 1

      The number of people using Scheme is small, but it is there. Yes, PHP is more popular; It is also total garbage.

      I guess the problem is that I don't understand how "a good language to communicate ideas in" is different than "a good teaching language" or "a language that's good to program in". :-)

      Ah well... can I buy you coffee?

    6. Re:R6RS is not Scheme yet by oohshiny · · Score: 1

      I guess the problem is that I don't understand how "a good language to communicate ideas in" is different than "a good teaching language" or "a language that's good to program in". :-)

      Yes, I think that's at the heart of the issue. What's the difference? It's like textbook French (learning) vs. colloquial French (programming) vs. academic French (communicating ideas): they are all different languages for different purposes. Scheme is a good teaching language (though not the only one), which is why it's being used to this day for that purpose, but...

      The number of people using Scheme is small, but it is there. Yes, PHP is more popular; It is also total garbage.

      Scheme has had lots of practical advantages over other languages: lots of people know it because they have to learn it in college and there have been excellent implementations for nearly two decades. The fact that programmers and computer scientists at all levels consistently choose other languages despite that built-in advantage is pretty good evidence that Scheme is not well-suited for those other purposes.

      Unfortunately, it doesn't look to me like R6RS makes Scheme any better as a real-world language, but I think it may make it worse as a teaching language.

      Ah well... can I buy you coffee?

      Thanks for the thought.

  27. Why should I learn Scheme? by Bluesman · · Score: 4, Interesting

    This always comes up, but if you're at all interested in programming languages, here's why you should learn Scheme.

    A few years ago I was doing a project that involved parsing the intermediate code that GCC generated while compiling a C program. Doing a bit of research I found out that one of GCC's intermediate stages was a language called RTL (register transfer language). To my surprise, RTL looked something like this:

    (set (reg:0) (mem:blah blah))

    But wait, I thought -- that looks like Lisp. Come to find out RTL was based on lisp s-expressions.

    It was then I realized what the Big Deal with Lisp was - it has no syntax at all, and programs written in this parenthetical form are trivially converted into a parse tree. In fact, if you've ever written a simple interpreter or compiler, odds are good you'd use a list-like structure to store the parsed code.

    The reason Lisp and Scheme are so "powerful" is that you, as a programmer, have direct access to the program's parse tree at all times. (You can even alter the parse tree at compile time with macros, which is really modifying the compiler to suit your program.)

    But really, the best way to learn why Scheme or Lisp are so great is to implement them. Writing a Scheme to assembly compiler will give you an incredibly deep understanding as to how compilers and programming languages in general work.

    If you were to try to write a compiler for any other language, you'd probably spend most of your time on the lexer and parser. With Lisp or Scheme, the program, as written, is already almost fully parsed for you. Once you understand that, you'll realize why it's so cool.

    --
    If moderation could change anything, it would be illegal.
    1. Re:Why should I learn Scheme? by Abcd1234 · · Score: 1

      You can even alter the parse tree at compile time with macros, which is really modifying the compiler to suit your program.

      I find it very odd you made this a parenthetical. This is, AFAICT, *the* reason why Lispers bring up the equation between code and data. Basically, it lets you create domain-specific languages.

      Of course, what they *don't* point out is that this is a great way to create unmaintainable code with a very high learning curve. In order to maintain your app, now developers need to a) learn Lisp, and then b) learn your nifty derivative Lisp-a-like that you created using macros.

      Moreover, actually understanding and maintaining Lisp macros is, IMHO, a bear... they're not exactly the clearest constructs in the world.

      Once you understand that, you'll realize why it's so cool.

      Yes, very cool. Practical, no. "Cool", as in, "wow, that's pretty cool, but now I need to get some actual work done", definitely.

    2. Re:Why should I learn Scheme? by RAMMS+EIN · · Score: 1

      ``Of course, what they *don't* point out is that this is a great way to create unmaintainable code with a very high learning curve.''

      Yes. But the same is true of any abstraction. It helps if you do it the right way, it hurts if you do it the wrong way. Also, a common use of macros is to hide ugliness. For example, suppose you have developed some system that you need to feed thunks (procedures that take no arguments). You would have to write things like

      (frobnicate (lambda () (your code here)))
      (munge (lambda () (put) (your) (code) (here)))

      Having to repeat the (lambda () ...) over and over quickly gets old. So, instead, you create a macro that will expand

      (munge (put) (your) (code) (here))

      into

      (do-munge (lambda () (put) (your) (code) (here)))

      Voila! Your API just became more elegant!

      ``In order to maintain your app, now developers need to a) learn Lisp, and then b) learn your nifty derivative Lisp-a-like that you created using macros.''

      You should be comparing that to writing domain-specific languages from scratch. In that case, you _will_ have to learn a new language from scratch, and it probably doesn't have all the nice facilities of Lisp. By contrast, a DSL built on top of Lisp is still Lisp, which means there is a large part which you could already know, and you have access to all of Lisp, making your DSL every bit as powerful.

      --
      Please correct me if I got my facts wrong.
    3. Re:Why should I learn Scheme? by Bluesman · · Score: 1

      I find it very odd you made this a parenthetical.

      That's because you're assuming I'm trying argue that Lisp is better than all other languages because it has macros. I'm not. I'm simply saying that learning Lisp or Scheme by implementing them is a great way to learn about how programming languages, in general, work.

      You don't have to master macros to do that. You can write a simple s-expression to assembly compiler in less than 100 lines of scheme or lisp, never touching a macro. It would be much more difficult to do in any other language, because you'd get bogged down in the details of lexical analysis, which is no fun.

      --
      If moderation could change anything, it would be illegal.
    4. Re:Why should I learn Scheme? by Curly · · Score: 1
      The reason Lisp and Scheme are so "powerful" is that you, as a programmer, have direct access to the program's parse tree at all times. (You can even alter the parse tree at compile time with macros, which is really modifying the compiler to suit your program.)


      Not in Scheme you don't. Functions may be first-class, but they're opaque.

      Lisp and Scheme are only superficially similar. They share a (virtual lack of) syntax, but the split was early and definitive.

      The Big Deal with Scheme isn't its syntax---I find its everything-looks-like-a-list syntax annoying at best. And when compared with built-in facilities in other languages (e.g., hashes, regular expressions, string-interpolation, object-orientation), Scheme's built-in list parser is a toy. An occasionally handy time-saver, but not a Big Deal.

      The Big Deal with Scheme is first-class functions, tail-call optimization, call/cc, and all the Alice in Wonderland playground those things imply. By all means write a compiler for Scheme, but the time savings gained during parsing will be nothing, nada, zero, compared with the fun that implementing the actual language features brings.

      The Big Deal with Scheme is a that a language with so little (this is one of its features) can contain so much power and all-out fun.

  28. Learn Scheme by borgboy · · Score: 3, Informative

    I am sure there are a numer of ways to learn Scheme if you are interested. Here's one: follow the CS-61A course podcast of Brian Harvey's class at Berkeley.

    --
    meh.
    1. Re:Learn Scheme by Breakfast+Pants · · Score: 4, Informative

      Here's another(video lectures). Make sure to read the book as well. Both the book and the videos are free.

      --

      --

      WHO ATE MY BREAKFAST PANTS?
  29. Re:an oxymoron by RAMMS+EIN · · Score: 4, Interesting

    ``"properly tail recursive" is an oxymoron. Tail recursion is not proper. Decent programmers use loop constructs for looping.''

    That's highly debatable. I would agree that when you want to express the concept of a loop, it's best to use a looping construct, but other people would disagree. Also, tail calls are more general than loops; for example, they also work for mutually recursive functions.

    Which is more elegant?

    int gcd(int a, int b) {
        return (b == 0) ? a : gcd(b, a % b);
    }

    or

    int gcd(int a, int b) {
        int t;
        while (b != 0) {
            t = b;
            b = a % b;
            a = t;
        }
        return a;
    }

    ``Your problem is that Scheme can't do that.''

    That depends on what you mean by "Scheme can't do that". It's entirely possible to implement looping constructs in Scheme, and several people have done so. Scheme can't do looping in the same sense that C can't compute factorials.

    ``When all you have is a hammer, everything looks like a nail.''

    Except that, in Scheme, you can make your own tools on a much more fundamental level than in many other languages. Thanks to tail call optimization, you can _implement_ looping constructs, even though the language doesn't provide them.

    ``Needless recursion makes your code more convoluted and less readable.''

    I think the example I gave earlier illustrates that, sometimes, recursion leads to less convoluted, more readable programs. The right tool for the job, ey? In a language that isn't properly tail recursive, the recursive gcd would be a bad idea because the recursion would eat memory, but in Scheme it's no problem.

    ``It's amazing how people can claim a deficiency as some kind of advantage. You just keep smoking...''

    I'm not claiming a deficiency as an advantage. I'm claiming tail call optimization is a nice features to have. There is no deficiency here.

    You could argue that the lack of looping constructs is a deficiency. However, the lack of looping constructs (1) is not at all implied by the language being properly tail recursive, (2) is easily remedied, and (3) actually has been remedied in many implementations.

    And no, I don't smoke, though I do live in the Netherlands.

    --
    Please correct me if I got my facts wrong.
  30. Re:an oxymoron by countach · · Score: 1

    The problem with looping as opposed to recursive, is that recursive is functional programming and thus it is easier to prove the code correct. Looping has side-effects, and thus it is more prone to bugs. None of this makes sense to the VB raised programmer for which for every nail, VB is the hammer.

    Besides which Scheme has looping, it is just that it is implemented using the more primitive construct of tail recursion. Scheme gives you the power to invent your own control constructs.

  31. False dichotomy by Estanislao+Mart�nez · · Score: 1

    Those are good things to have some standard way of doing, yes, but they don't actually support the point you made: "reducing the number of primitives by creating a can of worms like CALL-CC is not good design."

    Why so? Because you can have it both ways: you can have call/cc as a language primitive, plus standard threading and exception facilities implementable with macros on top of call/cc. (And if you look at R5RS, you'll see that this approach is already taken for large parts of the language; the standard demonstrates how to define, for example, let, in terms of lambda and macros.)

    1. Re:False dichotomy by Anonymous Coward · · Score: 0

      I agree with you in general, but it is worth noting that

      - call/cc tends to be slow
      - call/cc tends to make people's heads hurt.

    2. Re:False dichotomy by Estanislao+Mart�nez · · Score: 1

      Note that I didn't say that stanrdard threading and exception handling facilities should be implemented in terms of call/cc. I said they should be implementable in terms of it. The let forms are implementable in terms of lambda, but they typically aren't implemented in terms of it. Threading and exception handling can be implementation primitives without being language primitives.

      The point is that such a design makes the language simpler.

  32. Isn't Scheme already a standard? by quanticle · · Score: 1

    I thought the Scheme language had been standardized by the IEEE a while back. Is this a revision of the standard, then?

    --
    We all know what to do, but we don't know how to get re-elected once we have done it
    1. Re:Isn't Scheme already a standard? by Estanislao+Mart�nez · · Score: 1

      I don't know the details of the story of the IEEE Scheme standards, but the RnRS document series are the traditional community definition of the language. One of these (R3RS?) served as the basis for the submitted and approved IEEE standard, but there's been a few RnRS documents since, and those are the ones that people in the scheme community actually care about.

  33. Re:an oxymoron by kravlor · · Score: 1

    Clearly the second example is more elegant, given the assumption of a C-like language, as it is an in-place algorithm. As you point out, given the constraints of C the recursive implementation eats memory and thus doesn't scale well to GCD(large number); the tail-recursive feature of Scheme allows for an arguably simpler-to-visualize implementation.

    Having written my own Scheme interpreter for a programming languages course back in my University days, I must admit I prefer C; however, each language has its strengths -- and that's why you use it!

  34. VBS vs VBA by Latent+Heat · · Score: 1
    Is scripting the same as application extension?

    VBS is a Microsoft Windows Scripting Host (WSH) language, while VBA is the Microsoft extension language for writing macros in Word or Excel. While they have similar syntax, the application is a little different. A scripting language is a glue language for building new applications that use objects, system resource, GUI widgets, and even entire applications such as MS Word or a Web browser as a piece-part of the application. An extension language is something for writing a plug-in or extension of a particular application like Word or IE.

    Is this a distinction without a difference? I suppose you could extend Word if you had a way to script Word, but there is a difference in emphasis between a stand-alone script that does something with Word and a plug-in that is run from Word.

    I suppose for Scheme as a plug-in language, it is probably like AutoCad and Emacs using Lisp dialects as extension languages. But is this the same as using Scheme/Guile for scripting? Or if Python is widely available on Linux for scripting, does this mean Gimp exposes a scriptable interface to Python (Word exposes a scriptable interface to Python under Windows, and many COM/ActiveX objects are usable from Python, but largely because of Windows-specific libraries that can be called from Python)? Does this also mean that Gimp can call back into Python to implement plug-ins in Python? So in this sense, I get the feeling that Scheme/Guile is limited to plug-ins and not much used for scripting?

  35. language that isn't properly tail recursive??? by r00t · · Score: 1

    What in Hell is that supposed to mean?

    C is as properly tail recursive as Scheme. I just compiled your code with gcc 4.1 on PowerPC. I see no recursion in the assembly output. Some of you Scheme people seem to have no clue about modern compilers.

    In case you somehow have a clue about assembly:

    gcd:
                    cmpwi 0,4,0
                    bne 0,.L7
                    blr .p2align 4,,15 .L9:
                    mr 4,0 .L7:
                    divw 0,3,4
                    mullw 0,0,4
                    subf 0,0,3
                    mr 3,4
                    cmpwi 7,0,0
                    bne 7,.L9
                    mr 3,4
                    blr

    1. Re:language that isn't properly tail recursive??? by ldd23 · · Score: 1

      In most languages, it falls on a compiler to provide for tail-recursion optimization and not all compilers will do that in all their optimization modes. As I understand Scheme, a Scheme system is not compliant with the language specification *unless* it optimizes tail-recursion.

    2. Re:language that isn't properly tail recursive??? by RAMMS+EIN · · Score: 1

      That's just gcc on PowerPC. On x86, it doesn't do tail call optimization. Also, the C standard doesn't mandate tall call optimization, but the Scheme report does. So, really, C isn't properly tail recursive, and Scheme is.

      --
      Please correct me if I got my facts wrong.
    3. Re:language that isn't properly tail recursive??? by Anonymous Coward · · Score: 0
      That's just gcc on PowerPC. On x86, it doesn't do tail call optimization.

      Yes, it does. At least for the supplied code with gcc-4.1.2, -O2.
    4. Re:language that isn't properly tail recursive??? by DragonWriter · · Score: 2, Insightful

      Most modern C compilers will do tail-call optimization. However, it is not a requirement of the language (an implementation that fails to do so will still be "C"), and so implementation-agnostic portable code shouldn't count on it, and the language itself provides strong support for programming constructs that make sense when you can't count on tail-call optimization.

      Functional programming languages that require tail-call optimization as part of their definition, tend not to support such constructs as well (or, when they do, to do so as syntactic sugar for a recursive implementation), but rather use recursive functional idioms to address the same situation. These may be less natural appearing if you've spent lots of time working with imperative languages where those approaches aren't the natural solution (and where likely you've had "don't use recursion unnecessarily" beaten into your head), but recursive expressions of algorithms tend to be both compact and clear.

  36. no it doesn't by r00t · · Score: 2, Interesting

    It's time you looked at the output from a modern C compiler. I compiled the example for PowerPC using gcc 4.1 and got the assembly shown below. There is no recursion. There isn't even any memory access; everything is done in registers. (FYI, "blr" is the PowerPC instruction for "return")

    gcd:
                    cmpwi 0,4,0
                    bne 0,.L7
                    blr .p2align 4,,15 .L9:
                    mr 4,0 .L7:
                    divw 0,3,4
                    mullw 0,0,4
                    subf 0,0,3
                    mr 3,4
                    cmpwi 7,0,0
                    bne 7,.L9
                    mr 3,4
                    blr

  37. Please use fewer 'junk' characters. by jelle · · Score: 1

    ... for the same reasons why we must learn history (to know not to make the same mistakes ourselves)...

    scheme code unevitably turns into an unreadable pile of ((((((((((()((() junk

    Actually, I could not give an accurate representation of scheme, because slashdot kept saying 'Lameness filter encountered. Post aborted! Reason: Please use fewer 'junk' characters.'

    And don't get me started in functional programming languages.

    --
    --- Hindsight is 20/20, but walking backwards is not the answer.
    1. Re:Please use fewer 'junk' characters. by RAMMS+EIN · · Score: 1

      ``scheme code unevitably turns into an unreadable pile of ((((((((((()((() junk''

      Not for nothing is LISP short for Lots of Irritating Superfluous Parentheses. :-) But then again, C (just to name one language) has lots of irritating superfluous parentheses, commas, semicolons, type annotations, and curly braces.

      What few people seem to realize is that the parentheses in Lisp code are actually a very natural representation of trees. This is no accident; Lisp was originally invented as a notation for parse trees, so that program transformations could be discussed and studied. Try that with C code, and you will see that it's a whole lot more difficult to map C to syntax trees than Lisp.

      Indeed, program transformations are an integral part of Lisp programming. People use macros to add new constructs to the language all the time. Lisp macros are very powerful and yet very simple, making this feasible.

      ``Actually, I could not give an accurate representation of scheme, because slashdot kept saying 'Lameness filter encountered. Post aborted! Reason: Please use fewer 'junk' characters.'''

      Perhaps you should have tried to include some symbols (usually known as identifiers in other languages) as well. Contrary to what you seem to think, Lisp code tends to be only sparsely populated by junk characters, unlike many languages that people find more readable. Try:

      (defun print-vector (vec)
              (loop for x accross vec do (princ x)))

      vs.

      void print_vector(int *vec, int len) {
              int i;
              for(i = 0; i < len; i++) {
                      printf("%d", vec[i]);
              }
      }

      Which has more junk characters?

      ``And don't get me started in functional programming languages.''

      I think I'd better not, indeed.

      --
      Please correct me if I got my facts wrong.
    2. Re:Please use fewer 'junk' characters. by Abcd1234 · · Score: 1

      Of course, one might point out that the loop macro is a *terrible* (or, perhaps, carefully chosen) example, given that it's one of the least functional features in Lisp (and, amusingly, is one of the most expressive).

    3. Re:Please use fewer 'junk' characters. by RAMMS+EIN · · Score: 1

      ``Of course, one might point out that the loop macro is a *terrible* (or, perhaps, carefully chosen) example, given that it's one of the least functional features in Lisp (and, amusingly, is one of the most expressive).''

      That would be beside the point, because we were talking about junk characters, i.e. syntax, not semantics.

      Also, note that, contrary to popular belief, Lisp is _not_ a functional language; it just happens to be that many Lisp programs are written in the functional paradigm (perhaps because it is the most elegant).

      Finally, it's perfectly possible to implement loop in a purely functional way if a language is properly tail recursive (which Common Lisp is not, although most implementations are).

      --
      Please correct me if I got my facts wrong.
    4. Re:Please use fewer 'junk' characters. by Abcd1234 · · Score: 1

      Finally, it's perfectly possible to implement loop in a purely functional way if a language is properly tail recursive (which Common Lisp is not, although most implementations are).

      Of course it is. But then you lose the clarity of syntax, which was the original point being discussed.

      So, you get clarity of syntax, but you need to write complex macros to achieve it (which, I might add, are hideous to understand and maintain).

    5. Re:Please use fewer 'junk' characters. by swdunlop · · Score: 1

      Here's a nickle -- buy yourself a real text editor with parenthesis highlighting.

    6. Re:Please use fewer 'junk' characters. by RAMMS+EIN · · Score: 1
      ``
      Finally, it's perfectly possible to implement loop in a purely functional way if a language is properly tail recursive (which Common Lisp is not, although most implementations are).


      Of course it is. But then you lose the clarity of syntax, which was the original point being discussed.''

      Actually, I said that to demonstrate that there is nothing inherently imperative about loops; they can be implemented efficiently on top of referentially transparent constructs.

      As for syntax...I find Common Lisp's loop facility to have one of the clearest and most powerful ways to describe all sorts of loops...and it can be implemented as a macro that expands into a tail recursive algorithm. I don't see the problem.

      ``So, you get clarity of syntax, but you need to write complex macros to achieve it (which, I might add, are hideous to understand and maintain).''

      No more hideous to understand and maintain then the equivalent code when implemented in the compiler, I'm sure. And if, for whatever reason, you want to implement loops in the compiler rather than in a library, you can always do that. I can't see how being _able_ to implement them in a library could be construed as a Bad Thing.
      --
      Please correct me if I got my facts wrong.
    7. Re:Please use fewer 'junk' characters. by jelle · · Score: 1

      A crutch does not unbreak a bone.

      --
      --- Hindsight is 20/20, but walking backwards is not the answer.
    8. Re:Please use fewer 'junk' characters. by jelle · · Score: 1

      "What few people seem to realize is that the parentheses in Lisp code are actually a very natural representation of trees. This is no accident; Lisp was originally invented as a notation for parse trees, so that program transformations could be discussed and studied. Try that with C code, and you will see that it's a whole lot more difficult to map C to syntax trees than Lisp."

      That may lead to think that speed synthesis would be the ideal application to show off the power of scheme... Yet festival does use scheme and it is horrible.

      --
      --- Hindsight is 20/20, but walking backwards is not the answer.
  38. Re:an oxymoron by Anonymous Coward · · Score: 0
    Decent programmers use loop constructs for looping.
    Sure, but they also use recursive constructs for recursion. And with "proper" tail recursion, you have some guaranteed performance, so you know you don't have to bend over backwards to make it into a loop.

    Your problem is that Scheme can't do that. Sure, you can emulate a loop construct, but this is pure stupidity.
    Are you looking for looping in the generated machine code or looping in the source code? If you "emulate" looping constructs with macros and tail recursion in Scheme, you get both. (and I'm not going to bother finding out, but I assume the standard requires such macros predefined)
  39. Great Scheme bumper sticker by c0d3h4x0r · · Score: 1

    My other car is a cdr.

    --
    Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
  40. Continuation Crash Course by RAMMS+EIN · · Score: 2, Interesting

    Short and simple explanation of continuations:

    A continuation is "the part of the program that hasn't been executed yet". If your code is

    (foo)
    (bar)
    (baz)

    and you've just executed (foo), the continuation is (bar) (baz).

    In Scheme, continuations are first-class values, which means they can be stored in variables, returned from functions, passed as arguments, etc.

    There is a single way to create continuations, namely through the call-with-current-continuation form (often abbreviated call/cc). You pass call/cc a function that takes one argument, and call/cc will call that function, passing it the current continuation as an argument. E.g., in

    (foo)
    (call/cc fun)
    (bar)
    (baz)

    fun will be called with a continuation representing (foo) (bar) as an argument.

    The continuation itself is a function that takes one argument, and calling that function will have the effect of returning from the call/cc that created it, with the value you pass to the continuation as a return value. E.g.

    (display (call/cc (lambda (cont) (cont 42))))

    will display 42, because that's the value you passed to the continuation.

    Now, things get _really_ interesting once you don't immediately invoke the continuation, but you store it in a variable for later use. E.g.

    (define cont #f)
    (call/cc (lambda (c) (set! cont c)))
    (foo)

    Now, cont is set to the continuation that, when invoked, will have the effect or returning from the call/cc form (i.e. (foo) will be the next form executed). The great power of Scheme's continuations is that this cont can be invoked any number of times, just like a normal function.

    What is it actually useful for? Well, it's definitely not something you use all the time. But you could use it to implement threads, for example:

    (define *threads* '())

    (define (schedule-thread thread)
            (set! *threads* (append *threads* (list thread))))

    (define (run-next-thread)
            (if (not (null? *threads*))
                        (let ((thread (car *threads*))
                                  (set! *threads* (cdr *threads*))
                                  (thread))))

    (define (make-thread thunk)
            (schedule-thread thunk)
            (yield))

    (define (yield)
            (call-with-current-continuation
                    (lambda (cont)
                            (schedule-thread (lambda () (cont #t)))
                            (run-next-thread))))

    Now, you can create a new thread by saying

    (make-thread (lambda ()
            ; your thread's code goes here
            ))

    and a thread can give up its timeslice by calling (yield).

    No time to check the code now, I have to go to a meeting.

    --
    Please correct me if I got my facts wrong.
  41. Re:complicated syntax is readable and error-resist by Anonymous+Brave+Guy · · Score: 1

    Sorry, I don't usually post these, but how on earth is the parent post "flamebait"?

    It seemed to be making the perfectly reasonable point that just because LISP dialects are very uniform, this doesn't necessarily make them easier for humans to use.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  42. Felix Winkelmann's opinion by Azul · · Score: 1

    Felix, the author of Chicken Scheme, a fairly popular Scheme implementation, doesn't seem very fond of R6RS.

    I just thought my fellow Slashdot readers could want to hear his informed opinion. :-)

    1. Re:Felix Winkelmann's opinion by namekuseijin · · Score: 1

      he sounds like an ass.

      --
      I don't feel like it...
  43. Java Libraries? by TheRealFoxFire · · Score: 1

    Furthermore, one can access other libraries than those written in Scheme, using bindings to C/C++ libraries, or in the case of SISC, access to any and all Java libraries. This, combined with Scheme's flexible language constructs, has led to amazingly powerful programming frameworks such as SISCweb (think Web 3.0 if you want a buzzword).

  44. What kind of a function is "I"? by HiThere · · Score: 1

    The rule in lisps is that the first argument of a list is the executable, and the rest of the list is the parameters given to the executable. The normal mapping is from verbs to executables.

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.
  45. Re:an oxymoron by RAMMS+EIN · · Score: 1

    ``The problem with looping as opposed to recursive, is that recursive is functional programming and thus it is easier to prove the code correct. Looping has side-effects, and thus it is more prone to bugs.''

    Actually, that's not completely true. Since looping can be expressed as tail recursion and the other way around, they are both equally referentially transparent. Of course, this is more obvious in case of tail recursion, which is why you would probably transform loops to tail recursion before making proofs.

    --
    Please correct me if I got my facts wrong.
  46. Re:an oxymoron by RAMMS+EIN · · Score: 1

    ``Clearly the second example is more elegant, given the assumption of a C-like language, as it is an in-place algorithm.''

    Alright, I should probably have made it clear that I was just using C syntax to make it easier for people to understand the code (assuming that more people read C than Scheme). I also obviously wasn't clear about the meaning of elegant; that was meant to refer to the source code, not whatever the compiler cooks up as a result.

    Under these definitions, I think there's no denying that the first snippet is more elegant (although I've met people who claim that recursion is evil, always. I wonder how they write functions...)

    Your statement that the second snippet is more elegant, because it runs in bounded space, is a nice example of how the lack of proper tail recursion can force you to go out of your way to come up with good (or even working) algorithms. A compiler _could_ transform the first snippet into efficient code, and thus probably _should_. If you think cluttering up your code to help the compiler generate efficient code, think about manually unrolling loops, pipelining your code, inlining functions, constant folding, etc. Yes, they make it possible to have simple compilers generate efficient code, but they don't increase the elegance or legibility of your programs. Tail call optimization is just like that, in my opinion.

    --
    Please correct me if I got my facts wrong.
  47. Re:Scheme--now with bloat! by DragonWriter · · Score: 1
    We need a nice, clean, simple, powerful teaching language to replace C and Java.
    How about Oz?
  48. Why would you ever want to write that? by Estanislao+Mart�nez · · Score: 1

    Um, when did you last ever write that in a real program?

    Anyway:

    ;;;
    ;;; The unless macro is not R5RS Scheme, but most implementations
    ;;; include it, so you might not need to define it.  (The R6RS draft
    ;;; does include it.)  Just in case, here's an R5RS macro system definition
    ;;;
    (define-syntax unless
      (syntax-rules ()
        ((unless cond expr . rest)
         (if (not cond)
             (begin expr . rest)))))

    ;;;
    ;;; Call proc for each number between lo and hi, inclusive.
    ;;;
    (define (iterate-over-range lo hi proc)
      (unless (> lo hi)
        (proc lo)
        (iterate-over-range (+ lo 1) hi proc)))

    ;;;
    ;;; this one is straightforward
    ;;;
    (define (print-line x)
      (display x)
      (newline))

    ;;;
    ;;; print each number from 1 to 10, in separate lines
    ;;;
    (iterate-over-range 1 10 print-line)

  49. [...] if you are stepping through a list and transforming each member in a common way, an iterative description seems more clear (particularly a for-each kind of approach.)

    Ever heard of map?

    1. Re:Eh? by DragonWriter · · Score: 1

      Okay, yeah, even in that case the typical functional articulation is probably more clear.