(def whatever (row) (row "something")) ; unsafe
(def whatever (row) (do.row "something")) ; safe
(def whatever (row) (or.row "something")) ; safe
; The "or.row" one is possibly more efficient, since it expands to
; "row", but I use "do.row" 'cause I don't want to desensitize myself
; to "or".
(def whatever (tab key) (= tab.key "something")) ; unsafe
(def whatever (tab key) (= do.tab.key "something")) ; doesn't work
(def whatever (tab key) (= or.tab.key "something")) ; confuses me
(def whatever (tab key) (= .key.tab "something")) ; safe
As long as I keep this up, my macros and parameters can conflict all they like, and it doesn't matter. But this approach basically amounts to qualifying the name of each parameter as it's used in function position, so from my point of view, macros and parameters almost don't live in the same namespace.
rocketnia
|
cached 26 minutes ago
|
|
cached 23 days ago
In my code, I've been doing sorta convoluted things to avoid accidental macro-expansion just like what you're talking about:
|
|
cached 23 days ago
|
|
Modules, Multimethods (Kinda), and More for Arc
(rocketnia.wordpress.com)
cached 23 days ago
|
|
cached 12 days ago
If you need to use the particular name "." and you're not worried about brevity, you can input the symbol like this:
It's the same as escaping the symbols |(|, |)|, |'|, |"|, etc. These characters have special meaning to the reader, so they're less convenient to use in symbols.As for . specifically, it's special to the reader because of dotted lists:
Also, as long as . is already special, MzScheme overloads it for a kind of infix-like syntax sugar, which Arc inherits:
A reader could probably be smart enough to interpret "'." as being equivalent to "'|.|", but this one doesn't go to that trouble. I don't blame it, either. As long as . means something special to the reader in one symbol-like place, and as long as MzScheme is going to use it for other things like infix syntax, it might as well be treated as a reserved word.
|
|
cached 23 days ago
First off, two bugs: You use 'append rather than 'join, and 'shuffle_numbers will overwrite the global variable 'i since 'i isn't a lexical variable at (= i (- max min)) and (-- i). There might a third bug where you say (~is (caar lst) 'fn), but I'm not sure what your intention is there.
Next, there are some things you can simplify. In shuffle_members, you have "let temp 0 @", which isn't doing much, and you also have "@ arr" at the end, which is unnecessary. Unlike 'let, 'w/table automatically returns the value its variable has at the end of the body. In span_let, there's a place where you check [and (is (type _) 'cons) (is (car _) 'scope)], but FYI, that's exactly what [iscar _ 'scope] does. :) Also, I don't expect you to know this right away, but you can accomplish the decreasing loop using (down i (- max min) 1 ...); 'down is a backwards 'for. Finally, it's really not a big deal, but these names would be more consistent with Arc:
I think that the scope macro make the code more readable. What do you think?I don't really think it makes it more readable, but that's only because it introduces new rules I'm not accustomed to. The "let temp 0" line is clearly supposed to wrap the whole area, but I had to open up Arc and check to see whether the 'for loop wrapped the 'loop loop or not. (Your indentation might have been a clue, but I suspected a bug.) In total, you removed ((()())) and put in (scope @ @ @ @) and some extra rules to worry about. I think that's sort of a net loss. But hey, it could be the basis for a better idea. If it helps you read your code, then I think it's worth it already. ^_^ |
|
cached 9 days ago
It was just there for a brief pause between the macroexpansions of declare and undeclare.
If we want to change the behavior of other macros for a certain region of code, then that pattern might be useful. Since we seem to be talking about static type declarations, which I presume would be taken into account at macro-expansion time, I think the "between the macroexpansions" behavior is the whole point. |
|
cached 2 days ago
Here's the code I tried:
If I repeatedly request foo, my Racket process's memory usage (Racket 5.0.1 on Windows XP) climbs as high as 50-60 MB, but after another request, it garbage-collects and releases about half the memory. It does reach higher peaks if I keep going, to the point where now it's going up to 120 MB and dropping to 60, but clearly all those strings I'm making are at least eligible for garbage collection, even if the garbage collector lets more and more of them stick around.So I've seen no evidence of a memory leak yet... but then again, I haven't had an Arc server run for longer than it takes to do poking around like this. Maybe you should try out a more recent version of Racket? |
|
cached about 5 hours ago
Performance: for the sorts of exploratory programming I do, performance is important. For instance, one thing I did when trying to figure out the code was match all substrings of one watermark against another, to see if there were commonalities. This is O(N^3) and was tolerably fast in Python, but Arc would be too painful.
Here's a take on it. It isn't so painful, probably because it only takes about O(N^2) time. :)
-
-
To summarize, I started off in Arc, switched to Python when I realized it would take me way too long to figure out the DNA code using Arc, and then went back to Arc for this writeup after I figured out what I wanted to do. In other words, Python was much better for the exploratory part.Yeah, I know just what you're talking about there. Still, it wasn't long ago that I found my ideas easiest to express in Java, so I think familiarity has an awful lot to do with it. I'm afraid even Arc's error messages can be an acquired taste. :-p |
|
cached 23 days ago
I kept hoping to find out it was just an April Fool's joke, but I guess it isn't. >_<
The first thing I think of when I hear the name "Racket" is tennis, suggesting the language is but one frequently visited taking-off point in some larger system. That would be okay if it were more obvious how it was meant; for instance, maybe the Racket language is a taking-off point on the way to the other languages PLT Racket supports. One could also talk about parentheses as being like Pong paddles, but that's a stretch. The second thing I think of is a loud, grating noise, suggesting the language is a pain to read. This may or may not be an accurate description of the Racket language--hello parentheses--but the fact that it's an aversive connotation suggests that the language eschews utility (like Brainf___). Then again, I suppose naming a language after an intentionally obnoxious noise is better than naming it after an unintentional speech impediment (Lisp). The third thing I think of is organized crime. Now, that's in the same ballpark as "evil mastermind," which was the first thing I thought of when I heard of Scheme (the second thing being blueprints), and indeed that's the association they're shooting for. In the context of that association, there's even a vaguely useful meaning to it; in my mind, small groups and individual masterminds scheme, whereas large organizations and conglomerates racket. The thing is, if any language deserves to be named after organized crime, I'd say it's either something like C# whose use rather exclusively benefits one closed platform (not that it would name itself that way), or something like Mono which provides one of the few alternatives to such a platform. Trying to equate "organized illegal activity" with education and with multiple-language techniques doesn't make nearly as much sense. Oh, and finally, "Racket" is eerily close to "Rocket," which is actually sorta positive for me (as my moniker shows). It almost makes me wanna write a parody dialect or something. ^_^ Racket's a terrible name for PLT Scheme, but long live Racket. I do think it's great to change the implementation name to something else, what with Scheme's own identity being intentionally split. |
