Only got through the first half before my the flickering in my status bar was so irritating I had to stop reading. Sorry Dustin but if you're talking about user experience, please do not have my browser ajax your site every couple of seconds.
> Reading about finding and learning a programming language is like reading about an artist choosing a brush.
Wands are a much better metaphor to make. Or perhaps, what if you had a magic brush that could at any time be extremely fine or large or anywhere in between depending on how you felt? That would be some brush, especially when you compare it to the many medium sized brushes which aren't so fine when you need them to be.
Okay, so maybe the metaphor is still stretching a bit, but these are no ordinary brushes; they are worth writing about.
I'm sorry but this seems an aggressive comment to me. CatDancer did mention the preference of simple macros over MzScheme's more complicated hygienic macros. Beyond that, Arc is different from Scheme and everyone knows it. The differences are documented and they are the reason why Arc is not Scheme. You do not have to challenge the piece just because you don't particularly like the changes Arc made in comparison to Scheme.
It is unfortunate for abstractbill to use this incorrect explanation, because hygienic macros are still a red herring - a decent module system and a bit of restraint gets you there.
(define-macro (my-if a b c) `(std.if ,a ,b ,c))
(define (boo)
(let ((if list)) ; if is shadowed
(my-if 'x 'y 'z))) ; gives (std.if x y z)
(define (boo2)
(let ((std.if list)) ; error! cannot shadow module vars.
(my-if 'x 'y 'z)))
I've posted this around a few times asking why this isn't already used in Lisps and never seem to get a convincing argument back. The only conclusion I can draw from this is that CL-ers are ashamed of the fact that multiple namespaces aren't actually necessary and Schemers are rightly ashamed of hygienic macros. Please convincingly prove me wrong!
(ps. This ofcourse would not be limited to the languages std module but would also apply to any exported module symbols.)
That's exactly what I meant in "In CL ... (b) using packages greatly reduces accidental shadowing." So I'm not sure what you are asking to be convinced. CL certainly does not prevent you from messing with package-private symbols, but usually a convention is enough to avoid disaster. I mean, I won't write (let ((your-package::private-symbol list)) (your-macro ...) ...) unless there's absolute need to do, such as emergency workaround of a bug in a third-party library.
On the other hand, one of the reasons Scheme avoids explicit module prefix is, I think, that it breaks abstraction. Suppose my-module defines my-macro and my-function. My-macro expands into a call to my-function. But I don't really want my module users to call my-function directly, so I only export my-macro and keep my-function private.
In your proposal, my-macro will expands into prefixed-symbol like this:
But... if we allow module-private function to be called with module prefix, we can't prevent ordinary code from calling my-function as well.
This is a language design choice. Some may not mind others to mess with module-private bindings; CLers certainly would not. But if you want to hide module-private symbols, and want to allow macros expand into them, how will you do that? One idea is to mark the output of macro expansion so that the compiler can distinguish whether the reference is from legitimate macro expansion or not... well, that's what hygienic macro is doing.
Thanks for the explanation. I hadn't thought of the my-macro problem because I tend to think of macros exactly as a clever copy paste mechanism, so would expect it to always use public variables, but I guess some people might have a problem with that in some cases.
In the first point I was asking to be convinced that you can't have hygiene solely through the use of a package / module system and without needing multiple namespaces.
Although your workaround argument (for allowing variables to be shadowed) is convincing, in that case the package system wouldn't really be providing any safety at all and only the convention would be helping. I guess we can sum it up as CLers really don't see a problem at all, and Schemers require macros to be completely abstract.
(mac awhen (expr . body)
`(std.let it ,expr (std.if it (std.do ,@body))))
This assumes that awhen is being defined and exported from the std module too, so that it can also be used in expansions. Slightly more verbose, but that's optional hygiene if you want it.
> On the plus side, the discussions that happen in Comments are definitely still good.
Maybe its me, but I've found a lot more comments within the past fortnight or so grating on me than previously. Remarkably, every time I checked the submitter, they'd been on Hacker News for about a year and a half at least.
And by grating I basically mean rude and unhelpful.
I've noticed a lot of the top voted comments lately are riddled with poor thinking and logical fallacies. I'm not sure if the smartest commenters are leaving, but the crowd definitely seems to be rewarding nonsense.
A few times I've found the account is over a year old, but comments only started recently. If the front page of their comments was filled (i.e. 10 comments), I probably wouldn't have noticed this. BTW they didn't seem especially bad, just the typical newbie comments before someone replied "Please elaborate".
It might be worth doing one more version considering the ratings only from people who have contributed significantly to the culture (their karma along with age should reflect reasonably well i guess)
Agreed. The only reason we associate life with self-replicating is because living things don't last long without it, but it doesn't mean you need self-replication to be alive.
That's fine, but don't leave it as analysis done. twitvid.com is blatantly copying twitvid.io and that's wrong, end of story.