Lambda the Ultimate

Why do we need the finally clause in exception handling pattern? I never understood why would one need it... or, rather, I was always able to code everything without using the finally block.

function f (file_handle h) {
  try {
    // do something dangerous
    h.read;
  }
  catch (e) {
    //catch the exception and do something
    print_err ("Can't read file " + h.name);
  }
  h.close;
}

Why and in what situations does one need the finally clause? I hope that this question does not sound too stupid, as I believe that a lot of people are perfectly accomodated to using the try...catch...finally pattern, but I really never understood it... sorry :)

Patents are supposed to be formal specifications of inventions that contain enough information for someone reasonably skilled in the art to reproduce the invention. I'm curious as to whether anyone is working on automating patent comparisons for the purpose of establishing violations. My shallow understanding is that proving systems might have something to contribute to that problem, or at least a significant enough subset of it - at least for "software patents".

Having such a system might be a good weapon against big firms that file suits that take ages to verify and primarily serve to feed the pockets of lawyers (apologies for the cynicism there).

Hi all,

I noticed a similarity between semaphores and other thread-synchronization mechanisms, and control dominators (from control flow theory).

A control dominator is a node that controls the control paths that go through it. Basically, in a control flow graph, if node B post-dominates node A, any path from A to the end-node *must* go through B.

In a similar way, a semaphore guarantees that any path from the wait() call to the end of the execution, *must* go through the signal() call. This feels like "runtime" post-dominance, which is of course a very informal way of putting it.

Does anybody know if there is more research about this similarity? Can dominance be generalized to a runtime concept? Can it help us understand thread-based concurrency better, or is that a lost cause in advance?

Attempto Controlled English (ACE)

Though formal methods promise improved quality of software and partial automation of the software development process they are not readily accepted by domain specialists. This applies particularly to formal specifications that are at the very basis of any formal software development. The reasons are twofold -- formal specifications are hard to understand and difficult to relate to the concepts of the application domain. ...

In brief, an ACE specification is formal and at the same time "explains what the specification means in real-world terms and why the specification says what it does".

I'm trying to learn lisp. I've been reading some of Paul Graham's stuff and he has convinced me of its coolness :) So anyway, I'm totally lost. I'm using gcl (Gnu Common Lisp) under Gentoo. I tried to get sbcl and cmucl but they didn't compile. My basic issue is simple - how do I make a binary executable with gcl? My test program is just this.

(format t "hello lisp")

This file is called 'hw.lisp', I've managed to create an object file but do not know how to link it to make a binary. I'm just doing this in the interactive gcl session

(COMPILE-FILE "hw.lisp")

Now that gives me the 'hw.o' file but how to link it? Or is there a way to just go straight to the executable? I've looked online but the gcl docs are rather sparse.

As a LtU junkie, I've learnt a lot from the discussions that LtU editors bring up and I've been hacking away trying to implement some "fairly modern" concepts in a scheme-based open-source scripting language muSE. The latest hacks are in the processes branch and include the following -

• Erlang-style message passing processes
• Concurrency management using (atomic ...) blocks
• Resumable exception mechanism
• Exception handler choice using argument pattern matching
• Support for guards in patterns

Some basic description of this stuff is available from the muSE blog page. This is public code that's there for anyone interested in exploring lisp-based expressions of such functionality. Comments, suggestions, questions, brick bats, rotten eggs, all are welcome.

Notes: You'll need MS VC++ Express edition in order to build a muSE interpreter. "Solution" files are available from the above mentioned branch. Currently only MS Windows+Intel combination is supported [.. ducking to avoid laser beams! ..]

This is a beginner question. In the books I've seen so far (e.g. "Principles of Program Analysis" Nielson&Nielson) simple dataflow analyses are explained. But the more practical/precise applications using DFA are using one which is path-sensitive (SLAM,ESP,etc.).
How do you make a DFA path-sensitive? Do you know any good papers/books which cover this topic?

Thanks.

I'm starting grad school in computer science next year and I'm hoping to focus on languages. Needless to say, LtU is a daily favorite. The contributors here have introduced me to many interesting papers and discussions.

I'm curious to hear from people who are working in the field, going to conferences, etc... What are some active areas in language research today? What do you think are the most exciting recent developments?

What about visual programming? Multi-paradigm programming (or programming 'paradigms' period)? Compiler design and optimization? Language support for concurrency? Formalisms for computation, translation, type-systems...

I hope this isn't too intense. Thanks in advance.

I thought folks might be interested to see that lambda expressions are coming to Visual Basic .NET.

http://www.panopticoncentral.net/archive/2006/12/08/18587.aspx

There's an interesting discussion going on concerning the proposed syntax.

This has just crossed my mind:

Functional APIs and imperative ones often differ in the way that functional ones make use of function-passing as a way to manipulate data. For example, in Haskell, there's filter:

 filter :: (a -> Bool) -> [a] -> [a] 

Used like this:

 filter somecondition oldlist 

For lists, this can be simulated in say, Java by using:

ListIterator<E> it = list.listIterator();
while(it.hasNext()) {
  if(!somecondition(it.next())) {
    it.remove();
  }
}

While it is possible to implement this and other operations on lists equally fast, it doesn't seem to be the case for maps. Consider the following task:
You have a map from strings to int. You get a string "str" and an int "n". If the value at the position "str" is smaller than "n", you delete it, otherwise you overwrite it with "n" plus the old value(if there was no entry, the old one is assumed 0). In Haskell I would implement this using alter:

 alter :: (Maybe a -> Maybe a) -> k -> Map k a -> Map k a 

In this case:

alter (\x -> case x of
             Just v  -> if v < n
                        then Nothing
                        else Just (v+n)
             Nothing -> Just n) str oldmap 

This traverses the tree exactly once, while my Java implementation

Integer value = map.get(str);
if(value==null) {
  map.put(str,n);
}
else {
  if(value<n) {
    map.remove(str);
  }
  else {
    map.put(str,n+value);
  }
}

traverses the map twice(once for retrieval, once for insertion/deletion).
Is this (or equivalent performance issues) relevant for API design? Can every such problem be solved using iterators?