new language - subset of a universal language

[navin syde]

I've this idea about a new language which has the following
capabilities:

** general purpose - you learn one language to do most of the things
1) system programming - can implement real time systems, OSes, etc.
2) client/server side programming
3) embedded system programming, for mobile devices. phones, set-
top boxes, micro-controllers etc. (like embedded c; or java ME)
4) web-programming - can use scripting variant of the language for
this; will comes with a web-framework (like PHP, Ruby/Grails, etc)
5) parallel/cluster programming - super computing platforms - like
HPC
6) must have OO capabilities
7) UI programming - comes with a platform independent UI framework
for major platforms
8) etc.


** highly portable - source & binary (yes, at least on to main
platforms as single executable with different run-times - either as
fat binary, or binary with accompanying run-time for each platform);
see java & .NET does a trick, as they supply the VMs (the run-time-
platform) prior to the programs; they say language is portable. but
really not - you need to have the VMs ported on the platform first.

** run on bare metal - i.e. compiled so it is faster than any language
on a VMs - not having JIT compilers

** can consume libraries from various languages - libraries from java
- but without a VM, bytecode should be able to be invoked or
translated and linked to the binary; libraries from C/C++ etc.

questions are:
- How easy to design a language like this?
- Are there any example languages like this, that have already built?

Also looking forward your expert help on designing such a language.

cheers
-Navin

[Dmitry A. Kazakov]

Very difficult because many things are not settled until now. And language
design is one of the most difficult things.

When you require OO + UI + parallel/distributed you get a huge problem of
working them together. E.g.

- OO + UI raises the issue of handling events in a structured hierarchical
and safe way per OO inheritance. Nobody knows how.

- OO + distributed means distributed types, operations, objects. It again
is a huge problem. Inheritance from task objects is very difficult at best.

- UI + parallel has the problem of task safe UI, again, a problem, some
frameworks like GTK are single threaded, others like Win32 are exposed to
deadlocks and live-locks.

> - Are there any example languages like this, that have already built?

Ada 2005 is most close to 1, 2, 3, 5, 6.

4, 7 are not related to the language design, however, as I said, 7 requires
some language capacities missing in any existing language.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Rugxulo]

Hi,

On May 28, 2:02 pm, navin syde <navin.s...@gmail.com> wrote:
>
> I've this idea about a new language which has the following
> capabilities:

Uh oh, sounds like design by committee. ;-)

http://xkcd.com/927/

> ** general purpose - you learn one language to do most of the things
>    1) system programming - can implement real time systems, OSes, etc.

C, Modula-2, Oberon, Modula-3

>    2) client/server side programming

Dunno exactly what this means, networking?? Java, Modula-3

>    3) embedded system programming,  for mobile devices. phones, set-
> top boxes, micro-controllers etc. (like embedded c; or java ME)

C, Forth, Oberon (or embedded into apps, e.g. Lua, Tcl, Rexx)

>    4) web-programming - can use scripting variant of the language for
> this; will comes with a web-framework (like PHP, Ruby/Grails, etc)

HTML5/JS, Java

>    5) parallel/cluster programming - super computing platforms - like
> HPC

Fortress, Go

>    6) must have OO capabilities

(puke) Don't they all these days? It's practically mandatory (sadly).
But, IMHO, it shouldn't be forced in every situation. Similarly
Unicode, multithreading, etc. Nice (I guess) but overkill for some
cases.

>    7) UI programming - comes with a platform independent UI framework
> for major platforms

Various C/C++ toolkits have been ported, but usually it neglects
anything that isn't "heavyweight desktop" or similar. It would be
interesting to know what "bare minimum" would be considered
acceptable.

>    8) etc.
>
> ** highly portable - source & binary (yes, at least on to main
> platforms as single executable with different run-times - either as
> fat binary, or binary with accompanying run-time for each platform);
> see java & .NET does a trick, as they supply the VMs (the run-time-
> platform) prior to the programs; they say language is portable. but
> really not - you need to have the VMs ported on the platform first.

Nothing is ever "by default" portable anyways, just hidden behind
different layers. Having a VM is just a standard backend that is
(hopefully) easier to port to, e.g. see Pascal (pcode -> P4) and
Modula-2 (mcode -> M2M-PC), which predated and inspired Java.

