Lambda the Ultimate

I would like to discuss with you my ideas on new programming language for embedded applications, denoted further as e#.

Here I post only the core concept, more details can be found on this link

e# is a tool language that should be suitable for all kind of embedded-related development activities, starting from defining the device architecture and its instruction set, documenting device specifics and finishing with programming the device with a developed application. Instead of allowing the developer to write an arbitrary language constructions and pushing the compiler to made an executable out of it, e# should let a developer (a device vendor) to express the device resources, capabilities and constraints in the language terms. These capabilities and constraints than are applied to the application sources, simulation model and executable image. If any of the constraints are violated the e# builder would produce error, either compilation, simulation or code generation time.
It should retain major assembler’s capability to express application’s logic in terms of processors instructions, where each statement is translated into known number of know instruction of a given CPU/MCU.
The language should allow writing generic libraries for a given architecture operating on common architecture-wide facilities expressed in terms of a lowest subset of ‘abstract device instructions’ declared for the architecture, which then, at application level, are implemented/instantiated for a given MCU.
Shortly e# can be defined as a compilable code generator – at first sources are compiled then they are executed and, as a result of this execution, application code is generated. Compilation should not generate any target device code, it should only verify syntax and generate instructions on how to generate target device code. e# definitely is a high level programming language, however, applications written in it should still be able to use features of a low-level programming language, such as access to all available device resources.
It is believed that the concept could be applicable to RISC, CISC and VLIW architectures, although, the latter one will require more efforts on describing the device.

From http://rubyforge.org/forum/forum.php?forum_id=8551:

"APP Design, Inc. released a pre-alpha code set for the Prelude project. The goal is to enable Ruby programmers to use higher-order functions, monads, infinite lists, and other Haskell features. The project is released under GPL, community participation is more than welcome."

I got to thinking that it would be cool if using a language's builtin tools you could create its array type -- without using its array type. Most language's I've seen have some builtin concept of an array or list. And although some languages give a 'definition' of what a list is -- that defining code won't actually run through the interpreter.

I came up with the following C++ implementation that manages to implement an array type without actually using arrays. Before you cry that it depends on the class layout which isn't guarunteed -- it is when a class is a POD, and in this case the element is public so it is, and even if it wasn't, it's a defacto standard that things are layed out this way and projects like boost.python depend on it, and the point of the example is to show that a language can do it (even if the language is "C++ with small tweak").

template<class T, int n>
class Array : public Array<T, n-1>
{
public:
    T& operator[](int i);
    T tail;
};

template<class T, int n>
T& Array<T, n>::operator[](int i)
{
    // Should be able to just use line below
    // but some compilers (GCC 3.4) are stupid
    // return *(&(Array<T, 1>::mem) + i);

    int& x = Array<T, 1>::tail;
    return *(&x + i);
} 

int main(int argc, char *argv[])
{
    Array<int, 5> x;

    cout << sizeof(Array<int, 5>) << endl; // 20 as expected

    x[0] = 9;
    x[1] = 8;
    x[2] = 4;
    x[3] = 2;
    x[4] = 5;

    // Prints correctly
    cout << x[0] << x[1] << x[2] << x[3] << x[4] << endl;

    return 0;
} 

How often do you see recursive inheritance? *grin*

The concatenative language Enchilada only defines two types:

- Expressions that are sequences of operators and lists.
- Lists that are sequences of expressions

(operators are primitive expressions)

One interesting result is that there is no need for an additional integer type.
Another surprising result is that the Cartesian product turns out to be a very powerful operator!

I've recently started a blog to explain some of the details.

I'm pretty sure that I've hit something extra-ordinary but I leave it to Lambda the Ultimate to decide.

Feedback is much appreciated!

From the Meta O'Caml tutorial.

Hygienic quasi-quotation notation for distinguishing different computational stages (that is, the generating vs. the generated code) in a program.

Ignoring O'Caml for now, I have tried with the design of several languages to syntactically distinguish between multiple stages (like C++ does with its template system and macro system), and now I have been asking myself the fundamental question: is that really a good idea?

If a language is pure (or at least side-effects are contained within some construct like monads) can the compiler not simply choose to apply as many stages as desired, using only partial evaluation?

