Well done, the site does look good. I'm not a fan of tables either, but I do try and get my html to validate. You have a few errors on the page - you might want to check out the following:
http://validator.w3.org/
About done with high school, eh? Boy, I feel old now :)
Given that the browser with 80% to 90% can't handle XHTML properly, and after long drawn out debates in usenet over the best doctype, I've personally settled on HTML 4.01 Strict. Once I discovered how IE actually handles XHTML, that sealed the deal.
Thanks - I had forgotten about the repl operator that pg mentioned in that thread. I'll have to try that out.
I love the quote from Ron Garret about the benefits of a REPL.
"Debugging a program running on a $100M piece of hardware
that is 100 million miles away is an interesting experience. Having a
read-eval-print loop running on the spacecraft proved invaluable in
finding and fixing the problem."
You're probably right about not waiting. I probably won't have time until after this weekend anyway, so we'll see if we get an Arc3 gift :)
Good to hear about MzS 360, that's the package that installed on my local Ubuntu 7.10 system.
I just installed it on an older Ubuntu server that I'll be using for production and got 352, so that should be pretty safe given that's what pg is using.
Haskell chooses this order because partial application and pointfree style are really common.
let squareall = map (^2)
squareall [1,2,3] ===> [1,4,9]
squareall [3,4,5] ===> [9,16,25]
let f = foldr1 (+) . squareall . filter even
f [1,2,3,4,5] ===> 20
But since partial application is not a default behavior in Arc ([map square] and [map _ square] are not that different from one another) the order of the fn and list aren't as important.
Rule of thumb might be: put the fastest changing piece last, but this syntax thing might be a stronger heuristic.
It's premature to say what type of performance Arc will eventually provide, but I'm not aware of anything in the language that would preclude good performance - it will depend on the implementation of the production compiler.
Is there a particular aspect of Arc that causes you concern with respect to performance? Also, do you have a particular application in mind, or is you concern a hypothetical one?
Thanks. It's not the language itself that I'm concerned about. Rather, I'm wondering how much interest there will ever be in developing a truly fast Arc.
Consider Python, for example. It's been around for a while and is widely used. Yet it's still pretty slow. Fast enough for building websites, sure, but it's nothing like C or Fortran for serious numerical work.
Python's supporters will tell you that its slowness doesn't matter, because you can re-write the time-consuming bits of your code in C. I can imagine that that works well for web programming where latency accounts for much of the execution time anyway and one might only occasionally have a really chunky calculation to do. But in my experience doing Monte Carlo simulations, solving large systems of non-linear equations and that type of thing, a large part of the code is fairly critical for execution speed, so re-writing in C would mean doing a large part of the project in C. If I wanted to do that, I'd just write in C to begin with.
I've experimented with Ruby and Python lately, with the hard-care numerics to be written in C, as I alluded to above. I've not actually done huge amounts of programming recently, although in the past I did so in a proprietary language resembling C and in Fortran. Recently I have a look at CL (which accounts for my interest in Arc) and at OCaml, though I've not yet used either extensively.
It also looks like its OO using Clos and it looks very un-arcish presenting the very hard problem with in CS - naming things - or in this case renaming things shorter.
Alist of filename patterns vs corresponding coding systems.
Each element looks like (REGEXP . CODING-SYSTEM).
A file whose name matches REGEXP is decoded by CODING-SYSTEM on reading.
The settings in this alist take priority over `coding:' tags
in the file (see the function `set-auto-coding')
and the contents of `file-coding-system-alist'.
No, I'm simply selecting text with the mouse in an Arc buffer and trying to paste with the middle-button in a non-emacs window such as this text area.
I've narrowed the problem down to the filename extension. Here's the test:
brian@airstream:~/temp$ cat > temp.arc
hello, world
<ctrl>-d
emacs temp.arc
Then select some text with the mouse and try and paste in a non-emacs window using the middle button. I can do this with everything but files ending in .arc !
brian@airstream:~/temp$ emacs --version
GNU Emacs 23.0.60.2
I just killed my .emacs file as a test and I get the same results, so you should be able to duplicate that if you're on Linux.
With no .emacs file, I see the following message when loading temp.arc:
File mode specification error: (error "Buffer format not recognized")
I expect that's related. Maybe we can get pg to use another extension like .arclisp :)
So it's not sufficient to add the new arc.el, you have to remove the existing association also? I would think that once a match is found in the auto-mode-alist, it wouldn't consider the other entries.
BTW I started a thread on gnu.emacs.help, but if the above fixes it, it's moot.