> ** run on bare metal - i.e. compiled so it is faster than any language
> on a VMs - not having JIT compilers

Anything (almost?) can run native, even Rexx, BASIC, Java, etc.
"Faster" is an implementation issue, almost never determined by
language spec itself.

> ** can consume libraries from various languages - libraries from java
> - but without a VM, bytecode should be able to be invoked or
> translated and linked to the binary; libraries from C/C++ etc.

So far, that's been very difficult, esp. since different calling
conventions are used. "cdecl" seems to be considered
pseudo-"universal" these days, and I guess that's as good as you can
hope for. Some languages (or tools) do a better job at "interfacing"
than others.

> questions are:
> - How easy to design a language like this?

If it was easy, there wouldn't be so many (nor different parsers,
etc). You can always try again, but "those who forget history are
doomed to repeat it".

> - Are there any example languages like this, that have already built?

I don't think "one language to rule them all" exists, but most people
seem to prefer only one or two languages. Judging by statistics, it
seems C/C++/Java are the big dogs these days, but a few others (and
various scripting ones) still exist in some corners too. I don't think
you can please everyone.

> Also looking forward your expert help on designing such a language.

Heheh, ugh, unlikely!

P.S. Not saying that no language fits these requirements, some will
probably (mostly) correctly point out various ones that already do
(more or less) all of the above, e.g. Oberon, C/C++, Ada, FreePascal,
FreeBASIC, Java, or whatever. You can pretty much make any language do
whatever you want. It's up to "critics" to determine how well (or
little) it satisfies their goals (if at all). It's easy (cheap) to
call a language a "failure" instead of admiring its successes. Also
talk is cheap ("use the right tool for the job"), esp. with so many
implementation difficulties (mostly for polemic reasons). So I dunno,
honestly, it's a big mess. But indeed, some seem better than others
(but it depends on your own skills, needs, wants, etc).

[BartC]

"navin syde" <navin...@gmail.com> wrote in message
news:084aa38d-573d-452d...@ki5g2000pbb.googlegroups.com...

> I've this idea about a new language which has the following
> capabilities:
>
> ** general purpose - you learn one language to do most of the things
> 1) system programming - can implement real time systems, OSes, etc.
> 2) client/server side programming
> 3) embedded system programming, for mobile devices. phones, set-
> top boxes, micro-controllers etc. (like embedded c; or java ME)
> 4) web-programming - can use scripting variant of the language for
> this; will comes with a web-framework (like PHP, Ruby/Grails, etc)
> 5) parallel/cluster programming - super computing platforms - like
> HPC
> 6) must have OO capabilities
> 7) UI programming - comes with a platform independent UI framework
> for major platforms
> 8) etc.

You want a single language that runs on both a system with 256 bytes of
memory, as well as one with 256GB of memory? Do you need programs to be
portable from one machine to the other too?

> ** highly portable - source & binary (yes, at least on to main

Difficult with such a wide range of target hardware. You might approach the
problem by targeting a VM ...

> ** run on bare metal - i.e. compiled so it is faster than any language
> on a VMs - not having JIT compilers

... but you don't want a VM, nor even native code if it's the result of JIT
compilation.

> ** can consume libraries from various languages - libraries from java

Now you're giving up on the one language, and allowing mixed language
solutions.

> - but without a VM, bytecode should be able to be invoked or
> translated and linked to the binary; libraries from C/C++ etc.

So, is translated bytecode OK or not?

> questions are:
> - How easy to design a language like this?

You've forgotten syntax. Even if such a language was feasible, nobody will
be able to agree on syntax. (Which is unfortunate as that is one thing that
*could* unite a multitude of languages which is what would be most
practical.)

> - Are there any example languages like this, that have already built?

If you broaden your scope of what a 'language' actually is, then yes such a
'language' already exists. Although it is necessary to switch syntax and
libraries as you move from one field of applications to another (bearing in
mind you've said nothing about syntax, but have agreed to make use of any
libraries that are kicking around).

> Also looking forward your expert help on designing such a language.

If you put forward some actual, concrete proposals, then I'm sure people
here will help with comments.

--
Bartc

[Marco van de Voort]

On 2012-05-29, Rugxulo <rug...@gmail.com> wrote:

> On May 28, 2:02?pm, navin syde <navin.s...@gmail.com> wrote:
>>
>> I've this idea about a new language which has the following
>> capabilities:
>
> Uh oh, sounds like design by committee. ;-)

