Which is exactly what I meant by "macros seem to work in functional position." But amkglor's original statement "compose does not work with macros" does not take into account the special treatment of 'compose in functional position, which is why I was confused.
And if I am not mistaken, first class macros, once implemented, could be used in other situations like your example above.
Looking at alkmglor's comment, it appears to indicate that a literalcompose doesn't work; when it's optimized out, it works fine. In other words, everyone is vehemently agreeing with each other ;)
And of course, first class macros could do this. But we don't have those yet…
You raise some interesting points, but first, I have to address a confusion I've seem come up before. It is this: arrays are not lists. Arrays are a data structure with O(1) indexing, designed to be accessed and not iterated over. Cons cells/linked lists are a data structure with O(n) indexing, designed to be iterated over and not accessed. What's more, if we have a dotted pair be an array of length two, we get
Cons vs. Array
-----------------------------------
(a . b) <---> [a, b]
nil / () <---> nil / []
(a . nil) / (a) <---> [a, []]
(a . (b . nil)) <---> [a, [b, nil]]
Arrays and lists have fundamentally different structures (one emphasizes first vs. rest, the other emphasizes here vs. there), and this is why mzscheme / PLT Scheme separates vectors (its arrays) and cons cells.
As for content: it seems to me that your title overstates your point. You appear to be arguing for the removal of hash tables as an axiom, which is different from arguing that they are "unnecessary". (To be fair, your second argument does propose to eliminate them, but you replace them with something with equivalent access "terminology" (though not speed nor mutability).) Hash tables (or really any sort of dictionary) and closures/anonymous functions are, in my opinion, the two most useful things in programming, so I feel that they should be part of the language; whether in ac.scm or in arc.arc doesn't matter to me as an Arc user. However, as someone who cares about the implementation, your point about simplifying the axioms and examining speed tradeoffs is a good one, and is worth considering (though I'll leave it for wiser heads than mine). It would be nice if we could get all our complex data structures out of one (or a few) axiom(s), and perhaps arrays would suffice; after all, they do for C.
That's an interesting idea, which would work nicely in some cases. (For instance, I like how (svgpage) looks, but not how (repeat 20) looks.) Here's an implementation (lightly tested):
(mac block body
(if (or (no body) (~cdr body))
(carif body)
(join (car body) (list `(block ,@(cdr body))))))
Actually, the Anarki supports exactly what you want with static files: a root directory for static files, and a table mapping extensions to mime types for them.
And there's a typo on your page: you don't close the code tag around "/getcontents?field=population&name=value", so the rest of the page is in monospaced font.
That said, your site is consistently fantastic, and I find it amazingly useful. Please keep it up!
But couldn't you decide that any macro was only evaluated once (so the my-oper in my-function wouldn't change), but macros were searched for in the lexical namespace anyway? This would mean that any call with a lexical in the functional position would have to be checked for macro-expansions at runtime, of course, but it would be slightly more reasonable.
Yes, but again: compilation during runtime. Meaning (most likely) some sort of JIT. Wanna try to implement this? You could start by hacking this onto pg's arc-to-scheme implementation.
Okay. Be careful to still be able to properly handle environments, without actually turning it into an Arc interpreter.
pg's ArcN is really an Arc-to-Scheme compiler. And I dearly suspect that this was the main reason for not implementing first-class macros. Macros are intended to work on the code before the compiler does, so having true first-class macros is a little difficult.
LOL. I suppose it's because the populace is mostly dissatisfied with the president, and the president is trying to appease the populace? Those are the conditions in our country anyway ^^
Though I don't use Windows, I am told that the Anarki (which I do use), among other things, fixes these problems. (It's a git repository for Arc that anyone can push to and pull from; it fixes bugs and has extensions to the language.) See http://arclanguage.org/item?id=4951 for details.
Well, I'm watching with fascination, but it's over my head. I'm working through Essentials of Programming Languages (Friedman, Wand, and Haynes), though, so maybe soon ;)
Yes, it's from "arc-en-ciel" - but "en ciel" doesn't mean anything in this context. One might map "en ciel" to "in java" and consider that java is heavenly, but that's not an interpretation I want to push :))
I don't have too much experience with web apps, but I've done a little PHP (and I've used Ruby for non-web stuff). PHP has an amazing amount of resources out there, and it's ubiquitous, which are two large plusses. But its capabilities are rather elementary, and while this can be fine, it often isn't. For instance, PHP doesn't have real closures, and it doesn't have first-class functions. (When C's functions are more first-class than yours, you know you have a problem.) You have to pass their names around in strings. Ruby, on the other hand, is a nicer language to work in--it has the things I mentioned, and even more. And when the language isn't fighting with you, you don't necessarily need as many resources; nevertheless, Ruby has them.
Javascript, though, I feel is a better language. Real first-class functions and closures, innumerable examples and tutorials (though not always good ones), and more. Its problem is that every browser understands it slightly differently.
So between PHP and other things, I feel that the difference is within the language itself, not in the modules and prebuilt things (as all of the mentioned languages have these). But working in PHP felt confining when I was using it, and that's something I took away. (It reminded me of Java in that regard—the same feeling of being confined, as though I couldn't do what I wanted to.)
