Lisp is not popular because it was not at the right place at the right time. Other languages were, but that is all they were. Lisp meanshile is as good (and superior) as it ever was. And it is catching on, part of why I ranted that it is time to stop wringing our hands over Lisp's popularity and start programming with it. Or Arc. :)
(rv) generates a random algebraic variable. I am writing an algebra tutorial in CL and this code is from my DSL for the bit where I randomly generate algebra problems. (rv 2) would return a list of two variables one would reasonably find in a typical text. ie, x and y or m and n, but not x and a.
(dsb (a b c) (shuffle (cons 1
(random-primes 2 2 10)))
dsb is destructuring-bind. I did not use random-primes very oftwn so no abbrev. yet. :)
(dsb (x y z) (rpu 3 (r+ 5))
(rp n form) expands into a loop expression that repeats that many times collecting the result of the form shown. rpu is the version that ensures no duplicates (u for unique). (r+ n) generates a random number from 1 to n inclusive.
(m+- (m+- (ms* a (ms^ v x))
(m+- x y) generates either a mathematical expression tree my software will use for tutoring, randomly x+y or x-y
ms* generates a product as does m, but is smart about it and tosses a factor of 1. likewise ms^ returns a power but not if the exponent is 1, then just the variable. mss^ is supersmart and converts x^0 to 1.
(ms* b (ms^ (xqv v) y)))
xqv is short for mx-equiv, which copies a mathematical expression to get an equivalent expression. (mx-copy creates a Lisp copy that is "EQ" the original at the application's level of abstraction.
(ms* c (ms^ (xqv v) z))))))
Hmmm. This is a problem in factoring out the gcf of three terms ax^i + bx^j +cx^k.
Note that the above is as much about DSLs as it is about abbreviation, and I think if I wanted to delay shipping even further <g> I would break down and do a full parser of something like "ax^i + bx^j +cx^k,(abc)=[1 5],....".
One funny thing is that I was not even used to one thing: a let just to bind one local at the head of a function really bugged me, so I would use &aux to avoid it.
But yeah, just a few weeks of arccing and I realized I was hitting myself in the head with a hammer and decided to stop, or rather, how much surprisingly nicer it was to just superabbreviate and de-parens the obvious.
Of course I try not to use LET (I think there is a tax on it) but I was doing a DSL which was always starting by picking a random entity that then got re=used a few times, so I was in Letville unless I wanted to go nuts and code-walk in my DSL.
> a let just to bind one local at the head of a function really bugged me, so I would use &aux to avoid it.
> Of course I try not to use LET (I think there is a tax on it)
In Cadence Skill, the lisplike we use in the office, 'let does have a tax to it when using lexical bindings; environments were pretty hefty objects and using 'let in a loop would generate a lot of them as garbage (the language implementation doesn't even have tail call opts!). I ended up using @optional (approximately equal to &optional) for some variables in time-constrained code, which helped reduce environments.
Arc is now offically a Lisp! When detractors try to say "the number of libraries available sucks!", somehow the name of the language comes out instead of "the number of libraries available"!
I have no idea what pg et al are up to, but google says the list of approved mentoring orgs gets announced here: http://code.google.com/soc/2008/ tomorrow. If you do not see an Arc group, talk to Lisp-NYC (er, assuming we get approved -- if not, look for any group in the Lisp family).
Firefox cannot load any of the icons so all I see are broken icon images. When I wanted to hit "back" I accidentally voted it up. I was kinda hoping it would start a groundswell of enthusiasm for the comment and it would soar to the top ten.
"This seems like such a simple request - I can express it in a few sentences"
Awesome. I want to time travel. That's just one sentence. :)
"it should be at least not extremely difficult to implement in the ideal programming language"
Cue the asbestos! No one said Arc was intended to be some abstract ideal satisfying all few-sentence specifications, and as per the Java crack, who says that the ideal language is idiot-proof or attack-proof? To the contrary, the Design Imperatives I have seen trust the programmer to be good and are not hoping to be able to run virus attacks imperviously.
As for your question, it is a hard problem and one reason I think we do not have a Lisp plug-in for browsers.
I don't mean to start a flame war - I am certainly not a big Java or JavaScript fan ;-)
I don't want to make the language idiot-proof. I acknowledge this is a hard, rather "meta" thing and I was hoping Arc would be powerful enough to do this.
So, regardless of whether "the ideal language would have it", you agree this would be very useful; it would let us have an Arc plug-in for browsers for example. Or make a site
where you could make your own Arc site by entering code and the main servers would run it restrictedly. Arc is trying to be native to the web, and allowing restricted execution is a very webby thing to do.
"I was hoping Arc would be powerful enough to do this."
OK, asbestos did not work, try the foam!
What you might be missing is that power makes attacks easier, not harder. As I suggested, part of that power is reflection so you have a fighting chance, my concern is that once you have blocked all the exits there will be no way to get in. Whatever that means.
"you agree this would be very useful"
I do? Wow. Actually, I do not know much about security,tho I might have to learn soon. My guess is that probably the best way to go is not to cripple the plugin, rather to allow only registered, vetted, digitally signed code to run. ie, the plugin looks for a digital certificate before launching.
Tilton's Law: Solve the right problem. What is the problem? Losers posting evil code. Solution? Don't run just anyone's code.
"I think we do not have a Lisp plug-in for browsers"
Well, we have JavaScript, and it is not really safer by design than Lisp (they are quite close, too). But JavaScript has a security manager, quite restrictive sometimes. And look at rebol : that's also a close relative to Lisp and it's got a cool security manager.
Well, they mainly prevent you from reading/writing the host filesystem or from connecting to undesired remote servers.
Lacker, this might not be as "secure" as Java's model, and not exactly what you were asking as it does not prevent you from overwriting another's code, but it is obviously enough to run untrusted code on one's machine. And to implement it, you only need to overwrite the dedicated axioms in ac.scm.
Then there was that other ILC where the speaker argued we Lispers should rejoice because Javascript was a Lisp and was in all the browsers. Make sure there are no children in the room and I'll tell you what happened next.
"Personally I'd do a recursive expansion of the optional/keyword part"
I'll be honest, I am just a simple application programmer, I was stunned for example by the expansion of withs.
And I am just a muddy Common Lisper, I am not smart like the Lisp-1 guys, I do not know how to express the number 3 as a half-dozen nested lambda forms. So...
...that's a long way of saying I think you are right, there is almost definitely a nicer lambda-based solution out there. I would say I would love to see it except I doubt I would understand, I have been to Lisp-1 talks and never understood a word, I've stopped going.
But I would enjoy seeing a recursive solution, your approach sounds promising and even easy to read, more than I can say for mine.
Turns out that 'withs is recursive enough for this ^^.
(mac dsb (params data . body)
(let (reqs keys opts) (dsb-params-parse params)
(w/uniq (tree kvs)
(withs (optfn
(afn (l)
`()))
; turn reqs into the argument list, adding
; the ,tree as a rest argument
(if (no reqs)
(= reqs tree)
((afn (l)
(aif (cdr l)
(self it)
(= (cdr l) tree)))
reqs))
`(withs (,reqs ,data
,@(mappend [list (carif _)
`(do1 (if ,tree
(car ,tree)
,(cadrif _))
(= ,tree (cdr ,tree)))]
opts)
,kvs (pair ,tree)
,@(mappend [list (carif _)
; don't use aif - dsb might be
; used itself in an aif context
(w/uniq it
`(let ,it (assoc ',(carif _) ,kvs)
(if ,it
(cadr ,it)
,(cadrif _))))]
keys))
,@body)))))
Yep, I concede. The recursive solution won't easily handle the cases in http://arclanguage.org/item?id=4423 . So this is really the best way to do it ^^.
Ha, ha, yeah right, I don't even use any lisplike programming languages in an application I've ever passed to a client (using a lisplike to generate an application in a non-lisplike is another statement).
...that's a long way of saying no, I'm not even a simple application programmer, I bet you've built more Lisp code that actually reached application level.
Anyway I'll be doing my hacking now, will come back in a few dozen minutes.
It's problematic for a recursive solution. ^^ So is the second. ^^ In the end I decided that the sketch up of your solution is better, since 'withs is, after all, recursive ^^
Cool. pg, if you are reading this plz let me know if we should advertise to Arcers or if your group will be doing so. You would get more student projects allocated as an Arc-specific mentoring organization, btw. Lisp-NYC only got a few projects from Google last time, and Arc students would be competing against students for other Lisps for the allocation.
In the meantime, interested Arcers who qualify under the Google rules are free to conjure up projects they think will be attractive to whichever group ends up mentoring Arcers, and/or watching the Lisp NYC space for project ideas provided by us and/or mentors outside our group. In the end the student applies to Google who forwards to the right group for assessment which the group returns to Google who then finally decides. Hope that's clear. :)