The reason I ask the question is that if I do something like create a subset of the language with a different notation, it just obfuscates things. It seems it would be much easier to provide metaprogramming primitives, and let the compiler's partial evaluation phase try to work out what it can, and do the rest at run-time. This may even solve some thorny type-system problems.

So to sum up: my hypothesis is that I should let people write code, as if types are a first class citizen. The partial-evaluation phase will pre-execute what it can. Any non-resolved type expressions will be evaluated at run-time.

Any thoughts on the subject would be welcome.

Hello all !

I will try this way with a error on a Iseries (AS/400) Is this an error in LUA or ...?

¬string "Lua ML (1):line 83:/aXes/de/lua/sidebar.html"|:4: unexpected
symbol near '{'

Hope you give me an answer !

Lars

I've been having a running discussion with a coworker of mine. He's a big fan of Ruby, while I find its runtime type checking worrisome. His recent response to my concerns about runtime type checking is that in the Java arena people are pushing using unchecked (runtime) exceptions, and that unchecked exceptions are just as unsafe as runtime type checking. In a way I can see his argument, because in Ruby if you misspell a method name it will throw a method not found error, so you could look at Ruby's runtime type checking as simply a source of unchecked exceptions.

But I have this sense that it's not quite that simple and can't put my finger on why.

(I'm not affiliated with them in any way.)

The Meta Programming System from JetBrains:

"MPS is an implementation of Language Oriented Programming, whose goal is to make defining languages as natural and easy as defining classes and methods is today. The purpose is to "raise the level of abstraction", which has been a major goal of programming since the first assembly language was born. MPS uses a variety of techniques, especially generative programming, to achieve this. With the freedom to program at a higher level, programmers can increase productivity, reduce errors, and adapt to changes more quickly.

The MPS project is still currently in the research phase, and could benefit greatly from open review and comments from anyone interested."

I dunno if this is snake-oil, but I've heard good things about the other tools they have released (IntelliJ, Resharper).

hello,

i'd like to find out about the differences between erlang processes and pthreads threads -- not in terms of the use of them but in what they actually are -- what the process and thread consists of -- how processes and threads differ and what those differences mean/amount to. i know an erlang process is much more economical (probably in both memory and cpu use) than a thread -- what is it that threads have and processes don't? stacks? each thread has a stack of it's own i think; do processes not? -- those are the kind of differences i'd like to find out about -- where can i read about this kind of thing? i notice there's a c project called "Protothreads: lightweight, stackless threads in C" ( http://www.sics.se/~adam/pt/index.html ) -- how similar to a process is one of these protothreads do you think (if you happen to know anything about protothreads)?

any info on this would be great.

thanks, ben.

I've been wondering about this for a while, google and LtU archives didn't bring up anything:
Is it posssible to generate an interpreter and an IDE for a language by providing a simple BNF type specification?

My understanding is that BNF (or EBNF) as it is usually used by parser-generators is not strong enough for this task because:
1. The specification has to deviate from its simple language representation due to problems such as left recursion.
2. CFG, by definition, can't do context based analysis, doesn't know anything about typing rules, in other words, doesn't know about the semantics of a language.

Regarding the first problem, I found the following from CTM (p. 641, last paragraph) interesting:
"Relational programs can be written to parse highly ambiguous grammars. This is one of the most flexible ways to do parsing. It can parse grammars with absolutely no restriction on the form of the grammar. The disadvantage is that if the grammar is highly ambiguous, the parser can be extremely slow."

Doesn't this mean that we can describe a general grammar which is good not only for parsing, but also for extracting a simple, clean AST (let's say we accept the slow speed for the sake of building an easy language-prototyping system).

Regarding the semantics of a language: why couldn't we use some sort of operational semantics, the way they are described in Pierce's TAPL (actually PVR has has an SOS in CTM...lol :) )

In other words, given the following:
--A simple logic language with a context, well integrated with an EBNF syntax (an 'extended' EBNF),
--A way to tell this 'system' where to find existing source code files (so the generated IDE can parse those 'libraries' to provide code-completion)
--Typical OS interface routines (to print to screen, read from keyboard, read/write HD, etc.)
What else is required? Would this scale to non-[OO, procedural, functional] languages?

(I understand that many existing languages are not easy to define using TAPL type rules...perhaps a system such as this, with all its benefits, will encourage non-expert language creators to put more thought into semantics)