archives

The Pooh language / Learnable programming in action

I would like to present my project; it might be interesting in light of the 'Learnable programming' discussion. The Pooh language lives here It has the following features:
  • Does not force to introduce OO concepts from the start; non strict OO viewpoint.
  • Makes flow visible by tracing of the program flow; the -x command line option instructs the interpreter to trace each statement and evaluation results + intermediate values.
  • A focus on readability and clarity in syntax and semantics
    • no statement delimiters - no semicolons
    • all function parameters are passed as named parameters;
    • all variables declared in function are local;
  • Variable must be defined before use, similar to strict mode in Perl; variable is defined if value is assigned to a name.
  • The language has closures and can do objects by prototyping; has higher order functions like map/fold/filter .
  • If a non local variable is referenced, then it must have the prefix outer . ; references to global variables from a function must have prefix global . ; object member references must have prefix this .
  • the Pooh language has green threads / co-routines / generators like Lua; so there are nice for loops like in Python. The local variety of this idea is called Pooh routine.
Thank you for your attention.

Dependencies as first class entities

When thinking about what pains are worst when writing code, it seems like it all boils down to dependencies. Even as a user, the problem seems to be the same. Ehrm, correction, as a user I get frequently insanely mad at dependency problems. As a programmer, it is more of the moaning kind.

My first thought was to do a better make language, since this was where most of my pains were. Then I realized, it is bigger than this. Just building the thing isn't all there is, installing it, remember what was installed and why, be able to remove some of it that seems to be in the way, and so on. Not to mention configuration problems. Now, why was that configuration set in that way, who depends on it? What would happen if I changed it? Sometimes I don't even know how to find the answers.

My current thought is to deal with this once and for all. Let's make dependencies a first class entity in the programming language, make it externally visible and then watch what would happen.

The questions I haven't been able to figure out any answers to yet are:

  1. How should this be implemented?
  2. What could this achieve?

Has anyone been there before me, as usual, and written some vice word on the subject?

Anyone having similar ideas?

Fixpoint theory, induction and recursion

I have always looked at recursion very pragmatically. A well formed recursive function is a function which calls itself during its execution. In order to avoid infinite loops, some of its arguments have to be constantly decreasing on each recursive call and there has to be a branch where no recursive calls are made.

Certainly in theoretic computer science fixpoints are introduced and from a mathematical point of view a recursive function is the solution of a fixpoint equation. But diving into the subject deeper there are a lot of interesting aspects in this connection between recursive functions and fixpoints. There is a connection to closures, to induction etc.

I have tried to write down some of these interesting aspects into the little paper Closures and fixpoints. All needed math is expressed within a programming language in a manner that the compiler can verify all derived facts. Maybe some of you are interesting in reading this.