Random Hacks comments

"Jim Hefferon's Linear Algebra: A free textbook with fascinating applications" by Anon

Mon, 03 Nov 2008 07:38:50 -0500

You should also take a look at Gilbert Strang’s Linear Algebra video lectures on MIT’s open courseware site. They’re pure gold.

http://web.mit.edu/18.06/www/Video/video-fall-99-new.html

"September 8th, 2007" by rajika

Sun, 28 Sep 2008 12:29:29 -0400

congrats!

"McCarthy's Ambiguous Operator" by backtrack

Tue, 09 Sep 2008 12:40:37 -0400

There’s also goal directed computation as implemented in the Icon language, though you probably know about it.

"Ubiquitous Hoogle" by Bryan O'Sullivan

Tue, 02 Sep 2008 23:51:21 -0400

Lovely stuff, thanks!

"Haskell: Queues without pointers" by Eric Kidd

Mon, 01 Sep 2008 06:47:15 -0400

kumma: head and tail are easy enough (and fast enough, too). But to implement a queue, you also need some sort of “enqueue” operation. And that can get really slow, if you’re not careful.

Specifically, consider the following implementation:

data Queue a = Queue [a]

newQueue = Queue []

deq (Queue []) = error "Empty queue"
deq (Queue (x:xs)) = (x,xs)

enq (Queue xs) x = Queue (xs ++ x)

Here, deq uses head and tail (in the form of the (x:xs) pattern match), and it runs in constant time, no matter how big the queue.

But enq uses ++, which is seriously slow, because it makes a complete copy of xs every time we add an item to the queue. If we keep (say) an average of 1,000 items in the queue, that means we need to copy a 1,000 item list every time we call enq.

The alternate implementation you see above doesn’t have this problem. In our example, it can enq an item in a single operation 999 times out of 1000, and only reallocate the entire list 1 time in a 1000, instead of every single time. On average, that works out to O(1) time. For 10 lines of Haskell, it’s actually a pretty decent queue.

"Haskell: Queues without pointers" by kumma

Mon, 01 Sep 2008 04:24:42 -0400

Are tail and head too complex for use or what?

"Why Hygienic Macros Rock" by Scott

Tue, 15 Jul 2008 22:30:03 -0400

Daniel: Ok, thanks.

I’m acquainted with Forth. I read both Starting Forth and Thinking Forth a few days after posting the above comment, actually; I love the concatenative approach, though I find Forth a bit too low-level for my taste. (My favorite language is currently OCaml, so you can guess how I feel about working without any type system whatsover.) I’ve also looked a little at Factor, but not in depth.

That said, the source to a Forth interpreter in i386 assembly and Forth was one of the single most mind-blowing programming things I’ve ever read. When I saw that the interpreter had a bit for whether the code was being compiled or evaluated, and immediate functions could toggle it at runtime, everything suddenly made sense. So much flexibility emerging from so few constructs!

http://www.annexia.org/_file/jonesforth.s.txt

"Why Hygienic Macros Rock" by Daniel

Sun, 22 Jun 2008 21:47:00 -0400

I have actually read a lot about hygienic vs non-hygienic macros. I just cannot recall what blogs and sites I read them.

You might try smuglispweeny and lambda-the-ultimate blogs, though. And wikipedia.

The thing is, gensyms handles some of the stuff hygienic macros handle, but not all of the stuff. There are some complex cases which would require heroic efforts in LISP, and very prone to errors at that.

On the other hand, hygienic macros can access the runtime context, in a more verbose way.

So, really, they each can be used for the same things, with varied levels of complexity depending on the task. But let me advocate hygienic macros a bit here.

There once was a language called Forth. Forth was interesting in that not only it was written in itself, but all the internals were available to any programs written in it, and, furthermore, it could be changed at will. You could change the parser, for instance, or you could change how it performed compilation.

Needless to say, it was powerful in the way such languages are. The thing is… Forth lacked abstraction. Yes, you could change the compiler. But, of course, you’d have to know how the specific compiler you were changing worked—and I don’t mean simply dialect differences. The most famous Forth generated indirectly threaded code, quite a few generated directly threaded code, some generated subrouting threaded code, others generated bytecode, and others compiled directly to machine code.

So it was very powerful stuff, which had very little portability. Well, let’s be honest. It had no portability at all.

And here is the thing with non-hygienic macros… the programmers using someone’s macro also have to know how that macro works. Either that, or you add stuff to your macro until it is, effectively, hygienic.

So, by using hygienic macros, you guarantee a level of portability to them similar to library functions.

"Why Hygienic Macros Rock" by Eric

Fri, 20 Jun 2008 07:40:30 -0400

Scott: That’s a good question, and I don’t actually know the answer.

Most Scheme implementations take a distantly-related approach. They generally have two different hygenic macro systems:

A “low-level” macro system, which works roughly like LISP, but which provides hygiene by default, but also provides the ability to violate hygiene selectively. This tends to be a bit fiddly to use.
A “high-level” macro system, which is based on hygienic rewrite rules. This is very easy to use, and will work for nearly all common macros.

Of course, using the low-level macro system, you can easily implement Lisp-style non-hygienic macros.

The PLT people have recently added another very slick feature to the standard Scheme toolkit: The ability the selectively violate hygiene from inside rewrite rules, in a carefully controlled fashion. This is a really nice feature, and we’ve been using it at work with great success.

"Why Hygienic Macros Rock" by Scott

Thu, 19 Jun 2008 20:15:42 -0400

To what extent can hygienic macros be implemented in non- and vice versa? I’m more familiar with Emacs Lisp-style macros than CL or Scheme macros, but it seems like the hygiene involves automatically writing code with gensyms to avoid variable capture and other compile-time analysis. If one is implemented in terms of the other, it would probably make the most sense to have two different forms, e.g. hmacro for declaring hygienic macros, and macro for when you deliberately want to do things like variable capture.