LtU Forum

(Alice ML + monads - value cells) > Haskell?

Would a Alice-like language without value cells but with monadic state have any advantages over Haskell?

It seems that Alice's combination of strict, lazy, and lenient evaluation, coupled with transparent futures would make it more powerful than plain Haskell.

Thanks.

Type Theories

Hi,

I have a question: what're the benefits of investigating type theories when designing new programming construct/model/paradigm? I read through some of the recent interesting papers posts on LtU. Always, the authors dedicate a section to formalize their new programming constructs under various lambda calculi. I'm asking this from the perspective that how does this help us in designing better programming languages? What kind of insights will such process of formalisation give us?

I'm genuinely interested in understanding this. I've been considering of doing a PhD in investigating better programming constructs. I can say I know untyped lambda calculus. Beyond that, I'm not particular strong in "deeper" type theories and other formal systems (e.g. denotational semantics). I'm wondering how a PhD thesis will stand up if it isn't strong in this aspect.

If I want to brush up my skills/knowledge in this area, I suppose the text "Types and Programming Languages"
by Benjamin C. Pierce will be my starting point? Any other suggestions?
--
John

Metaobject protocols: Why we want them and what else they can do

Metaobject protocols: Why we want them and what else they can do

Traditionally, languages have been designed to be viewed as black box abstractions; end programmers have no control overthe semantics or implementation of these abstractions. The CLOS MOP on the other hand, "opens up" the CLOS abstraction, and its implementation to the programmer. The programmer can, for example, adjust aspects of the implementation strategy such as instance representation, or aspects of the language semantics such as multiple inheritance behavior. The design of the CLOS MOP is such that this opening up does not expose the programmer to arbitrary details of the implementation, nor does it tie the implementor's hand unnecessarily -- only the essential structure of the implementation is exposed.

In more recent work, we have pushed the metaobject protocol idea in new directions, and we now believe that idea is not limited to its specific incarnation in CLOS, or to object-oriented languages, or to languages with a large runtime, or even to Lisp-like languages. Instead, we believe that providing an open implementation can be advantageous in a wide range of high-level languages and that metaobject protocol technology is a powerful tool for providing that power to the programmer.

Computing Kazhdan-Lusztig-Vogan Polynomials for E8

This is not a PLT paper, but I found the programming adventures of mathematicians trying to compute the Kazhdan-Lusztig polynomials for E8 very interesting: The Character Table for E8 by David Vogan. The software part begins on page 9.

I wish he had expanded on the following (emphasis mine in bold):

So late in 2004, Fokko began to add to his software an implementation of the Kazhdan-Lusztig algorithm for real groups. The papers in which this algorithm is formulated are extremely dense, and written with no consideration for computational practice. An expert could easily spend many months just to understand the mathematical statements. Fortunately, Jeff Adams had been working on a new formulation of Theorem 6 (parametrizing irreducible representations), growing out of earlier work that he did with Dan Barbasch and me. Jeff's formulation seemed suited to computer implementation; he had been working with Fokko to make it more so.

Over the course of the next year, Fokko understood the Kazhdan-Lusztig algorithm for real groups, recasting it in the language that he and Jeff had developed. He wrote clear and efficient code to implement it. In November of 2005 --incredibly soon!-- he finished. Very quickly he and Jeff used the software to compute Kazhdan-Lusztig polynomials (and so character tables) for all of the real forms of F4, E6, and E7, and for the non-split form of E8.

LtU beer party - Jerusalem

It turns out thaty both Luke and me are in Jerusalem at the moment (well, I am usually there)! Luke is here until the end of August, and we want to have a little meeting for LtU members and friends.

If you want to join us for drinks and discussion of esoteric languages let me know (please suggest dates, and mention any special food/drinks requirements if you have them).

creating my own programming language

Hello,

I wanted to know where would I start to create my own programming language. I have no idea where to start, any help would be appreciated. I don't know much about how compiler and parser works. So if anyone could point me to a direction like a website/book/online articles to get me started writing my own programming language.

Thank You.

Good real world example on map/reduce/filter

I'm trying to find some good real world usage of map-reduce for a demo.

The target audience would be cluster person so they have enough knowledge on parallel algorithm.

Any good idea?

Unifying functions and functors

I recently came across the PML language, which aims to realize "the great unification between records/structures/modules/objects and functions/functors/methods". Sounds great, but it lead me to wonder exactly why there is a distinction between functions and functors in the first place.

Is this simply because in all current languages, the module language is separate from the term language? Does anyone have any references on functors that might clarify why functions and functors are currently distinct? Given the explanation of categories in the last link, I might hazard that functions are arrows/morphisms mapping objects within a single category, and functors map objects between different categories, ie. functions operate on objects within a category, functors on entire categories.

If that's accurate, then would "the great unification" involve reifying categories/modules at the term level somehow? If not, what does this "great unification" involve? The only reference to "functor" in the PML manual is on page 8:

/\id:a -> b : dependent types are allowed in PML. They are useful to write the type of functors: functions
that handle structures with type in their fields. Here is an example of such a dependant type with a value of
this type:
  type F = /\s:{ type p = [ A[] | B[] ] val q : p } -> s.p
  val f:F s = s.q

Any clarification is much appreciated. :-)

First-class Polymorphism

I've been reading and trying to understand First-class Polymorphism with Type Inference (FCPWI); the "monads as first-class values" example in FCPWI was quite interesting. I was wondering if there were any languages that currently implement first-class polymorphism (FCP), and whether they support type inference.

From my searches, it would seem that MLF supports FCP, though MLF is still in its infancy; higher-rank types seem to have the same expressiveness as FCP, but I'm not certain as I'm still a type newbie. If that equivalency is valid, then the Morrow interpreter qualifies. Anything else?

The system described in FCPWI seems interesting, but I haven't seen it implemented anywhere, so I was just wondering what its limitations are.

Syntactic abstraction? (newbie question)

Hi,

I'm trying to find out about languages/papers which deal with modifying the PL's syntax within itself. For example: incorporating EBNF so it can dynamically extend it's grammar. I'm not sure, but I was wondering if this is covered by the term "syntactic abstraction"?

My background is very much imperative languages, but I've done a fair bit with parsers, and I'm learning some Lisp. My web searches have only yielded "Boo" and S-expression langages so far.

Any help gratefully received.

XML feed