Yup, anything to avoid making definite choices. Either this is the outcome
of a committee, or he probably is in the civil service :)

One usually starts a new language by making definite choices to what one
wants, not by avoiding them.

[Jacko]

Yep, simple opposites like pre/post and object/infix notation have to be decided. Only then will parse rules be definable. Maybe natural language would be better for committee cobol...

cheers Jacko

http://code.google.com/p/jarvar/wiki/IndexOfWords

[navin.syde]

I would reword what I'm dreaming about :)
A "new language + a technology platform", rather than just the
language.

The language syntax - I prefer most used and favored syntax by
majority of the programmers as the *base syntax* for the language. it
needs to be less complex to code, read & understand (also something
I'm also familiar with :-)) So I'm thinking of C like syntax, and for
OO representation to have some similarity to C++/Java language syntax.
Also, want to have very shorter learning curve for people to adopt to
the language - rather having a alien syntax that hard to understand.
and add extensions to the base syntax to cater for objective listed my
original post. feedbacks are welcome here.

For the compiler design I would go for a retargetable compiler design
- for starter, would like to start with one of the existing toolkits:
1. GCC - it has backends for most of the CPU architectures - I think
this is the most ported compiler
2. lcc - from Chris Fraser & David Hanson
3. Open64 - reasons for looking at this is due to UPC (Unified
Parallel C) http://upc.lbl.gov/

This will allow me to experiment enough with the language faster and
then later do my own compiler from scratch. Suggestions are welcome
here?
Also looking at the compiler design here: http://titanium.cs.berkeley.edu/
This uses Java like syntax and allow OO programming for distributed
systems.


this may be a **crazy idea** -- having all these objectives, but I'm
setting some goals.
I've very little time to work on this, so there is no promise, but I
would do as much as possible to look for a better language +
technology platform.
reason is that; there are many languages, tool kits and libraries
which address narrowly focused objectives (yes, it avoids complexity)
- but in general what they all do have things in common. like
arithmetic, logical, condition evaluation, looping/jumping/branching,
predicting, manipulation of bits, memory moves, storage, display,
control, transfer etc ... etc... eventually a particular task is
accomplished. So why there needs for many languages to do those; can't
we use one? What I believe we need is one language, but good compiler
& toolkits + libraries with technology platform - so this simplify to
accomplished a task.
e,g, today C with extensions and java with lots of libraries/profiles
allow achieving many goals.

***
* The compiler should be capable of generating code for micro
controllers of having 256 bytes (tiny) and also for machines with
256GB of memory. The language should be able to be design targeting
these architectures. It is not possible to make binary portable across
these architectures. So believe having different memory models – tiny,
medium, large. So libraries written for these categories will not able
to port, unless they are recompiled targeting this – this is going to
be a limitation of binary portability.

* JIT compiler may be ok, but no VMs - this is to take the full h/w
strength. (of cause OS must be there)

* able to use other language libraries is good thing as people can use
already available one than inventing their own and will be fast to
adopt to the language.
Idea is: at linking time (say one parse at intermediate code level -
before assembly) - for static images - libraries functions will be
extracted, and translated into intermediate form - e.g. if a java
library jar is used; then byte code for functions(plus dependencies)
will be extracted from the jar and translated into the intermediate
form of the new language, and will be globally optimized before target
image is generated - (hope this is not crazy?). for shared libraries
need to think about a mechanism is it seems quite complex for loading
& positioning, setting the code pointer and execution, real time
translate ... etc.

Cheers

[Dirk van Deun]

: > One usually starts a new language by making definite choices to what one
: > wants, not by avoiding them.

: Yep, simple opposites like pre/post and object/infix notation have to be decided. Only then will parse rules be definable. Maybe natural language would be better for committee cobol...

More importantly, seemingly unrelated language features can be
incompatible in theory or in practice. If you want pervasive lazy
evaluation, better rule out imperative programming. If you want to
support ActiveRecord (i.e. "MyNewLanguage on Rails"), better rule
out static typing. Etc.

Dirk van Deun
--
Licensed to (kill -9)

[navin.syde]

* Also for embedded systems JIT may not be a choice due to the
restricted resource issue and no OS.

[BartC]

"navin.syde" <navin...@gmail.com> wrote in message
news:a218f4c1-440b-4bb8...@pr7g2000pbb.googlegroups.com...

> I would reword what I'm dreaming about :)
> A "new language + a technology platform", rather than just the
> language.
>
> The language syntax - I prefer most used and favored syntax by
> majority of the programmers as the *base syntax* for the language. it
> needs to be less complex to code, read & understand (also something
> I'm also familiar with :-)) So I'm thinking of C like syntax, and for
> OO representation to have some similarity to C++/Java language syntax.

Since this is a new language, why not have a compiler switch so that people
can write in a syntax of their choice? Because some people can't stand
C-style syntax. It's also very fiddly to write, unforgiving, and
error-prone, among a number of problems with the syntax.

(So in a simple iterative loop such as:

for (i=a; i<b; ++i) ...

There are 3 times as many opportunities to get the index variable wrong, or
the limiting condition, or the incrementing step. In fact, shouldn't the
compiler be generating the code for the loop mechanism rather than the
programmer?)

> For the compiler design I would go for a retargetable compiler design
> - for starter, would like to start with one of the existing toolkits:
> 1. GCC - it has backends for most of the CPU architectures - I think
> this is the most ported compiler
> 2. lcc - from Chris Fraser & David Hanson

Actually, it doesn't look good when you are using C as the starting point
for a new, universal language...

--
Bartc

[navin.syde]

will consider your point regarding the loop; are there list of other
things you know which are having issues?

> Actually, it doesn't look good when you are using C as the starting point
> for a new, universal language...
>

C will not be my starting language, rather I will use a retargetable
compiler, as it will be easy for me to modify and /or introduce a
front-end to create a new language compiler. Also it will be easy for
me to add backends targeting different architectures. also most of
them are well documented, and will reduce time to implement the
compiler.

GNU Compiler Collection (GCC) - has many front-ends, and will be easy
to add one for this language.
lcc & open64 can be modified easily to build a new compiler.

also, I will look into LLVM, if that can helps.

[navin.syde]

> Since this is a new language, why not have a compiler switch so that people
> can write in a syntax of their choice?

Are you suggesting people will use their own syntax, so compiler need
to understand all of them based on a switch? that will complicate the
compiler design and will not able to achieve it's goals.
goal is "one language" to do all.

[BartC]

"navin.syde" <navin...@gmail.com> wrote in message

news:776194d7-9cde-4f55...@h10g2000pbi.googlegroups.com...

You've already mentioned GCC having a choice of front-ends, so perhaps it
can be done that way. And a parser is the simplest part of a compiler.

--
Bartc

[thomas...@gmx.at]

On Wednesday, May 30, 2012 10:38:34 AM UTC+2, navin.syde wrote:
> I would reword what I'm dreaming about :)
> A "new language + a technology platform", rather than just the
> language.

I am working on a "language technology platform" for years now.
One of the ideas is: The features of a language are not hardcoded
in the interpreter or compiler. Instead they are defined in
libraries. This even allows the defintion of a completely new
language.

In the topic you mention "universal language". Creating such an
universal language was the intention, which started my project
(around 1980). With syntactic and semantic extensions I planned to
adapted this universal language to various application areas and
to cope with advances in programming language design.

My original plan proposed an import of a Pascal, Fortran, Cobol,
Ada, etc. library, followed by a corresponding program. So I
imagined a language which is capable to emulate all other languages.
It soon turned out that many classic languages contain features,
which are hard to emulate in an extensible language. At the same
time this features are often not considered good ones and therefore
they are omitted from new languages. So over time I restricted the
extensible language features, such that the focus moved to the
support of modern language features. Gathering features from
different languages became an important goal.

> this may be a **crazy idea** -- having all these objectives, but I'm
> setting some goals.
> I've very little time to work on this, so there is no promise, but I
> would do as much as possible to look for a better language +
> technology platform.

When you have very little time to work on this, you should
definitely use the work of others. And honestly, something like

Let's design and implement a great new language

will NOT motivate others to do all the work. There are just too
many designers and too few implementers. The designers will usually
not agree. Agreement with implementers is even more improbable.
Finally: People who have enough time, skill and motivation to
implement a language do so for their own designs. Believe me:
Language design and implementation is really a LOT of work.

Maybe you can use Seed7 as base for your programming language
research. E.g.: You can experiment with different statements and
operators. I am currently improving the documentation. I am also
splitting the main library of Seed7 (seed7_05.s7i) into several
libraries. The documentation for Seed7 libraries

http://seed7.sourceforge.net/libraries/index.htm

contains libraries which describe the features of boolean, char,
integer, float and string:

http://seed7.sourceforge.net/libraries/boolean.htm
http://seed7.sourceforge.net/libraries/char.htm
http://seed7.sourceforge.net/libraries/integer.htm
http://seed7.sourceforge.net/libraries/float.htm
http://seed7.sourceforge.net/libraries/string.htm

For-loops for various types can be defined defined with a template.
See:

http://seed7.sourceforge.net/libraries/forloop.htm

Hope that helps.


Regards,
Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[BartC]

"navin.syde" <navin...@gmail.com> wrote in message

news:6c7c4184-0cde-46b4...@s6g2000pbi.googlegroups.com...

> will consider your point regarding the loop; are there list of other
> things you know which are having issues?

Involving C? Loads. They get discussed in comp.lang.c from time to time, but
that language is static.

But strangely many of the syntax limitations of C seem to propagate through
to most languages that inherit it's syntax; they don't seem interested in
adding interesting new statements.

>> Actually, it doesn't look good when you are using C as the starting point
>> for a new, universal language...
>>
>
> C will not be my starting language, rather I will use a retargetable
> compiler, as it will be easy for me to modify and /or introduce a
> front-end to create a new language compiler. Also it will be easy for
> me to add backends targeting different architectures. also most of
> them are well documented, and will reduce time to implement the
> compiler.
>
> GNU Compiler Collection (GCC) - has many front-ends, and will be easy
> to add one for this language.
> lcc & open64 can be modified easily to build a new compiler.

OK. In that case that demonstrates my point that there might be already be a
universal 'language', by choosing combinations of front and backends to GCC.

However the sort of languages compilable with GCC are not too interesting
from my point of view; they tend to be highly complex (eg. C++) and not very
dynamic, and the development model (edit-compile-link-debug) is not
attractive.

How would you use gcc to compile a language that looks and works like Python
for example? And have code that can be entered a line at a time, and run
instantly.

--
Bartc

[navin.syde]

> OK. In that case that demonstrates my point that there might be already be a
> universal 'language', by choosing combinations of front and backends to GCC.
>
> However the sort of languages compilable with GCC are not too interesting
> from my point of view; they tend to be highly complex (eg. C++) and not very
> dynamic, and the development model (edit-compile-link-debug) is not
> attractive.
>
> How would you use gcc to compile a language that looks and works like Python
> for example? And have code that can be entered a line at a time, and run
> instantly.

It is not the intention to add just another front/back end to the GCC
-- it will not going to be universal subset and will not be new
technology platform at all; and nobody will be interested of it. My
intention is to use retargetable compiler as the start point to reduce
the effort at initial stage and put more focus on the language syntax
& semantics. I may need to add several backends, and intermediate
steps to satisfy that. Once I get that right, I'll write the compiler,
linker, codegenerator or JIT (or something totally new) from scratch
to get the technology platform right. o/w if I go and try to build
everything from scratch from start I'll never gonna finish my project
in this life time.

[BartC]

"Rugxulo" <rug...@gmail.com> wrote in message
news:8ccc889c-7e11-4c05...@n42g2000yqm.googlegroups.com...

> On May 28, 2:02 pm, navin syde <navin.s...@gmail.com> wrote:

>> 6) must have OO capabilities
>
> (puke) Don't they all these days? It's practically mandatory (sadly).
> But, IMHO, it shouldn't be forced in every situation. Similarly
> Unicode, multithreading, etc. Nice (I guess) but overkill for some
> cases.

OO is deliberately left out of any languages I design. Mostly because I've
never used it nor understood it, so cannot really implement it. Also it
looks pretty complicated to actually do.

I guess that means no-one will use them, but.. I don't care. The same goes
for stuff like currying, continuations, closures; terms I have to look up
every time to find out what they mean, then forget five minutes later.
Obviously I've never had a pressing need for them!

> "Faster" is an implementation issue, almost never determined by
> language spec itself.

They go hand-in-hand. The language spec might say for example that:

a+b

can't overflow (either end up with a wider type, or raise an error). The
implementation might do a good job of this, but it's certainly an extra
imposition on the compiler, especially in a language where 99.9% of the time
a+b won't overflow. Yet overflow-checking code must be included in all those
cases.

An extreme example is Python, which is extremely difficult to get up to
speed (because everything is dynamic and liable to change at any instant.)
Make some minor language changes, put in some restrictions, and suddenly a
whole load of optimisations become possible.

--
Bartc

[Marco van de Voort]

On 2012-05-30, BartC <b...@freeuk.com> wrote:
>> goal is "one language" to do all.
>
> You've already mentioned GCC having a choice of front-ends, so perhaps it
> can be done that way. And a parser is the simplest part of a compiler.

Sounds easy, but what I hear from it, it is still a massive project to
create a frontend, and afterwards an infinite catch up problem to adapt to
new versions. GNU Pascal (one of the oldest open source projects and gcc
frontend, started in 1988) gave up a few years ago.

From what I hear, generation of C (or in rare cases C++) code is seen as an
alternative my most little languages. A few others target JVM, but those are
more from the scripting language side of things, which I monitor less
intensively so I don't know what became of them.

Of course there is a lot of talk about LLVM, but most people are still in
the planning or building a proof of concept language on top of LLVM, and the
more long term effects are not known yet (though their management of
internals and interfaces looks better on paper than gcc's)

[BartC]

"Marco van de Voort" <mar...@toad.stack.nl> wrote in message
news:slrnjsjo6d...@toad.stack.nl...

> On 2012-05-30, BartC <b...@freeuk.com> wrote:
>>> goal is "one language" to do all.
>>
>> You've already mentioned GCC having a choice of front-ends, so perhaps it
>> can be done that way. And a parser is the simplest part of a compiler.
>
> Sounds easy, but what I hear from it, it is still a massive project to
> create a frontend, and afterwards an infinite catch up problem to adapt to
> new versions. GNU Pascal (one of the oldest open source projects and gcc
> frontend, started in 1988) gave up a few years ago.

For this purpose, all the different syntaxes fed into the compiler would
need to be compatible (being able to express the same language features).
That doesn't seem to be the case with what gcc supports at present.

And because the syntaxes are all really the same language, then perhaps only
a 'thinner' front-end needs to be different.

So it's perhaps less ambitious than it might appear.

--
Bartc

[Marco van de Voort]

On 2012-06-02, BartC <b...@freeuk.com> wrote:
>
>>>> goal is "one language" to do all.
>>>
>>> You've already mentioned GCC having a choice of front-ends, so perhaps it
>>> can be done that way. And a parser is the simplest part of a compiler.
>>
>> Sounds easy, but what I hear from it, it is still a massive project to
>> create a frontend, and afterwards an infinite catch up problem to adapt to
>> new versions. GNU Pascal (one of the oldest open source projects and gcc
>> frontend, started in 1988) gave up a few years ago.
>
> For this purpose, all the different syntaxes fed into the compiler would
> need to be compatible (being able to express the same language features).

No. They have to align to the same intermediate representation, that is
not the same.

A common backend of course propagates some assumptions back to the frontend,
but be careful not to overgeneralize it.

> That doesn't seem to be the case with what gcc supports at present.

I don't understand this. That is (a common intermediate representation) is
what gcc does. But it changes every other couple of versions.

> And because the syntaxes are all really the same language, then perhaps only
> a 'thinner' front-end needs to be different.

I doubt it, since the default frontends are the most complicated, so not
easily subsettable. IMHO this is wishful thinking on the back of a beer
coaster.

[BartC]

"Marco van de Voort" <mar...@toad.stack.nl> wrote in message

news:slrnjsp27j...@toad.stack.nl...

> On 2012-06-02, BartC <b...@freeuk.com> wrote:
>>
>>>>> goal is "one language" to do all.
>>>>
>>>> You've already mentioned GCC having a choice of front-ends, so perhaps
>>>> it
>>>> can be done that way. And a parser is the simplest part of a compiler.
>>>
>>> Sounds easy, but what I hear from it, it is still a massive project to
>>> create a frontend, and afterwards an infinite catch up problem to adapt
>>> to
>>> new versions. GNU Pascal (one of the oldest open source projects and
>>> gcc
>>> frontend, started in 1988) gave up a few years ago.
>>
>> For this purpose, all the different syntaxes fed into the compiler would
>> need to be compatible (being able to express the same language features).
>
> No. They have to align to the same intermediate representation, that is
> not the same.
>
> A common backend of course propagates some assumptions back to the
> frontend,
> but be careful not to overgeneralize it.

Imagine that you have two alternate syntaxes for a single language. One just
uses {,} to enclose blocks, the other uses 'begin','end' to do so.

It's easy to see this would be trivial to implement (perhaps using the same
parser with an option). Everything else about the language is the same, so
the resulting syntax tree is the same, the symbol table is structured the
same way, the type system, etc.

Now try this where one syntax *looks* like Fortran for example, and the
other one *looks* like Ada. Somewhat more difficult this time, and there
might be some features that can't be expressed in both languages. But still
doable I would have thought.

>> That doesn't seem to be the case with what gcc supports at present.
>
> I don't understand this. That is (a common intermediate representation) is
> what gcc does. But it changes every other couple of versions.

>> And because the syntaxes are all really the same language, then perhaps
>> only
>> a 'thinner' front-end needs to be different.
>
> I doubt it, since the default frontends are the most complicated, so not
> easily subsettable. IMHO this is wishful thinking on the back of a beer
> coaster.

Finally, try this where one language *is* Fortran, and the other *is* Ada. I
can see that differences between the two could make this nearly impossible,
not just in the front end, but finding an intermediate code and backend that
works for both.

My suggestion would come somewhere between my first two examples. It would
be for a single language, and for a choice of syntaxes designed to express
the same language features.

--
Bartc

[Marco van de Voort]

On 2012-06-04, BartC <b...@freeuk.com> wrote:
>>> For this purpose, all the different syntaxes fed into the compiler would
>>> need to be compatible (being able to express the same language features).
>>
>> No. They have to align to the same intermediate representation, that is
>> not the same.
>>
>> A common backend of course propagates some assumptions back to the
>> frontend,
>> but be careful not to overgeneralize it.
>
> Imagine that you have two alternate syntaxes for a single language. One just
> uses {,} to enclose blocks, the other uses 'begin','end' to do so.

So, for the sake of argument say C and Pascal which map 1:1 for 90%.

> It's easy to see this would be trivial to implement (perhaps using the same
> parser with an option).

No that is my point. THe 90% maps easily. The 10% is the problem. E.g. that
proper ISO Pascal has a nested functions where nested functions can access
parent's variables.

Worse, they are also passable as procedure variables making a base procedure
variable a two-pointer type instead of the single pointer type that C
supports.

> Everything else about the language is the same, so the resulting syntax
> tree is the same, the symbol table is structured the same way, the type
> system, etc.

If all that is the same, you are not talking different languages, but the
same language before and after preprocessing.

> Now try this where one syntax *looks* like Fortran for example, and the
> other one *looks* like Ada. Somewhat more difficult this time, and there
> might be some features that can't be expressed in both languages. But still
> doable I would have thought.

As I demonstrate above, even a single minor feature difference can become a
major problem. It's not the commonalities that rule, but the differences,
however minute.

>>> And because the syntaxes are all really the same language, then perhaps
>>> only
>>> a 'thinner' front-end needs to be different.
>>
>> I doubt it, since the default frontends are the most complicated, so not
>> easily subsettable. IMHO this is wishful thinking on the back of a beer
>> coaster.
>
> Finally, try this where one language *is* Fortran, and the other *is* Ada.

Afaik ADA is a sane language with a proper module system. That is non
trivial with gcc, to say the least.

gcc supports separate compilation, but not modular systems.

