I'm motivated like I usually am by things on the internet -- "you're wrong, let me show you how". If functions are first class, then you can't prevent recursion. I think the Y combinator (or the U combinator, maybe?) can make recursion happen quite easily.
I didn't have the heart to tell him that 1. the language isn't Lisplike, which is a dealbreaker for me, and 2. I don't have room in my life for two languages no one uses.
I don't think he's actually written much in the language (which is somewhat understandable, since the damn thing isn't implemented yet), and that's causing problems because he hasn't realized how annoying simple things like his any statements become.
I haven't asked him this yet -- I'd like him to answer a question I've asked three or four times now first -- but why do some statements run in reverse order? The definition of let and get from http://code.google.com/p/aha-programming-language/wiki/Getti...:
>The statements after the where clauses are evaluated in the reverse order (i.e. from the end)...
This just seems bizarre, confusing, and not at all useful. But we'll see.
If a where clause's binding expression ran after the body in an eager language, we couldn't use the value during the body. We'd be limited to using it from inside closures (manual laziness).
I do have ideas, but none that make sense. :-p It does seem better to embrace top-to-bottom side effect ordering throughout all syntaxes of the language, with as few discontinuity points as possible.
But if we want to embrace that, it's probably hypocritical if we use prefix syntax for procedure application. ^_-
Yeah it'll be interesting to see how it goes. I'm actually more favorably disposed after the thread on the list. His motivation is a reasonable one: to make the static shape of code more closely mimic how it looks at runtime. This requires constraints so it feels kinda wild and whacky. But I'm glad somebody's trying these ideas.
Running statements in reverse order isn't such a big deal. Concatenative languages seem backwards, and even preorder is kinda weird at the start.
The best new languages require so much tolerance to the bizarre that it hurts. Alan Perlis said, "A language that doesn't affect the way you think about programming is not worth knowing." I just realized he didn't say, "A good language.." Potential dead ends can be worth knowing as well.
Mumps Interpreter V11.0 Fri Jun 08 11:19:45 2012
> s a="345"
> w a+1,!
346
> s a=" 123" ; With a space at the front, it does not qualify
> w a+1,! ; as a number and defaults to 0
124
>
Running Rainbow or Jarc from a jar is easy, but there are some caveats:
- Both Rainbow and Jarc expose JVM reflection capabilities to Arc, and thus provide the Arc program with ambient authority. This is convenient for an application written in Arc, but it means we should only run Arc code the user trusts. (Rainbow might be possible to tame by nilling out some global variables, but I wouldn't count on it, and it doesn't seem in the Arc spirit.)
- Both Rainbow and Jarc intern symbols into a static field, so if someone's Arc coding style causes their program to intern lots of symbols, it may be difficult to reclaim the memory. (In fact, I wonder if Racket has the same issue.)
- Rainbow stores global variable values in the symbols themselves. Since these symbols are interned, it would be difficult to manage more than one global namespace during any given run of the JVM program, let alone to manage more than one independent Arc runtime, as a REPL program might like to do.
- Jarc has support for bytecode generation, but it probably won't work on Android. I don't think Jarc depends on bytecode generation for normal functioning, but I don't know Jarc well enough to be sure.
- Rainbow's example code, including its welder.arc text editor, makes heavy use of Swing, and I doubt that will work on Android.
Interned and unreadable symbols are only weakly held by
the internal symbol table. This weakness can never
affect the result of an eq?, eqv?, or equal? test, but a
symbol may disappear when placed into a weak box (see
Weak Boxes) used as the key in a weak hash table (see
Hash Tables), or used as an ephemeron key (see Ephemerons).
Kinda. It irks me that a value that's still arguably reachable (via 'read) could be observably lost by a weak box, weak hash table, or ephemeron. But it seems feasible to create readable-counts-as-reachable versions of these data structures on top of the built-in ones, so the built-in ones expose strictly better lower-level control.
One thing I should explicitly mention: you could replace '' with an extra bit of metadata in all values (symbols, cons cells). I'm averse to adding a field to my core Cell data type for this because I don't want a reader coming to see it for the first time to be distracted with house-keeping for a special-case. It also seems more space efficient to only pay for '' when you have to, but that's a negligible concern.
It was very fun, but no talk on arc. I ended up talking about http://arclanguage.org/item?id=16378. I'd love to see a presentation on arc; I wasn't sure five minutes was nearly enough.
That sounds like a good talk. Anything beyond your post? I must admit that I haven't put enough time into the macro-apply situation, so I'm not even up to speed with your post, butI'd love to see slides if you have them.
My reason for giving a five-minute talk about Arc is -- well, beyond the usual "I don't know if I can do a longer one" -- I've talked to a few Lispers about Arc, and they're not very excited about it. In fact, it's denigrated. I wanted to give a short talk to convince people they want to learn more. Maybe not 5 minutes, but 15? I don't know.
Yeah I have other, less politically-correct, reasons not to want to talk to lispers about arc :) The reasons for not wanting to talk are themselves hard to talk about.
I'm not interested in trying to convince lispers about anything because they are pretty close-minded about their tools. Trying to evangelize anything risks a minor flamewar, and even if you avoid flamewars you end up thinking you might have better spent your time talking about something else.
At yesterday's talk there was the obligatory old dude speculating that I might be able to accomplish my already-eval shenanigans using reader macros on backquote. In itself there's nothing wrong with the idea. It's totally false[1], but that's ok. The bigger criticism is that I could predict ahead of time that I'd get some question like that. There's a huge bias in the sorts of questions that get asked by CLers, and that predictability is utterly boring. I find questions about why I don't use Apple similarly boring.
Crotchety old lispers are fun to talk to. Often I learn some gem I couldn't find anywhere else. At the risk of sounding condescending, I'm aware I'm on my way to being a crochety old man myself[2]. I've just learned to avoid certain topics -- and to change the subject when others don't know to avoid them -- so we can all get along.
Talking about lisps is like talking about text-editors. Perhaps it's more important to focus on what we do with our tools. A cool app in arc will be more effective at getting lispers to engage with arc than any words we can come up with. But you'll still have to fend off questions about why you couldn't just use Common Lisp for the purpose. Snort.
That said, I still would love to watch you try to explain arc to non-arc folks. Sometimes explaining a thing helps understand it better. The audience will almost all take it constructively. You'll just need to put up with the prospect of the occasional miscreant. And if you do you'll be a better man than me.
[1] I don't even need to know anything about reader macros to make that assertion, because my feature isn't just some syntactic sugar. It requires semantic support for fexprs. CL has no fexprs. QED.
[2] My girlfriend says I must have been 60 when I was born.
---
I don't want to sound like it was a terrible time. I had a fantastic time there, lots of great conversation with a lot of interesting people, and will definitely go back the next time. But even at a lisp meetup the best conversation is only tangentially about lisp. There was one lightning talk about building a distributed RDBMS inspired by Connection Machine principles. The guy didn't build it in lisp, but he figured lispers might be worth showing it to. And that is awesome; I think many people got a lot out of it.
wart> (def helper(a b) `(cons ,a ,b))
wart> (mac foo(a b) (helper a b))
wart> (foo 1 '(2 3))
(1 2 3)
wart> (foo @'(1 (2 3)))
008eval.cc:79 calling macros with splice can have subtle effects (http://arclanguage.org/item?id=15659)
005types.cc:263 can't coerce number 2 to function
Eep! You're right, this is a fairly common use case.
The good news is that wart's warning system has held up. If it can't handle it it throws that warning.
I still emit the warning, because examples like this fail:
wart> (def helper(a b) `(cons ,a ,b))
wart> (mac foo args (helper @args))
wart> (foo @'(1 (2 3)))
008eval.cc:79 calling macros with splice can have subtle effects (http://arclanguage.org/item?id=15659)
005types.cc:263 can't coerce number 2 to function
I haven't looked at your link yet, but I want to clarify my comment first so that we can attack it together after I'm updated. ^_^
My solution relies on unquote and therefore on backquote. I don't recall Kernel mentioning them; scheme seems to ignore them in general. But let's assume that they are implementable just like quote. When I say "quote" I mean this holy trinity :)
I know Kernel doesn't prevent quote, but it discourages it. Even if you got apply working with backquoted macros in Kernel, it wouldn't be very helpful if most macros were backquote-less as a matter of course. This seems like a limitation of the philosophy.
More strongly, I want to argue that having syntax for quote/backquote/unquote is valuable. In wart all symbols are overrideable[1]. It uses punctuation for quote/backquote/unquote/splice to highlight that they are different from symbols, more fundamental to the programming model. Supporting apply for macros has made them even more so, even more fundamentally entangled together and baked into the interpreter.
[1] The one exception is fn. Perhaps I should make it λ? Nah, that doesn't solve the problem. Hmm, the only punctuation character wart hasn't already put to use is #.. :D
"My solution relies on unquote and therefore on backquote."
Oh, right.
---
"More strongly, I want to argue that having syntax for quote/backquote/unquote is valuable."
I don't think that's as expressive as infix syntax. With the right kind of a.b syntax, we could write `(a b ,c) as qq.(a b uq.c), trading in some readability for the flexibility to define our own variants.[1] Would you still want to have dedicated quasiquotation syntax then?
(Even I might answer yes sometimes. The staged fexpr system I describe at http://arclanguage.org/item?id=15868 uses unquote syntax as a way to compute during a previous stage of the command processor.)
[1] Penknife does something like this, but the use of structured string manipulation instead of s-expressions forces it to use a string-like escaping mechanism for unquote: qq.[a b \,c]
