Lambda the Ultimate

inactiveTopic Editors, Ahoy!
started 11/5/2003; 2:50:44 PM - last post 11/6/2003; 11:43:40 AM
Ehud Lamm - Editors, Ahoy!  blueArrow
11/5/2003; 2:50:44 PM (reads: 6162, responses: 8)
Editors, Ahoy!
Whenever I see that all the posts on the home page were posted by me (aside from our illustrious gues blogger) I get worried (and a bit bored...)

So I guess it's time for another one of those call to arms posts. LtU is your blog, please add to our collective knowledge base.

Since I've come to appreciate the style and areas of interest of most of the contributing editors, I lie awake at night wondering what Andrew is up to, and what Chris is working on. I suspect they think nobody cares. But we do, we really do!

And don't get me started on the editors that specialize in languages and techniques I am curious about. How dare they put my education on hold, and keep the rest of the LtU readership in suspense? Luke, please tell us something new about erlang...

I don't want to mention all the others by name (you know who you are), since this is becoming a long post as it is. Suffice it to say that applying pl theory to linguistics is something we are always interested in, Javascript hacks are cool, biology is one of my pet subjects and that Scheme workshops (and DSELs) are always good subject for LtU posts.

Last thing before I logout (and wait to see what news LtU will bring me in the morning): I am asking for help, not trying to force anyone to write. I hope no one is offended by the humorous tone of this message. My bell is rusty, but my intentions are good.

Posted to admin by Ehud Lamm on 11/5/03; 2:55:01 PM

Chris Rathman - Re: Editors, Ahoy!  blueArrow
11/5/2003; 4:57:48 PM (reads: 463, responses: 0)
...what Chris is working on...
Actually got 3 projects burning at the same time: HIPAA file formating for our vendors; Sarbanes-Oxley auditing software; and a cement compressive strength evaluation package. Basically all over the map. First two are mostly database problems (close enuf for government work) and the third i've been meaning to start on any day now (decided to use Python just to keep it interesting).

Gotta take the young ones to see Matrix Revolutions tonight, so i'll have to procrastinate a bit longer on the posting. :-)

Luke Gorrie - Re: Editors, Ahoy!  blueArrow
11/5/2003; 9:16:55 PM (reads: 437, responses: 0)
Here's something about Erlang: it's pretty!

Cute trick, huh?

I'll be sure to report something more substantial after the conference later in the month!

Christian Lindig - Re: Editors, Ahoy!  blueArrow
11/6/2003; 12:16:39 AM (reads: 420, responses: 0)
This may have been discussed here before, but I cannot find it: I'd be interested to hear about language and implementation features that support testing of programs. I don't think so much about classical debugger support but features like assertions. We have assertions for values, but we don't have assertions for control flow. Would it be useful to assert that before g() can be called, f() must have been called? If anybody has thoughts about this, I would be very interested to hear them. I also get the impression that aspect-oriented programming is a good way to add functionality to an existing program that helps to monitor its execution. While I am skeptical abot AOP in general, I can imagine it works for testing, because testing is orthogonal to other functionality.

PS: Is LtU as slow for everybody else as it is for me?

Luke Gorrie - Re: Editors, Ahoy!  blueArrow
11/6/2003; 2:25:02 AM (reads: 393, responses: 0)
A pretty fancy idea is VerifyOutputWithGrammar. We used this recently to write a (creepingly complexifying) protocol between Emacs and a Common Lisp process in an editing mode we're writing. The verification means that any illegal protocol messages are immediately detected and properly reported.

The protocol lets Emacs evaluate code in the Lisp process, command the debugger (possibly recursively), redirect I/O streams, and various other things all at the same time. Throughout all this, Emacs and Lisp need to remain properly synchronized. In the Emacs code we have formalized this into a (macro-supported) state-machine, such that if an illegal transition is attempted the user gets a buffer explaining that they've found a bug and plenty of diagnostic information.

This debugging feature has been extremely useful. In the past week two users have reported protocol-violation errors which we could immediately attribute to out-of-sync Emacs/Lisp code versions. Without nice error reportage, it would surely take a lot of to'ing and fro'ing to figure out what's wrong. This is the most use I've had out of assertions in quite a while :-)

BTW, the state machine code is perhaps an interesting case for our previous discussion of macros. On the one hand, Lisp macros helped us to very neatly code the state machine. On the other hand, if we had real coroutines it probably wouldn't have been worth creating a new formalism in the first place.

(That code is actually not the latest, it's just the last "rewrote it, now it looks right" snapshot, and is much simpler.)

Luke Gorrie - Re: Editors, Ahoy!  blueArrow
11/6/2003; 6:36:56 AM (reads: 356, responses: 0)
Hey, I just found some code in the Linux iproute userspace-kernel communication program that LtU readers might find cute:

int store_nlmsg(struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
        struct nlmsg_list **linfo = (struct nlmsg_list**)arg;
        struct nlmsg_list *h;
        struct nlmsg_list **lp;
        h = malloc(n->nlmsg_len+sizeof(void*));
        if (h == NULL)
                return -1;
        memcpy(&h->h, n, n->nlmsg_len);
        h->next = NULL;
        for (lp = linfo; *lp; lp = &(*lp)->next) /* NOTHING */;
        *lp = h;
        ll_remember_index(who, n, NULL);
        return 0;
        if (rtnl_dump_filter(&rth, store_nlmsg, &linfo, NULL, NULL) < 0) {
                fprintf(stderr, "Dump terminated\n");
Blur your eyes a bit to ignore the details, and hey presto! It's fold with a list accumulator! Made my day. :-)

Karl Reitschuster - Re: Editors, Ahoy!  blueArrow
11/6/2003; 7:13:10 AM (reads: 340, responses: 1)
Hi this C-Code Example shows really what C is ( C++ too ) : a higlevel assembler even with oo-extensions ( C++ )


Dan Shappir - Re: Editors, Ahoy!  blueArrow
11/6/2003; 8:32:09 AM (reads: 330, responses: 0)
I definitely agree with this sentiment with regard to C. Some might even say this is an intentional part of C's design.

Not sure I would agree with regard to modern C++. Combined with STL I think you can come up with a much higher-level implementation of fold. Not that it would match Haskell, but still ...

Karl Reitschuster - Re: Editors, Ahoy!  blueArrow
11/6/2003; 11:43:40 AM (reads: 290, responses: 0)
Hi, a simple answer i can give you ... C++ inherited from C, so it's still a highlevel assembler, but with better techniques to hide this :-)