Lambda the Ultimate

It looks like this is going to be an interesting meeting.

The list of speakers is impressive, of course. Alas, not too many presentation titles are available at the moment.

The Semicolon Wars
Brian Hayes

A laypeople's introduction to the world of programming languages from American Scientist. Includes some history, a high-level overview of different programming paradigms, some guesses at which differences make a difference, some Dijkstra, and some cheap shots at zealots.

Regular LtU readers won't find anything new here, but it's a good article, and it's always nice to see something like this for the general reading public.

Why is there still the trend to create languages where most functionality is implemented in some standard-libraries und not in the language itself?

Quite often lots of time and effort are invested to make a language as extensible as possible and to create every feature (even standard datatypes, like arrays, lists etc) in the library and not as part of the languages itself. I think that's really antiquated thinking from the early years of CS where the usual usage patterns of programming languages where not so well known and an extensible language seemed much more powerful. But this has changed a lot: Today most usage patterns are commonly known and while there are lots of them, the total number of those patterns seems quite manageable.

Often it's unneccessary difficult to use those 'library implemented' features. Think of using lists in a language without native list-support (like Java, C++ etc) and compare that to a language with native list-support. It's so much easier and much more readable in the latter.

But why stop with those 'low-level' features? Why not try to build a language with ALL common used features directly in the language: From strings to maps to general graphs. From loops to threading to database-access. From visitor to observer to MVC. A language without much of a 'standard-lib' because it's mostly integrated in the language itself. Instead of inventing Systesm to create DSL why not simply create and integrate all those 'DSLs' in a single language?

Sure, such a language would be less 'cute' than a minimal one. But I suspect we could gain lots of productivity, safeness and performance.

There's been much discussion of Epigram, but I have yet to see much discussion of Applied Type System. There have been a few stories here on LTU, but relatively little discussion. This surprises me as ATS seems quite advanced.

As a relative newcomer to type theory, I'm interested in the relative merits of ATS vs. Epigram vs. any other dependently typed languages that might exist. From my understanding, Epigram is a Pure Type System that seeks to unify types and terms, where ATS distinguishes the statics and dynamics of the language. What benefits and limitations do these approaches have on complexity for both developer and implementor?

Recently I've been working on a language for programming some of the higher-end PIC microcontrollers. These are very resource-constrained machines, but they can be programmed in C; the one I use the most, the PIC18F4520, has only 32 Kbytes of flash program memory and a whopping 1536 bytes of RAM.

The problem is, while C is a semi-decent language (at least compared to PIC assembly), it still sucks for PIC programming. A lot. In order to make any non-trivial program, you need to set up a bunch of the onboard hardware modules which all have low-level access methods, and you need to do a bunch of interrupt programming (pragmas everywhere!) which gets you mired in a mess of low-level details -- did you remember to clear a certain bit in some obscure configuration register?

For most of the PIC programs I write, I actually think about the problem in terms of data flowing between blocks, similar to Simulink. For example, I might envision a program which performs analog to digital conversions and passes those values on to a bank of LEDs as a simple block diagram with two blocks, one for the A/D converter and another for the LED output. If blocks of arbitrary C code are supported and blocks for other hardware modules are added, this concept turns out to be powerful enough to handle almost every PIC program I've written, and without the pain of writing C code for the PIC. For example, here's a fairly simple program in a lisp-like syntax:

;; Define the configuration for the hardware devices
(config-bits
 (a/d :an1)
 (trisb 0)
 (trisd 0))

;; Define a custom block of C code
(defcode-inline inverter (x)
  "(~x)")

;; Connect analog input 1 (an1) to a bank of LEDs (latb)
(-> an1 latb)
;; Another bank of LEDs (latd) will be the bitwise inverse of latb
(-> an1 inverter latd)     ; Equivalent to (-> an1 inverter) (-> inverter latd)

This would be a lot harder to write in C, and I've got a partial implementation of a compiler for this language which is working fairly well, so I think I'm onto something good here.

Unfortunately, there's probably a mess of useful information about these sorts of blocks-and-connections languages, and I don't know any of it. So, better informed people: what do you think of this type of programming language? Are there any practical issues I should know about? And how would I go about typechecking this sort of language? Since type mismatches are likely to be caught by the C compiler and presented as baffling error messages complaining about perplexingly named mangled symbols, some form of static typechecking before the intermediate C code is generated takes on more than a little urgency.