I'm curious, why do you think this is inapplicable to Arc? In a prototype-based class system, you could use these hidden classes to model namespaces for a purely functional space, and then function dispatch would be really fast.

Further, it opens up interesting possibilities for modules.

It's possible though that you could implement arc hash tables using js objects, since they, too, are just glorified hash tables in a different way.

Basically calls on the arc side are compiled thusly:

  (fn (bar)
    (foo bar))
   =>
  (lambda (bar)
    (ar-funcall1 __foo bar)) ; the 1 here means there is one argument

  (let ((callsite1 (ar-funcaller1)))
    (lambda (bar)
      (callsite1 __foo bar)))

  ; scheme!!
  (define (ar-funcaller1)
    (lambda (f arg1)
      ;dispatch based on f, argument types, etc.
      ...))

By using a callsite lambda object, we can keep track of previous multimethod etc. lookups.

And then we can make the compiler emit code especially for (foo 'bar) forms:

  (fn (foo) foo!bar)
    =>
  (let ((callsite1 (ar-quotecaller1 'bar)))
    (lambda (foo)
      (callsite1 foo)))

  (define (always-false . rest) #f)
  (define (ar-quotecaller1 quoted)
    ; use only a single variable to prevent
    ; race conditions in multi-threaded code
    ; (might not always work if using true
    ; threads instead of green ones though)
    (let ((checker-and-dispatch (cons always-false #f)))
      (lambda (ob)
        ; copy to our own local variable to
        ; prevent race conditions (assuming
        ; the read is atomic anyway)
        (let* ((my-checker-and-dispatch checker-and-dispatch)
               (checker (car my-checker-and-dispatch)))
          (if (not (checker ob))
              (begin
                (set! my-checker-and-dispatch
                      (patch-quotecaller1 ob quoted))
                (set! checker-and-dispatch my-checker-and-dispatch)))
          ((cdr my-checker-and-dispatch) ob quoted)))))
  (define (patch-quotecaller1 ob quoted)
    (cond
      ((table-with-hidden-class? ob) ; implemented however you will
        (let* ((hidden-class (hidden-class-get ob))
               (hidden-class-index (hidden-class-index-lookup hidden-class quoted)))
          (cons
            ; checker
            (lambda (ob _)
              (and (table-with-hidden-class? ob)
                   (eq? hidden-class (hidden-class-get ob))))
            ; dispatcher
            (lambda (ob _)
              (hidden-class-ref ob hidden-class-index)))))
      (... ;other conditions: functions, methods, other data types...
        )))

One thing I've noticed about CPAN and the Perl community is that they take module and library creation to the level of an autistic activity. Even the most banal and trivial of things has multiple implementations in CPAN of varying quality.

  (load 'foobar)

Likewise, Scsh shows that a lisp-1 could encroach on territory typically occupied by Ruby and Perl.

Significant indentation is great. Wait, come back! Don't put this in the language yet! I'm not done! Significant indentation is great for languages like Python, in which code blocks are different from expressions and never go smack in the middle of a function call.

No, it's common sense. Call me old-fashioned, but I prefer being able to tell if code is syntactically correct just by looking at it instead of having to perform a hex dump. Never mind being able to reconstruct indentation from syntax when it eventually gets mangled in email/forum postings/code restructuring.

> Have you ever coded in Python?

Yes I have. Apart from the above caveat it's quite a nice language, although I find Ruby more elegant.

> Need I remind you what happened when Larry Wall tried to combine all the great ideas from a bunch of different languages into one?

> No, it's common sense. Call me old-fashioned, but I prefer being able to tell if code is syntactically correct just by looking at it instead of having to perform a hex dump.

Are you trying to say that source code (either with or without meaningful indentation) requires a hex dump to read? Or are you talking about object code (in which case I am pretty sure indentations is entirely irrelevant).

>> Need I remind you what happened when Larry Wall tried to combine all the great ideas from a bunch of different languages into one?

> Yes, it got hugely popular. You got a problem with that?

I don't know about you but Perl's conglomerate syntax, combined with all that extra magic, makes Perl pretty unmanageable in my opinion after a couple hundred lines of code.

From pg's essay Arc at 3 Weeks:

I am aware of some rather horrid languages that forced the use of meaningful indentation, but that doesn't make indentation evil in and of itself.

I hope that arc keeps a canonical and authoritative implementation. One of the big problems keeping many people from deploying Lisp applications is the uncertainty and difficulty in choosing a particular implementation. It can also end up fragmenting developer time and you will inevitably end up with incompatible but extremely similar arc implementations everywhere.

Abother example is call/cc. This is a very interesting beast, only existing in Scheme. But it is hard to implement efficiently.

The last example I can think of is 'nil. Using nil as false and the empty list is very interesting in this regard : you can implement nil as the NULL pointer, which is also 0, the false boolean. Less manipulations to do on the bare metal. Distinguishing between #f and '(), on the contrary, implies making more tests at the lower levels.

R. Kent Dybvig. "Three Implementation Models for Scheme". PhD. Thesis. http://www.cs.indiana.edu/~dyb/papers/3imp.pdf

Then continue at ReadScheme at "Compiler Technology/Implementation Techniques and Optimization" to see further developments (Look especially for Clinger's papers).

Note however that much of the theoretical analyses of call/cc make a basic assumption of a "spaghetti stack", which would mean that partially unwound stacks would be saved implicitly as long as any continuation exists which refers to that stack, and all stacks themselves are subject to garbage collection. Most machines don't actually have a spaghetti stack and can't make a spaghetti stack anyway ^^. That said a spaghetti stack could be implemented as a simple list, with push == cons and pop = cdr.

Alternatively store the local variables on a garbage-collected heap, and include a reference to the local variables with the continuation/return address (you'll probably need to save the pointer-to-local-variables anyway, since the target function is likely to use that pointer for its own locals). Again, no additional overhead over plain function calls, except perhaps to restructure the return address and the pointer-to-local-variables.

I read the Clinger "Implementation Strategies for Continuations" paper and they found call/cc about 10 times slower than function calls on the tak/ctak tests. I tried those tests on PLT Scheme and the overhead I saw is even worse: .7 seconds with function calls vs 51.8 seconds with continuations on (tak 24 16 8).

Components of call/cc: (1) put return address as argument somewhere (2) put return address somewhere (3) jump to function.

And yeah, call/cc is probably always going to be a bear. But man is it cool. :)

I suppose this goes against what a few of us (including me) were saying above -- that the language and the speed are really separate issues. Or maybe it's more coherent to say that language standards (as opposed to "languages" generally understood) can have a profound effect on speed. If they don't give implementors a lot of choice, they can box people into certain corners.