> can see that differences between the two could make this nearly impossible,

True. Ada being an effective superset of Pascal, which I used in my examples
says enouhg.

> not just in the front end, but finding an intermediate code and backend that
> works for both.

> My suggestion would come somewhere between my first two examples. It would
> be for a single language, and for a choice of syntaxes designed to express
> the same language features.

IMHO that is not really a different language. If you map languages 1:1, you
are not designing a new language but a preprocessor.

[BartC]

"Marco van de Voort" <mar...@toad.stack.nl> wrote in message

news:slrnjsq000....@toad.stack.nl...

> On 2012-06-04, BartC <b...@freeuk.com> wrote:
>>>> For this purpose, all the different syntaxes fed into the compiler
>>>> would
>>>> need to be compatible (being able to express the same language
>>>> features).
>>>
>>> No. They have to align to the same intermediate representation, that is
>>> not the same.
>>>
>>> A common backend of course propagates some assumptions back to the
>>> frontend,
>>> but be careful not to overgeneralize it.
>>
>> Imagine that you have two alternate syntaxes for a single language. One
>> just
>> uses {,} to enclose blocks, the other uses 'begin','end' to do so.
>
> So, for the sake of argument say C and Pascal which map 1:1 for 90%.

But they are two languages, not one.

>> It's easy to see this would be trivial to implement (perhaps using the
>> same
>> parser with an option).
>
> No that is my point. THe 90% maps easily. The 10% is the problem. E.g.
> that
> proper ISO Pascal has a nested functions where nested functions can access
> parent's variables.

