Lambda the Ultimate

Aggressive Type Inference

In talking with people at last year's Python Conference (IPC7), I mentioned the possibility of writing a Python compiler... in Python. Not content to stop there, I suggested that the idea could be taken further, to translate Python code into Perl.
[...]
What does this have to do with type inference? The translated Perl code must have the $@%&* type specifiers on all Perl variables.

Can we look at this as a constructive proof that funny characters are (mostly) not needed by compiler, and are there only to please the programmers?

I decided against posting this in the thread that mentioned ugly syntax (not of Python), as it was pretty long and losing focus already.

Hello and sorry if this question has been already answered somewhere, though i searched for it.

The question is: tail-recursion is something badly needed _only_ in Scheme?

Here's a related question: if it isn't, that is, if it's possible to generally get compilers or interpreters to correctly detect recursion and automatically apply and implicit goto to it, then why should i bother, when it just complicates matters?

I gave a though to it when a saw a recent post here about LLVM and its recent support for tail-call for Scheme and also for playing with Haskell a bit.

So, to keep things simple, let's look at the examples:

;; in Scheme
(define (fact n)
  (define (product min max)
    (if (= min n)
	max
	(product (+ 1 min)
		 (* min max))))
  (product 1 n))

That's one way to look at a factorial, but not the _natural_, i guess.

-- in Haskell
-- and just to add a bit more argument
dec n = n - 1

fact 0 = 1
fact n = fact( dec n ) * n

That's the _natural_, let's call it that, high-school definition for factorial, pristine clear. There's no tail-call anywhere to be seen, and yet, it doesn't cause stack overflow with large numbers...

Am i missing something? or is Scheme being stubborn? R6RS is coming and perhaps should address it?

Sorry for being provocative, but it's a sincere question...

Hi,

Is anyone aware of any systems which use AST intermediate representations instead of byte code? A few years ago, I read papers by Michael Franz concerning use of compressed ASTs in the Oberon system (e.g. A Tree Based Alternative to Java Byte Codes - pdf). Work on AST intermediate representations seems to have continued particularly in relation to mobile code (e.g. Towards Language-Agnostic Mobile Code - pdf).

Typically the AST intermediate representation of a program is compiled at the destination on the fly (with varying degrees of optimisation depending on time constraints). I'm interested in interpreting ASTs to see what the performance of AST interpretation is like as a first step (possibly with a subset of Oz). So far I've only found one attempt at anything like this.

Just wondering if LtU readers had come across any other work on AST representations and interpretation.

Regards,
Chris

Hi All,

This is a quick note to say that LLVM 1.5 is out, with many new features above and beyond LLVM 1.4. Perhaps the biggest feature of interest to this community is full support for proper tail calls, as described in the release notes. More details about the release can be found in the release notes and in the two status updates [1,2] since 1.4.

For those not familiar with LLVM, it is a compiler system that can be used to build a wide variety of compiler and language systems. It provides language- and target-independent tools for building static compilers, interprocedural optimizers, JITs, etc. If you are working on a new language and need a code generator, you should check it out. LLVM can be used in two ways: 1) link to the libraries we provide for direct access to the APIs. or 2) emit the LLVM IR as a text file. People have even written (toy) languages in perl using the second technique.

-Chris

Slow day, so from yet another odd corner of cyberspace: the Cyc system which, well, ahum, from the site:

The Cyc Knowledge Server is a very large, multi-contextual knowledge base and inference engine developed by Cycorp. Cycorp's goal is to break the "software brittleness bottleneck" once and for all by constructing a foundation of basic "common sense" knowledge--a semantic substratum of terms, rules, and relations--that will enable a variety of knowledge-intensive products and services. Cyc is intended to provide a "deep" layer of understanding that can be used by other programs to make them more flexible.

The system also comes with a language named

CycL which is "essentially an augmentation of first-order predicate calculus (FOPC), with extensions to handle equality, default reasoning, skolemization, and some second-order features."

No idea really what to think about it, CycL seems to have Lisp roots, predecessor of the semantic web or Peircian semeiotics based Wikipedia?

This article might be of interest.

From a language design perspective, this was interesting (emphasis mine):

Most noticeably for anyone reading code in the new syntax, the common double-underscore keywords prevalent in Managed Extensions for defining garbage-collected classes, properties, and so on, are a thing of the past. While a few of these keywords remain and a few more are being introduced, they are infrequently used and won't muddy up the readability of the code. These double-underscore keywords are being replaced with two new types of keywords: context-sensitive and spaced. Context-sensitive keywords are only keywords when used in certain contexts, and spaced keywords are only keywords when used in combination with other keywords. For example, the __property keyword from Managed Extensions is replaced with the property keyword. (Not only that, but the entire syntax for defining a property and its accessors has been dramatically refined, making the declaration look very similar to what you might write in C#. See Figure 1 for an example.) This doesn't prevent you from using "property" as the name of a variable in your code. A token parsed as "property" is only treated as a keyword when in the context of declaring a property on a type.

Curious if many other languages do that with keywords, and if it ends up being a cure worse than the disease...

Are there any resources online for someone looking to learn about logic..specifically as it relates to recent papers in PLT involving proof carrying code, typed assembly language, etc.? What are good printed books? (should be basic introduction). I couldn't find anything other than Jean H. Gallier's 'Logic for Computer Science.' at http://www.cis.upenn.edu/~jean/gbooks/logic.html

Thanks.

This website claim: "Qi has the most powerful type theory of any language that will ever be invented."

Frankly I don't understand the first thing in this write-up but I'm sure others will find it interesting.

Also, I read somewhere that while Lisp reflects programming language theory of old, Haskell represents PLT thinking of the 90s (poorly paraphrased from memory). I've always assumed Haskell's type system and pattern matching are what's supposed to be '90s thinking,' so where does that put Qi?

n/a

Hi,

my name is Norman, im currently doing a research on cobol,

the topic is "Is COBOL dead or is it still useful?"

im totally new and dont know anything about cobol, currently, the only thing I know is that it is a programming language for bussiness.

Can someone tell me what is the problem with COBOL? why does some people thinks its dead and if its still useful in what area?

or if some of you can find me some useful links please let me know..

thanks very much,