Intlib logo TheLanguage

A link

Just in order not to lose the link, I place it here. This is a HOWTO on writing language frontends for GCC. -- AndreyStolyarov

What is it?

This page is about our new project -- some kind of a universal language.

It is based on the idea of data abstraction, because having this mechanism and clear syntax makes possible to implement almost any paradigm (as InteLib prooved). So, it will be the base for implementing other paradigms (such an idea was found in Great American Compilers, but our language should suit low-level programming as well).

Colleagues, I've just created the page TheLanguageMacro. Comments are welcome. -- Andrey Stolyarov

Some ideas concerning the language.

I ask you, especially Igor G. Golovin and AndreyStolyarov, to add some ideas since I've hadn't remembered them all. -- IgorElman

  1. Operator whitespace - For more expressive power.
  2. Low-level - All what is possible to implement as external library, including mechanism of virtual functions and so on, should be done so.
  3. Backwards compatibility with C
  4. to be continued :)


Yes, it would be nice to read something else about the subj. If anyone except IgorElman (I've heard his opinion already ;)) explains the idea of whitespace operation, 'twould be great -- RamosianGlider

Well, I've got several things to say. First, and the main: The language as such must be low-level, just like C. In fact, that's the only chance to be better than all the high-level languages such as Java, C#, bla-bla-bla. All the high level programming capabilities must be added by libraries using abstract data types with operations. The language should be really universal, and in order to reach it, it must allow low-level programming such as needed for operating system kernels.

The second thing is I don't think there can be (and should be) compatibility with C++. C++ as it exists now is way too high already. In fact, many of C++ features should never come into the new language; this includes, but not limited to, RTTI, multiple inheritance (unless we find a way to implement it as a library, heh... I can't imagine such an implementation), exceptions (the language should may be present some features for it, but they must be way simpler)... So, the compatibility must be with C, not C++. Even not C99. Even not C90. May be ANSI C.

The last-but-not-least thing is that I refuse the idea of .NET translation. .NET and low-level programming are mutually exclusive. Furthermore, .NET is a platform to integrate different languages. Out goal is to create a platform to integrate paradigms without languages as such. This to mean, the language itself will be the platform. -- AndreyStolyarov

  1. I have expressed that as "total minmalism"
  2. Yes, yes. Of course, I agree. Anyway I thought about compatibility with C++ with libraries.
  3. Generally, I agree. But I ask you to consider current situation. (Anyway, not the matter - It is the last point because it can be done on any stage, if needed)

P.S. Maybe you want to fix intro text? -- IgorElman

I find this idea exciting. From the programmer's point of view (I mean the user of your compiler), the ability to overload the whitespace operator is a thing which can give great expressive power. Don't you want to allow overloading of the dot operator too? ;)

[I don't see any useful way of overloading the dot. However, I think we'll need something like it (may be @ or even $) for calling virtual functions, because I'm serious about removing virtuality into library from the language. -- AndreyStolyarov

[What we definetely need is support for tree-like discussions a la Wikipedia Talk pages.

Now about the dot. @ and $ seem completely disgusting to me. The first recalls DOS batch files, and the second look like Perl var. -- OlegFrantsuzov ]

Ah, before I forget it: I hope templates will be there.

I had fixed some typos etc., and replaced operation whitespace with operator whitespace. I do think this is more correct. -- OlegFrantsuzov

This discussion makes me really wonder, what are we talking about. Isn't it very and very funny to discuss overloading of operations ".", "$", "@" and express emotions on that topic when we talk about the language with as free syntax as possible? -- MeDendik

["as fre syntax as possible" is definitely not what we want, and I'm getting tired to repeat it. Free syntax is a thing which was done several times before, and this way is proven to lead to nowhere. -- AndreyStolyarov]

Than is not a reasonable argument, it's about meaning of words "free syntax". Adding syntax-level macros is exactly the way to make more free syntax (actually, almost the way I imagined that). Adding more opertations to overload is also a way to make free syntax, except that it is like turning a car into plane with a rasp, at least if that topic is discussed such actively before anything else done ;). As for me, I do not very like haskell's lexical layer, with no limit on operation names, but it seems wierd to me to not have at least that approach in multiparadigm language. Otherwise you just make a language for two given paradigms you know and two given languages you want to include. -- MeDendik

[Well let me try another explanation. We don't need as free as possible syntax; instead, we wand as strict as possible syntax which still allows to (a) create algebras of objects so that the immediate integration technique can work adequately, and (b) to move virtual functions into the library off the language. I agree that even this way we still can end up with a syntax too free from some points of view, but that's not what we want, that's only the evil we can tolerate as long as we can't avoid it -- AndreyStolyarov]

Okay-okay! We'll see -- MeDendik

Hmm. No, actually, that is not okay, as I said. Unless you revoke being platform for multiparadigm programming from language targets, anything about tolerating free syntax as evil seems absurd to me. -- MeDendik

Two notes about your fixed idea about "moving virtual functions into library". First: should I start enumerating successfull OO languages that have nothing resembling that strange construct from C++? Second: most important property of the feature in C++ is it's speed, for that very reason moving it away from language (if you do want to have that feature) means creating a more slow and useless implementation than that in C++. Is that what you want? -- MeDendik

One more opinion: I will not accept the language as good enough until I see at least a reasonable syntax for Haskell in it... Isn't it fair enough? -- MeDendik

[Not bad, BTW. With operator space, however, I believe there can be something very close to the original Haskell syntax. -- AndreyStolyarov]

With space operator -- for sure. With discussions about "@" or "$" -- never."" -- MeDendik

InteLibWiki PageList RecentChanges PageHistory