Does it really matter where the code runs? Or does it just matter who writes it?
In most examples, HTML runs on client machines which may be roughly comparable to your example, but who cares, because the code (whether measured in lines or nodes) the author had to write to generate that HTML was presumably superior in some way compared to writing HTML manually. (Otherwise why not just code straight HTML, all the time?)
In your example, even though the server side code consisted of 0 lines/nodes, the code written by you consisted on an entire HTML page. So did you really save any time or effort in writing the HTML? Maybe, that's why we compare the code trees. But even in that case, the HTML itself will count toward the code tree.
Perhaps this means that HTML templates (not HTML generated by server-side scripts) used in other entries should also be included in their code tree count, if they had to be coded manually by the author. But even if this is the case, it doesn't just add a constant factor to all entries (I believe the arc entry did not require any HTML to be written by the author), and thus is still useful information, although perhaps the two should be considered separately.
P.S. Really liked your submission. I just don't think it counts as 0 lines of code.
Thanks, eds. I think that's a pretty fair judgment, and you're right that it wouldn't be a constant factor because different people are generating different amounts of HTML in the end. My example only has one page, and though it should be valid HTML4, I do include some CSS and div's that other folks wouldn't need. Admittedly, to keep theirs valid, they'd also need a lot more html, head, title, and body tags than me if they're making multiple pages.
The thing that strikes me as being kind of a funny metric here with code length is that if the author wrote the HTML and imported it into their code, you have to count it, but if some other author wrote the HTML and you import it, then you don't have to count it. Seems kind of weird to me, seeing as this opens the door to somebody else saying:
Alright, maybe gjohnson's code count includes all that silly HTML and CSS, but my program uses his HTML template file (which isn't much of a template in this case, of course, being kind of the whole shebang), and has a parse tree of length 1.
Here it is:
<!--#include virtual="gjohnsons_magic.html" -->
Tada! I mean, heck. It's true that pg didn't write the HTML in his arc challenge submission code, but wait a minute! He did write it in his function library when he was defining the language. So being the author of the original HTML, does he have to include it after all?
You're right. That was one of the main objection against this challenge, from what I read on many forums. Well, the really convincing test is to use Arc for real. I wrote a small webapp with Arc and I never wrote such an app so fast. Quite amazing for a language I didn't know.
Point taken. This stuff about parse trees and who-wrote-what is after all just an academic argument. You're absolutely right that it's what we can write and how he enables us to write it in the end that makes this stuff all so interesting.
Anyway, keep going everyone. Those submissions are rockin' on. I've got my mind wrapped around a pretty perversely heinous challenge response that I may get to in the next couple of days. Keep your eyes peeled!
P.S. Did anybody notice that those class="page" attributes are unnecessary in my HTML/CSS code above? Just checking. Looks like I forgot to remove'em before posting.
The idea that Lisp's greatest strength - the inherent ability to transform to whatever you want it to be - is also its greatest weakness, since it prevents you from easily communicating with others what you intend - that is, one man's 'let (CL, Scheme) is another man's 'with (Arc).
Having ported my groovy Cells project to Arc, I can confirm that it was a pain where I sit that "only the names have been changed" in several cases. :) But pg gets the benefit of the doubt from me because I own both his books and he kinda rocks when it comes to Lisp.
The funny thing is that perhaps unbeknownst to you all the Lisp establishment is ragging on pg for Arc being too much like Lisp, you (and I a little) are hosed that he diverged from Lisp, so him being smart I would guess he is now ignoring everyone. :)
The only thing I can offer is that it totally sucks to have an installed base and not be able to change things cuz you will break all the code ofyour users. Only at times like this is an inventor free to change everything and anything, I guess pg did.
I chose "call" because that's how "help" was named. The setters hash is just "setters," though, I believe. I dunno, if you come up with a better name, feel free to rename it.
I don't really care that much, (at least not enough to bother changing it), just thought we might want to follow pg's conventions (in so far as those conventions exist).
File tables have some pretty interesting implications for persistent processes. (This would be even better if you could use data structures other than just strings as values.)
Would it be possible to associate file tables with specific directories? In the current implementation, the directory for the file table changes whenever you use change the working directory, so you can't really have file tables in multiple directories at the same time.
Should be possible if you give a fully qualified path (file-table "/home/eds/somewhere")
Anyway it's probably better to figure out how Arc can get the fully qualified path from a path string, i.e. (get-fully-qualified-path ".") => "/home/eds/arc-installation/". Probably by ($ ...)
Unless you're referring to something else?
As for "other values".... the only real problem anyway is serialization. Ordinary Arc values that can be input into Arc via text are of course trivially serializable, but something created via:
(= x (cons nil nil))
(= y (cons x x))
(= (cdr x) y)
Its not that serialization is difficult, but this seems like repetitive code that should be abstracted away. Maybe we should have one type/mode/version of file-table that reads everything as a string, and another that automatically prints a readable representation so that the object can be read back in later.
Of course, the above doesn't memoize, so repeated calls to ftab!fname will return different ((iso ftb!fname ftb!fname) => t, (is ftb!fname ftb!fname) => nil) objects.
And of course, you're not supposed to write circular objects with the above.
And then someone will want to use temload and friends... hmm. Need a good way of abstracting the abstractions...
Then memoization will be done on the file-contents (ct and mt) tables instead of actual file-table objects.
It would be useful also to have non-memoized versions, accessible via 'nocache:
(def grep* (rex path)
(zap re rex)
(accum collect
(ontable k v (file-table path 'nocache)
(if (re-match rex v) (collect k)))))
'nocache would be useful for such cases where you want to scan through files but not cache their actual contents.
It might also be useful to store cached contents only for a certain time, to preserve memory (but then gc will get run anyway).
p.s. supporting tagged options will make an optional path argument difficult. I suppose I can check if the first argument is a string, though, and treat it as the path if it is.
Great! This means infix.arc can now be defined entirely in arc without needing hacks in ac.scm. (Although this also means infix.arc is now dependent on defcall.)
Would it be possible to delegate searching out to google, just save the user the trouble of typing the extra "site:arclanguage.org"? I know I've seen sites before that used google search for the site's internal search. (Although admittedly, I have no idea how difficult that would be to set up.)
A form that redirects to google should be easy to implement. Another simple approach, that you can do for yourself, is to add a quick search in Firefox. I have this bound to keyword 'a';
The problem with using google to search forums, however, is that it doesn't know anything about threads. When I type 'a module' in FF's location bar, I get 121 hits (should be 122 after I post this ;), and I have no idea how many threads that is - not very practical.
in order to make this work. Else scheme might complain if the version the user is using is different than what the distributer used. Perhaps arc.arcc shouldn't actually be part of Anarki? (And add something to arc-exe.scm that will automatically compile arc.arc the first time if it isn't there already?)
It might also be nice to have a feature where the .arc file would be automatically compiled to its .arcc version whenever the date on the source is newer than the bytecode. (I think Python does this with .py and .pyc files.) Although it is true that you don't get any speed benefit from doing so, and only save startup time after the first startup.
Oops. You're right. It might not work with different versions of mzscheme.
So I removed arc.arcc from Anarki. Now, arc-exe generates it automatically if it cannot find it on startup. And the -cc flag doesn't write anymore on stdout but directly in file foo.arcc (if you called arc-exe -cc foo.arc).
Your point about date diffs between .arc and .arcc files is also interesting. Python does work this way. I might add it later (if nobody does it before me :)
Thats better. But its a little strange that when you run it the first two times, it compiles the arc.arc and libs.arc instead of starting up, I would expect it to both compile and start up.
I get the following errors when I try to start arc-exe:
C:\User\Programming\Arc\arc-wiki>arc-exe
Use (quit) to quit, (tl) to return here after an interrupt.
arc>
now arc-exe starts properly.
EDIT: Actually, arc-exe doesn't seem to be working properly. I can't access any of the predefined functions:
C:\User\Programming\Arc\arc-wiki>arc-exe
Use (quit) to quit, (tl) to return here after an interrupt.
arc> prn
Error: "reference to undefined identifier: _prn"
arc> (prn "hello world")
Error: "reference to undefined identifier: _prn"
arc> quit
Error: "reference to undefined identifier: _input-history-update"
arc> (quit)
although at least I can quit. This problem doesn't occur with mzscheme -mf as.scm.
This is using Anarki cloned on Wed Feb 27 22:36:04 PST 2008.
The problem ended up being that the definition (xdef 'ref ...) was missing from arc-exe.scm for some reason. Copying it over from ac.scm fixed all the problems I was encountering. Pushed the fix to Anarki.
That would be because I defined ref, and only thought to put it in ac.scm. We should come up with a way of dealing with this. I suppose we could admonish everyone to make changes to both files, but that seems a little annoying and apt to fall victim to forgetfulness.
Would you be willing to take on the responsibility of running "git log ac.scm" periodically and copying stuff over?
Wouldn't it be possible for arc-exe to just (load "ac.scm") somewhere? Admittedly I don't know enough about the mzscheme compilation process to figure out why it won't work that way - something to do with modules not being able to use (load ...), maybe?
No, it's not possible. There are problems with mzscheme's namespaces. I had to fight with them to make arc-exe work, and simply importing ac.scm in an englobing file will just not work.
Hmm. How about a macro which reads in the code from ac.scm and inserts it into a progn form? Would that work?
(defsyntax insert-file-here ()) ; dunno, never figured out scheme macros
(module arc-exe mzscheme
(insert-file-here "ac.scm")
)
Where (insert-file-here "ac.scm") would expand to:
(progn
(provide (all-defined))
...
(define (ac s env)
...)
)
Would putting the defines in (progn ...) work? Sorry, I'm not very good at macros in scheme, never managed to grok hygiene.
The alternative is to have the macros generate the (module ...) code, and insert the code inside the modules of ac.scm and as.scm and what else arc needs.
Basically what I'm proposing is writing a macro which does what you originally did in creating arc-exe.scm. The unfortunate part is that I never managed to grok Scheme macros, otherwise I'd offer to do it for you if you describe how you built arc-exe.scm.
Looks like an excellent proposition. I'm not very good with scheme macros either, however I think mzscheme has an à la Common Lisp define-macro extension. I'll look about that more precisely.
Is it really namespaces that are a problem, or modules?
I hacked together a short version of arc-exe.scm that worked just fine importing from ac.scm. The only problem with that version was that it wasn't a module, and thus couldn't be compiled by mzc. I couldn't make it a module because scheme complained when brackets.scm tried to override read and read-syntax. (Apparently overriding imported bindings only works outside modules.) And when I tried to modify or not include brackets.scm, it would complain that it couldn't find the module ac.
So did you encounter this particular problem or something else? My guess is that if I could make brackets.scm behave, I could make the rest of it fall in line. But maybe I am mistaken about this.
Anarki works on Windows as of yesterday. (I think the solution was to use scheme's date and mkdir functions, which should fix the problem on all platforms.)
