I have a language I would like to prototype in Haskell. It's a 'language-oriented' programming language based on Lisp, ML, and a touch of Python. It's a relatively small language, but should be powerful enough to have many of its features implemented in terms of itself (classes, actors, almost all syntax, etc.)

While the project is compensated, I'm just a commercial game programmer by day and don't have a corporate budget, so part of the motivation is the joy of the project itself. Otherwise, I have a budget of $4 - $6k USD over the next several months to compensate someone to hack it up for me. I don't have much in the way of specs, and the design is ongoing (almost certainly some holes), but there is some hint as to the design here - http://channel9.msdn.com/Forums/Coffeehouse/Prototyping-New-Language-With-Haskell

I really want to churn it out as a nice working concept to prove the language design and language oriented programming is practical even for soft-real time software like console games. The project will be open source throughout its development and the language will be free to use. I really want it to take off, despite my meager resources The great thing about using Haskell (beyond the obvious) is that it compiles down to LLVM can theoretically be deployed anywhere LLVM can (including specifically MSIL with a .NET-specific FFI).

Beyond that, I'm looking for charitable investors once the prototype is finished and proven. I want to find other people are so sick of writing soft-real time software in C-family languages at their work place that it's worth the donation. Perhaps there is some company who might be interested in further incubating the project if it proves commercially interesting

I do ask for the code to be reasonably clean as I would like to be able to help once I get some time. I would be implementing the thing fully myself, but I am way too swamped at work Since I have to rest my hands during my off hours, I would like to do most communication by voice.

If anyone is interested and has the credentials to bring the project to fruition, please contact me at bryanedds@yahoo.com straight away.

Just wanted to bump as the design has changed quite a bit (see first post). Sadly, I've been super busy with work, so the implementation is going very, very slow. Finally, I've been trying to think of a new name, but nothing seems to stand out except for names that have already been taken by other languages. Maybe something named after a gem stone. Gem stones are pretty.

Another reply to Ryan B - perhaps the sexp syntax should be hidden from the user by enabling meta: mode by default.

Overall, I get this feeling that there is so much great synergy between static and dynamic typing that new languages should be exploring it. Nothing more painful than being trapped strictly in just one or the other.

The name 'sexp': This is a common shorthand name for the concept of 'symbolic expressions'. Same with mexp which is short for meta-expressions. So, I don't know how I would change that. I could give it a friendler name in the language documentation, but it might just cause confusion for existing functional programmers.

The point of sexps: An s-expression syntax is necessary for comfortably implementing good internal DSLs using real macros. When it comes to the language-orientation pradigm, C-style syntax is inadequate (at least for internal DSLs). For this reason, I fear that C-style languages are an evolutionary dead end.

The point of mexps in addition to sexps: Mexps are much visually superior (at least in the eyes of C-style programmers like myself) to the sexp syntax. So the two syntaxes are both quite necessary. Again, with the meta(expr) function, you can force code to use only the mexp syntax, so it shouldn't be confusing.

The reason I believe C-style programmers will consider using the language is because it looks very similar to Python or Ruby. Many C-style programmers love Python or Ruby and their biggest reason for not using Lisp is the parens of its pure sexp syntax. I think the language I'm designing is right up C-style programmer's alleys because it's -

Static for near-C run-time performance

Static for beyond-C safety

