I'm using git and github as an experiment, wondering what the best way to share Arc patches might be. For myself, so far using git has felt like driving a tractor trailer to get a sandwich at the corner grocery store... big, powerful, can move an awesome amount of stuff, but clumsy... necessary when you have tens of thousands of lines of code, but when your language is high enough level that you don't need that many lines of code, is git actually useful? I don't know yet. In any case, I'm happy to get patches in any form that is convenient for the sender, whether by email, pastebin, or by github's "pull request" mechanism.
but theoretically you could host a bunch of languages in a single jvm instance - and have arc, clojure, jruby, jython, and javascript (via rhino) all calling each other in a big polyglotfest. Java 6 includes a scripting framework ( https://scripting.dev.java.net/ ) that standardises the way a jvm hosts a ScriptEngine. I haven't looked at this yet at all but it's on my todo list.
I've have to check the code at home, at work now.....
Essentially I'm taking a spreadsheet file (csv) with an arbitrary number of columns of data, reading in the headers so they can be output to the html table as headers then reading in the remainder to create rows in the html table.
also also letting users to pick and choose which columns of data they want by selecting header names.
I've pretty much got it all working, I'm just surprised the language wouldn't provide for passing in results of an iteration function cleanly. To have to create an extra function simply to strip out the nil ends up making the code readability poor..... I'm sure I will look at the code in 2 months, scratch my head and ask why I needed a second function.... of course by then I'll probably have found a better way :)
Unfortunately, this is then deoptimized for the most common one-argument case, where you have to write [... _.0 ...]. We could have [...] expand to (fn __ (let _ (car _) ...)), so that you would have
(reduce [- (/ __.1 (* 2 __.0))] mylist)
but still have
(map [+ _ (* _ _)] myotherlist)
. I still prefer the _1, _2, ... syntax, though---unsurprisingly, as I contributed that implementation (though not the idea) :)
Actually, I do think the _1, _2 .. syntax makes the most sense, if you aren't wanting to name parameters. Though maybe (as was mentioned above) in some cases, the first three should be a b c, or x y z? I don't know how you would set that up to work well with what already exists though.
I implemented something like the first one in my m-expression reader, "a -> b;" is translated into "(fn a b)". It could be used with cchooper's customisable reader, so you can still use s-exprs most of the time, like this: