I think "repeat" is one of the less-frequently used arc functions. The "Huffman encoding" philosophy would be to keep the name longer in order to improve clarity- Shortening this name, IMHO, would just be a small step towards the "line noise" problem that perl has.
Thanks for the patch link. I had to regenerate it, and I'm wondering if I missed something. The patch as I added it (attached below) does get rid of the warning from date, but all the other errors still seem to be there and Firefox still displays only a blank page, as do Links and W3M. Errors on the arc tty are very similar:
reference to undefined identifier: _ranked-stories*
As to Lynx I found this forum doesn't support it either, and I'm not sure I blame it. I tried logging in from my Zaurus, only to get an error about invalid content length. I'm annoyed with Lynx more than the forum. It's been around long enough.
+(def uname nil
+ (let val (tostring (system "uname"))
+ (subseq val 0 (- (len val) 1))))
+
(def date ((o time (seconds)))
- (let val (tostring (system (string "date -u -r " time " \"+%Y-%m-%d\"")))
+ (let val (tostring (system
+ (string
+ "date -u "
+ (if
+ (is (uname) "Linux")
+ ;; Linux wants -d and an interval
+ (string "-d \"" (- 1 (since time))
" seconds\"")
+ ;; BSD wants -r and epoch seconds
+ (string "-r " time))
+ " \"+%Y-%m-%d\"")))
(cut val 0 (- (len val) 1))))
(def count (test x)
Edit: Fixed the newlines. >_> I hope I didn't screw up the patch.
Edit #2: Or not. What kind of forum is this? One that likes proper <p> tags... Okay, I could live with that but honestly, what kind of coding-discussion forum does that make it?
ordinary text you want to put in a single
paragraph
(indent two spaces
(to get code)
(that is readable)
(make sure
(to put empty lines before and after)))
No good reason I know of... The "is" roughly maps to comparators in other Lisps that are designed for "near constant time" comparisons, which is possible for symbols and numbers.
Strings may have gotten grandfathered into this behavior because they were thought of as similar to symbols.
Another possibility is that a Lisp string implementations could, in theory, use pre-computed hashes for comparisons, which WOULD allow near-constant comparisons, while slowing other operations.
Arc is desinged as a practical language, and as such it is not built on any pure primitives. PG had, at one point, taken such an approach, but abandoned it because of poor performance.
It calls many mzscheme functions to run, most of them not primitive. Primitives, as far as they exist, are defined in ac.scm. They are not simple, however- Instead, the emphasis is on keeping the language implementation simple and reasonably efficient.
> Arc is desinged as a practical language, and as such it is not built on any pure primitives. PG had, at one point, taken such an approach, but abandoned it because of poor performance.
Personally I'm retaking this approach, and doing some trickery on the scheme side to improve performance. So far what I've been doing is only slightly slower than Anarki (within sampling variation, although the average times are slightly higher).
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 hard to imagine a more sub-optimal implementation than the one we currently have (short of porting it to Ruby 1.8's interpreter, lolslow!) :)
Hmm... the reason I was thinking it wouldn't help is because arc objects are just glorified hash tables. This means that if we implemented an arc2js program it would use a hash table on the js end...
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.
Looking briefly on the web, it looks like it might be possible to fully implement hashtables with js objects. In that case, arc objects could benefit from hidden classes. OTOH, regular hash tables may underperform due to innappropriate attempts to force hidden classes on them.
; scheme!!
(define (ar-funcaller1)
(lambda (f arg1)
;dispatch based on f, argument types, etc.
...))
(I've actually already implemented this experimentally, but the performance didn't increase much - however this was before I implemented serious multimethods (which I haven't actually completed implementing anyway...), so I suppose I can bring this back to amortize multimethod lookup.)
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:
callsite1 can then cache lookups on hidden classes.
(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...
)))
I was actually going to implement this, but then I thought that using arc hash tables as objects - and in particular the (tb 'key) form - wasn't actually that common enough (at least in Arc) to justify optimizing for it. Hmm.
also noticed that the difference isn't that large as the racing car seemed to suggest. Chrome's javascript has about the same performance as Opera's right now. We'll see how it develops.
Hah. someome made ruby run on v8 and made a small benchmark of it. Interesting:
My preferred solution, FYI, would be some kind of crazy thread-specific namespacing. Then, by having large numbers of light-weight threads, name collisions wouldn't be an issue anymore. (Yes, you could say this is similar to a module system, if you want to be pedantic :-)
Arc is, arguably, simpler than either Scheme or Common Lisp. The only reason for learning these other languages first, in my opinion, would be because of the greater availability of teaching materials.
In fact, if there's any language I'd recommend learning before arc it would be Haskell. You'll enjoy arc much more if you have a good understanding of functional programming first. The best way to do that (although a pretty hardcore way) is to learn Haskell.