Visually appealling (for the many C'ers that like Python or Ruby)

Many, many times more powerful than C or its derivatives due to real macros and optional dynamic typing and evaluation.

But again, because C-style languages can't comfortably do real macros, I fear they are a dead end. When (or if) C-style programmers come to believe this as I do, I hope they will consider this language as an alternative.

As to it turning into the next big thing - well, perhaps if I got some support or funding (and the idea actually proves to be sane) I could make it happen. Without it, I'm not sure if it could be much more than a potentially interesting toy.

The Feather Programming Language is a 'language-oriented' programming language. It is intended to expose a blend of imperative, functional, object-oriented, and language-oriented programming paradigms in one simple, machine-efficient and general purpose language. It is a static language with a Hindley-Milner type-inferencing algorithm, but has optional dynamic resolution using H-M inferencing as well (perhaps using staged compilation as referenced in the post later in this thread). The 'language orientation' paradigm is what makes the optional dynamic binding so important. Run-time semantics-wise, it's quite similar with Common Lisp and Scheme. Feather has two syntaxes - sexp and mexp, with the latter being used by default and being translated to sexp for macro processing. Sexp syntax is available only in the symbolic context (mentioned later). Macro processing is what makes the direct translation to sexp so important.

Here's the meta syntax that maps one-to-one sexp syntax. It is column-sensitive as well as newline-sensitive. The column sensitivity is what makes the command: syntax work without need a special end-scope operator. Meta syntax is transformed to sexp syntax before macro processing. This code is the mexp mirror of the sexp code above, and you can deduce the mapping mechanics yourself -

Note that the translation from mexp to sexp is purely syntactic, but some semantic checking must take place after the transformation using a map from the sexp back to the mexp. An example of semantic check that must be done is that the method.call(syntax) is used on method calls or method signatures only (and only said syntax is used).

----

All symbol resolution in the lexical scope of 'static' will be resolved statically (that is, when the code is compiled). All resolution in the 'dynamic' scope will be resolved dynamically (that is, when the code is executed). The default scope when none is specified is 'static'. Static typing is not only intended for safety, but also forcing as many possible program decisions to compile time where possible in order to achieve maximum run-time efficiency.

define: x -> 10.0 // define x as a Float of value 10. binding is scoped. A define of the same symbol never changes the underlying symbol, but shadows it instead.
define: fn(x) ' expression // define a function
define: c.md(x) ' expression // define a method. A single context variable is required
define: co: x y; ' expression // define a command like the let and if commands
define: x bi y p a ' expression // define a binary operator like + and - with p precedence with a associativity. Precedence is part of a binop's type, and should probably be some sort of fractional number
define: le x ' expression // define a left operator
define: x ri ' expression // define a right operator... not sure how this would be used :)
define: c.prop ' get x ' set x := value // define property
lambda... // create a lambda. Callable as a function only
methlambda... // create a methlambda. like lambda, but used to pass methods. callable as a method only
comlambda... // create a comlambda. like lambda, but used to pass commands. callable as a command only
bilambda... // create a bilambda. like lambda, but used to pass binops. callable as a binop only
leflambda... // create a leflambda. like lambda, but used to pass leftops. callable as a leftop only
rilambda... // create a rilambda. like lambda, but used to pass rightops. callable as a rightop only
proplambda... // create a proplambda. callable as a property only
let: x -> 7 ' expression // define a value over an expression. values cannot be set.
let: x -> var 7 ' expression // define a variable over an expression. variables can be set
let: [x -> 7, y -> var 5] ' expression // define multiple items over an expression. sequential like lisp let*
macro: y -> 5 // macro expands to expression
macro... // define a scheme-style hygienic macro. Invoked like a function.
macro... // like a macro, but invoked like a method
macro... // like a macro, but invoked like a command
macro... // like a macro, but invoked like a binop
macro... // like a macro, but invoked like a leftop
macro... // like a macro, but invoked like a rightop
macro... // like a macro, but invoked like a property
[functional types]
synonym... // like Haskell type
derivative... // like Haskell newtype
typeConstructor... // like Haskell data
typeClass... // like Haskell class
typeInstance... // like Haskell instance
[object system - could be done after the prototype]
class... // class like in CLOS, but without the generality of a MOP. Ideally implemented as a library.
[agent system - could be done after the prototype]
agent... // agents are like arbitrarily parallelizable objects
lazy x // marks a parameter (here x) as lazy-evaluated. This is a nice, simple substitute for some macros. A leftop.

meta: expressions // specifies the enclosed expressions may not use '{' or '}' sexp symbols. Prevents the two syntaxes from being used together unnecessarily. Functions may only be called with the x.y(z) notation and commands can only be called with the x: y notation (and so on for the operators).

pretty: expressions // disallows arbitrary white spacing / formatting so that all code looks roughly the same no matter the author.

` is quote, ' is unquote, and $' is dollarQuote (like lisp at-quote).

...rest // the rest parameters with name rest

import:> // very similar to Haskell's import, but much simpler and less error prone

Module.thing // qualifies thing with module name. If . is ambiguous, we could use Module/thing instead.

/// <Summary>Documentation comments are done almost exactly the same as in C#, except you can aim a comment from one place to a program element in another using a <Target> tag.</Summary>

RULE: all expressions should be readable from left to right and top to bottom (with some exceptions like f & g).

RULE: you can run any pure code at compile-time (define: for example is pure as it can never side-effect since it shadows).

RULE: there are 3 types of function purity – pure, impure, and dependent. Only higher order functions can be dependent. A dependent function resolves to pure or impure depending on how it is invoked. If one or more of its incoming functors is impure, it becomes impure. Otherwise, its purity depends on whether it calls other impure functions.

RULE: immutability always cascades down with recursive structures. You cannot have an immutable variable that is bound to a mutable list or an immutable list of mutable lists.

RULE: Feather is a single namespace language with lexical scoping. No special symbol affixation is needed to pass a function - just mention it by name.

RULE: nearly all functions must come from a module to be used, including operators on primitive types. This allows DSLs to avoid exposing operations that are not useful.

RULE: the only time you need to qualify a name with the module is when it collides with another imported name.

RULE: each implementation of Feather must have a self-compatible binary representation of all its objects. This allows entire object trees to be burned to disk (or ROM) and be reified directly back into memory to avoid the need for a serialization process, reflection-based or otherwise.

RULE: operator precedence and associativity is the same as in C, but the flawed associativety of .& and .' will be fixed up.

RULE: since this author despises noise in code, the compiler will warn about superfluous parenthesis / brackets, and give an error in pretty mode. Same for tabbed out // with no matching tabbed out // on adjacent lines.

RULE: Like python and its recommended 'pythonic' style philosophy, there is a similar recommended philosophy in Feather. In Feather, there is always a single best way to do any one thing, and it should be obvious. This won't always be achievable, but is a good language goal.

----

So, anyways, that's the design so far. I ultimately hope I can get C-style programmers to consider using it. If anyone see any big holes in it or has any feedback, please discuss it here.

----

Another immediate question I have as a language implementer is, how do most language implementers fund their projects? I will be developing this language slowly over time, but I'd like to find some way to move it forward faster. Are there any companies out there that are interested in this type of project? If this language makes as much sense as I think it does, it might be timed just right to serve the growing interest in efficient, object-oriented, functional and 'language oriented' programming.

Is there any such formalization of the process of abstraction? You know, in the same way there is a formalization of lambda calculation via the lambda calculus?

If not, couldn't there be?

It's one thing to understand a program, another thing to abstract, another thing still to understand and reason about the process of abstracting during program development. If there were an 'abstraction' calculus, maybe it would be easier to teach engineers about abstraction as well as when and how to do it?