Lambda the Ultimate

I have been reading up on row/record polymorphism (thanks to Andreas and Daniel for the pointers), but so far I haven't seen anything which apply the concept of a row variable to tuples.

If I understand my theory correctly, record types without labels are in fact tuples (or product types if you prefer). So if you have a row without labels, what would that be? An "unlabeled row"?

Viewed from another angle, I want to describe tuples with row variables. The nitty gritty of the whole thing is that I am working on devising an acceptable way to describe stack configurations using type theory.

A stack with an integer on top, and anything else on the bottom can be described as:

  T = int * A 

where A is the "unlabelled row variable". Perhaps these are examples of "stack types" or I could call them "column types" to distinguish them from rows?

Any ideas or suggestions would be much appreciated!

I am trying to understand continuations (yes, one more!).

I found the Javascript example proposed here quite helpful in understanding the basic idea.

Let me describe it that way:

Imagine that I am a bug in one of these old relay computers of the past. Bulbs are buzzing, relays are snapping all around. Being a curious animal, I decide to follow the noises to understand.

There is the operator, one of these funny animals with rags and the eyes forward facing. He is-- or is it a she?-- feeding some paper-like thing punched with holes (the program) in the machine and adjusting some switches (the data). Before he came in, the place was quiet and silent. That was the entry point of the program.

Then the machine started coming to life, relays activating in succession, bulbs blocking or passing the signal. That was the executed part of the program.

At the moment a relay just changed state; that is the Now.

Following the relays being activated, I can see that there is still more to come. The punched card still has more holes to be read, more relays need to be triggered. That is the program to be executed.

When all the punched card is consumed, some lights will come up in front of the operator, or some printing device will print an output: the result of the program.

The continuation is like putting the Now in a bottle.

If I was sitting at the wrong place, a relay may malfunction, a 1 become a 0, and the result would be different-- that is a different instance of the same continuation.

Another explanation is that a continuation is like the Replay function of an arcade game that I used to play. The game would replay everything I did during the last game. Then I could stop at one point, and take the game over from that point.

Of course continuations are used for a single function, not for a whole program like the punched card description. The entry point is the function call, and the data is the arguments of the function. Invoking the continuation is like replaying in fast forward the past execution of the function till the continuation point (the Now in a bottle) then injecting some new arguments to be used in the rest of the function to be executed.

For the program to stay coherent, the new arguments should not be used before the continuation point. It is also interesting to note that when the function terminates, the result is available to the program that invoked the continuation-- it is not returned to the original invoker of the function.

There remain some questions:

• If the above is correct, how is it different from simply invoking the function again with slightly different arguments? (supposing no side effects)
• How do you determine at which point in the call stack the entry point is, is it necessarily the current function? That will determine how much of the current state needs to be stored
• Why is it called continuation and not replay?

how convert state macine to petri net?

This is an admittedly rather vague idea that has occurred to me a few times - I'm wondering if anyone has had the same idea, or been able to formalize it in an interesting way.

I'm wondering if it would be possible to have a purely functional language, like Haskell, in which 'everything is an abstract data type'. There are no concrete data types in the language itself, everything is dealt with in an abstract / categorical / 'up to isomorphism' kind of way.

Data types would be chosen just to reflect what the data logically is, without concern for the physical representation or the performance characteristics of the algorithms involved. So a list of pairs, a hash-table and a function would all be of type Map. (or (Map a) => a, to borrow Haskell's typeclass notation)

The compiler, then, could chose which concrete implementation to use, say for a list or a map, based on any kind of compile-time or runtime optimizations it feels like. It can also apply lots of highly abstract categorically-based rewrite rules before it even gets to that stage.

Is this idea fatally flawed (I fear it might be, but I can't quite figure out how), or has anyone done anything similar?

(I looked but didn't see any other references to this on LtU)

There is now a Haskell -> Javascript converter using the York Haskell Compiler's (YHC's) "core" format.

From the YHC Core page:

Yhc.Core is a simple core Haskell-like language, feature case statements, let statements, top level lambda's and data values. Much of the syntactic sugar present in Haskell has gone (list comprehensions, typeclasses, overloaded names, nested lambdas)

The strengths of Yhc.Core are:

* Simple representation of Haskell
* Relatively simple to relate Core to original Haskell
* Source locations are preseved
* Minimal name mangling
* Few syntactic forms

The weaknesses are:

* Yhc cannot compile Yhc Core files, format is write only (fix is being worked on)
* Types are not present (hard to fix, a lot of work)

Chris Oliver has been blogging about F3, a soon-to-be-open-sourced functional programming framework for Java. It's statically typed, comes with an Eclipse plugin, and does some pretty cool dataflow/dependency management. It reminds me of SuperGlue, from McDirmid and Hsieh.

I've got two tuples

  Ta = (a0, a1, ..., aM)
  Tb = (a0, a1, ..., aN)

With the subtyping relationship

  Ta <: Tb

I am interested in referring to the type difference, and I was thinking of notating it as:

  Ta \ Tb = (aM, aM+1, ..., aN)

Is there a standardized notation or language for referring to such a concept?

ok so im trying to creat a ai program. I have read Prolog is great for this. Im scared maybe Prolog is limited, I need to talk to someone that knows Prolog and ask him/her a few questions about Prologs limitations. What do you guys think I should use, Prolog or C++? Thanks

When I encountered discussions about OO vs FP on LtU the first time my immediate response was that FP likely doesn't lack anything technology-wise but something essentially different: a discourse about modeling and design that is devoid of implementation or PL feature considerations but mostly strategic. A strategic approach is for instance object oriented analysis and design: start with a decomposition of a system into objects. Identify their responsibilities and relationships ( modularization / class diagrams ), their behaviour and interactions ( methods ) and their properties ( member variables ). The choice of a projects programming language is than influenced by its attitude to embrace the design/modeling strategy and not by other considerations that are secondary to this process: whether it favours recursion over iteration or enables the compiler to safely exploit cute little identities among combinators granted by referential transparency.

There has been a funny polemics by Steve Yegge some time ago about Java as the kingdom of nouns that caricatures the obsession of subordinating verbs ( functions ) under nouns ( objects ). The only immediate inversion of this subordination I'm aware of is that of category theory but I didn't notice yet a push of "general abstract nonsense" into a handy toolset that guides the programmer from customer requirements to program code. At the moment FP is advocated in terms of compensations or vagueries. It improves your quality as a programmer even when you write code in Java or C++ and it is "mind expanding" ( whatever this means ) or it is praised as the future of programming because once again it simplifies the life of compiler authors to deal with parallelism. It's always hard to distiguish hope from defiancy.

What do you think, are there approaches to transcend the current state by envisioning a new "big picture" or am I'm just wrong in my analysis and so deeply brainwashed by my education that I overlooked the obvious and eternal truth? In the latter case I would be grateful about a "mind expansion".

I was wondering how something like duck typing might work in C# or Java (there are other strict languages which do support duck typing, O'Caml for instance). Seems like you would have to have lots of interfaces and then list them when implementing them. Basically every public method would have an interface describing it, and then each class would laboriously list all those interfaces.

Actually it all falls apart because I don't think one can say a method takes a set of interfaces for a single parameter. You would have to automatically generate the combinatorical set of interface mixins, and use those in the method signitures.

(Just musing over the range of things one could - not particularly want to - do with the way Java/C# are already defined.)