With any number of actual differences.

>> My suggestion would come somewhere between my first two examples. It
>> would
>> be for a single language, and for a choice of syntaxes designed to
>> express
>> the same language features.
>
> IMHO that is not really a different language. If you map languages 1:1,
> you
> are not designing a new language but a preprocessor.

This is where we started. One language, with a choice of syntax styles. That
should be easy.

What is not so easy, is actually designing compatible syntaxes, which are
different enough to make it worth the trouble. And if one or the other looks
like a well-known existing language, there may be expectations that it will
work a certain way, so putting pressure to tweak the language design.

--
Bartc

[navin.syde]

> > IMHO that is not really a different language. If you map languages 1:1,
> > you
> > are not designing a new language but a preprocessor.
> This is where we started. One language, with a choice of syntax styles. That
> should be easy.
> What is not so easy, is actually designing compatible syntaxes, which are
> different enough to make it worth the trouble. And if one or the other looks
> like a well-known existing language, there may be expectations that it will
> work a certain way, so putting pressure to tweak the language design.

so far great feedback - thanks everyone.

Implicitly speaking, CLR is kind of a platform that provides,
different syntaxes, but represent common intermediate language (CIL).
This CIL is normally do not use for coding but to run the program
using a JIT compiler. also has some similarity in the java bytecode
instructions, provides intermediate stack machine instruction for
languages that uses different syntaxes, java, jruby etc. they are not
same languages but construct are eventually similar. RTL fell into
this similarity not exactly matching the intention, though.

