You're definitely looking for a future then -- lazy evaluation wouldn't bother to even start calculating til the result was required, and it would block until the calculation was done.
I still don't see either mechanism making it into elisp, but futures are probably more feasible to implement.
I want lazy evaluation. I want to be able to do this: (setq some-variable (lazy (some-function foo bar))) And then I want the next thing after that to go ahead and be evaluated. I don't want execution to pause and wait for some-function to complete until some computation actually needs the value of some-variable.
I can't tell from just one small example using metasyntax, but that looks more like you want a future. Those would be nice, but I don't see emacs doing those anytime soon. If you don't want to compute something right away, wrap it up in a lambda and bind it to a symbol. Emacs's brand of lisp lets you funcall a symbol through as many layers of indirection as you want. I think you can even get closures from the cl package, even if they're not implemented terribly nicely.
Selective lazy evaluation is more of an occasional syntax convenience for specific problems like streams, but outside of those areas, it's one of the leakiest abstractions you can get -- you end up having to sprinkle laziness declarations all over unrelated code to maintain the laziness you want.
Much as I love emacs, I think you can be reasonably sure that the emacs lisp environment is purely in maintenance mode and will never see significant architectural changes. You want an editor with a pervasively lazy extension language, try Yi.
The compiler does a lot of unrolling. Newer GPUs do have actual branch instructions, but they have enough locality restrictions that you'd have a hell of a time making them fully general. Restrictions on what you can write back are also not particularly fun.
It's still turing-complete all right, but the memory fetch latencies and other restrictions would make it absolutely hellish to run an OS on a GPU, which is why they don't run one.
Video cards run nothing like an OS on the hardware, and you won't be getting one running yourself. Most GPUs don't have branch instructions (newer ones kind of do, but only in the "skip forward" sense). It's kinda hard to run an OS without those.
Now it is fair to say that the _driver_ is a sort of microkernel OS all its own (and also has an optimizing compiler at that), but it does still use your CPU to execute it.
Nvidia's entire 19x series of drivers have consistently been a problem with fallout 3, ranging from stuttering to BSOD's. I recommend installing the WHQL Release 186. I never had bluescreens, but it stuttered like mad til I reverted to 186. Got a few graphical glitches in complex geometry (clipping mostly) but they were minor and the smoothness was worth it. I'll give this to nvidia, at least they do make the earlier drivers easily available.
Now if someone could tell me which drivers will play nice with both Dragon Age and Anno 1404... Don't tell me, ATI, right?
Slashdot Mirror
> When I play with Windows 7 and the new Office Beta, I see dozens of my pet peeves fixed
That's because Windows 7 was your idea! ;)
You're definitely looking for a future then -- lazy evaluation wouldn't bother to even start calculating til the result was required, and it would block until the calculation was done.
I still don't see either mechanism making it into elisp, but futures are probably more feasible to implement.
I can't tell from just one small example using metasyntax, but that looks more like you want a future. Those would be nice, but I don't see emacs doing those anytime soon. If you don't want to compute something right away, wrap it up in a lambda and bind it to a symbol. Emacs's brand of lisp lets you funcall a symbol through as many layers of indirection as you want. I think you can even get closures from the cl package, even if they're not implemented terribly nicely.
Selective lazy evaluation is more of an occasional syntax convenience for specific problems like streams, but outside of those areas, it's one of the leakiest abstractions you can get -- you end up having to sprinkle laziness declarations all over unrelated code to maintain the laziness you want.
Much as I love emacs, I think you can be reasonably sure that the emacs lisp environment is purely in maintenance mode and will never see significant architectural changes. You want an editor with a pervasively lazy extension language, try Yi.
I see what you did there.
Maybe a hierarchy of "funny". Funny-Haha, Funny-Serious, Funny-I-Laugh-Lest-I-Cry ...
The indexes only work on MyISAM. Who needed transactions anyway? Every feature MySQL lays claim to is always full of gotchas like this.
The compiler does a lot of unrolling. Newer GPUs do have actual branch instructions, but they have enough locality restrictions that you'd have a hell of a time making them fully general. Restrictions on what you can write back are also not particularly fun.
It's still turing-complete all right, but the memory fetch latencies and other restrictions would make it absolutely hellish to run an OS on a GPU, which is why they don't run one.
Video cards run nothing like an OS on the hardware, and you won't be getting one running yourself. Most GPUs don't have branch instructions (newer ones kind of do, but only in the "skip forward" sense). It's kinda hard to run an OS without those.
Now it is fair to say that the _driver_ is a sort of microkernel OS all its own (and also has an optimizing compiler at that), but it does still use your CPU to execute it.
Nvidia's entire 19x series of drivers have consistently been a problem with fallout 3, ranging from stuttering to BSOD's. I recommend installing the WHQL Release 186. I never had bluescreens, but it stuttered like mad til I reverted to 186. Got a few graphical glitches in complex geometry (clipping mostly) but they were minor and the smoothness was worth it. I'll give this to nvidia, at least they do make the earlier drivers easily available.
Now if someone could tell me which drivers will play nice with both Dragon Age and Anno 1404... Don't tell me, ATI, right?