Lambda the Ultimate

inactiveTopic Eidola Language
started 3/1/2004; 5:48:13 PM - last post 3/2/2004; 1:15:16 PM
Mark Evans - Eidola Language  blueArrow
3/1/2004; 5:48:13 PM (reads: 9201, responses: 6)
Eidola Language

Traditional programming languages are heavily tied to their representation as textual source code, which is unfortunate -- pure text is a very poor notation system for the concepts of a high-level language. An Eidola program, however, exists independent of any representation; its "fundamental" form is as a set of carefully defined mathematical abstractions, opening the possibility of having many different notations. Representations of the language thus exist for the benefit of the programmer instead of the compiler, and freed from the constraints of text files, we can tackle the question of how to notate a program well.

Be warned: Eidola is a very large project its very early phases. It is still mostly theory and vaporware.

The impetus and evolution articles give motivation, while semantics are specified in a short PDF document. The proprietors eagerly solicit feedback. They appear to be Java/C++ people. What I find interesting here is the prospect of a visual implementation.

Posted to general by Mark Evans on 3/1/04; 9:41:17 PM

Ian Bicking - Re: Eidola Language  blueArrow
3/1/2004; 9:56:58 PM (reads: 472, responses: 1)
I think Eidola is mostly a dead project at this point. I remember way back when it first came around... it was really evolved from the wrong reasons. It was just "visual programming sure would be cool", as opposed to graphical programming by more worthy goals -- like making it easier to program, understand programs, debug, etc.

You can get to graphical programming coming with those motivations (and a certain audience in mind). Squeak's scripting (part of eToys, the subject of does some of this. Another interest project (though unfortunately dormant) is Boxer (at -- it was really driven by a desire to make programming accessible, and used visual tools and metaphors to achieve that. But it didn't go all out or try to make things visual for novelty's sake.

I'd love to see Boxer's ideas in another language. Probably DrScheme could do it pretty easily now...

andrew cooke - Re: Eidola Language  blueArrow
3/2/2004; 4:41:31 AM (reads: 433, responses: 0)
OT: The University of California has prohibited our providing information about PC Boxer. Seek other sources of information.

Eh?! (

[on edit]

Ah! (so it appears to still be under development - the expiry date for the PC demo is the end of this year)

Tom Duff - Re: Eidola Language  blueArrow
3/2/2004; 9:23:42 AM (reads: 373, responses: 0)
UCB has apparently started being hardnosed about using their network to promote anything that the most confused reader might mistake for commerce. A friend whose personal site had a name ending in ".com" was forbidden to link to it from his UC employee page.

Frank Atanassow - Re: Eidola Language  blueArrow
3/2/2004; 9:34:40 AM (reads: 371, responses: 1)
Traditional programming languages are heavily tied to their representation as textual source code

No, they aren't. I could just mention abstract syntax, but any semantic model is a counterexample to this claim.

Ehud Lamm - Re: Eidola Language  blueArrow
3/2/2004; 12:14:05 PM (reads: 336, responses: 0)
Right. I was wondering why no one mentions this.

Some people shudder on hearing things like 'weak typing.' Me? I start runnig away when someone is confused about what concrete syntax is.

Mark Evans - Re: Eidola Language  blueArrow
3/2/2004; 1:15:16 PM (reads: 323, responses: 0)

Eidola is a naive effort - but that's why LtU feedback can help. Reciprocally, efforts like Eidola demonstrate what thinking exists in the wild, so touching on LtU's educational mission.

Probably they mean implementation not representation as textual source code which (as Frank complains) is just concrete syntax. They allow an interest in visual programming to confuse their terminology. Eidola's point seems to be that semantic models are neither formal enough nor explicit enough, but buried in the implementation, and thus hard to decouple. Our good friend Python is guilty as charged: "if you ... tried to re-implement Python from this document alone, you ... would probably end up implementing quite a different language....If you would like to see a more formal definition of the language, maybe you could volunteer your time."