IMHO, having different syntaxes mean you are representing different
languages than one even though they eventually ends up as a common
language construct, but with different AST at their own syntax levels
once the code is parsed - and later transfer it into a common form.
So what I believe is, a language should have one representation
(which
everyone like to use - I know this is hard as satisfying all with one
is not easy) without introducing ambiguity and complexity at language
level so it is a universal language, that everyone understand and can
speak (meant here as 'code'). when one use that language to speak
(code) to explain a technology, everyone simply understand what he/
she
speak and complexity is reduced - and that will ease to concentrate
on
the technology more than having a language barriers.

like we speak in english right now - everyone in this group
understand
it.

So let's say we want to use different syntax, e.g. in place of C loop
we use python/ada loop systax, now what is needed is a preprocessor
to
translate it into the common language - what is important to
concentrate here is, what is that common language is? can that
directly be used for everyday speaking(code). that's what the
universal (subset) language I'm trying to find out. Also not intended
to have that common language only machine level understandable (like
in bytecode, RTL etc) but easy for human and for human to use it
effectively in their day today work (than some thing like bytecode
whic is hard to use for coding)

IMHO, So adding complexity of multiple syntaxes on top of the
technology requirement, is quite premature to speak, rather
considering a preprocessor later to cater for that, if needed - but I
prefer not to; because if someone uses one syntax, it will be
difficult
for another to understand that - so goal of universal language
breaks.
as if I use, to express this message using English alphabet but using
different grammar rules and words.

Cheers
-Navin