Is there a programming language that doesn't compile, but rather just translates into another language? I apologize if this is a stupid question to ask, but I was just wondering if this would be a literal shortcut in creating a programming language. Wouldn't it be easier (probably not speedy) but still doable?
Is there a programming language that doesn't compile, but rather just translates into another language?
That makes no sense to me. My definition of compilation is "translating from one language (the source language) to another (the target language)".
Usually the source language is something written by humans and the target language is machine code (or asm), but that's not a requirement. In fact, many compilers are structured as multiple layers, each translating to another intermediate language (until the final layer emits code in the target language).
And it's not directly related to a language, but a particular implementation. We can take C, for example: There are C interpreters, C compilers that target assembler code, C compilers that target machine code (of various platforms), C compilers that target JavaScript, C compilers that target Perl, etc.
As for simplifying the implementation of a language: Yes, there are various kinds of code reuse that apply.
One way is to separate compiler front-ends (translate from source language to an internal abstract representation) and back-ends (translate from the internal abstract representation to machine code for a particular platform). This way you can keep the front-end and only write a new back-end if you want to support another target platform. You can also keep the back-end and only write a new front-end if you want to add support for another source language.
Another way is to use a full-blown programming language as the intermediate representation. For example, your new compiler might produce C code, which can then be compiled to machine code by any C compiler. The first implementation of C++ did exactly this. C has a number of drawbacks as a compiler target language; there have been efforts to create languages better suited for the task (see e.g. C--, which is used internally by GHC (a Haskell compiler)).
Today the most commonly translated language is JavaScript. The newer constructs of ECMAScript are translated to the old version to be compatible with older browsers. The translation is done by Babel.
There are also other languages like TypeScript and CoffeScript that are translated to JavaScript.
f2c translates Fortran 77 to C code. So it is probably an example for what you are looking for.
All general-purpose programming languages are Turing complete. That means any one of them can be translated into another.
When creating a new programming language, many designers often have their first prototypes translate their new language into one their are familiar with. This makes it easier to check if the translation is correct, that the new language is working correctly, and to share ideas with colleagues since it is machine independent.
When their design becomes stable, they make a front end to an existing compiler to do the compiling. Using an existing compiler has several advantages. Optimization is instantly available. The new language can access existing libraries. Compiling can be targeted to all the existing back ends, making the language available on different architectures.
Yes, this is one technique for creating new languages. The first experiments in what became C++ were translated to C for compilation. Taken from http://wiki.c2.com/?CeeAsAnIntermediateLanguage:
Examples of using C in this fashion:
CeeFront; the original implementation of C++, translated to C.
Comeau C++ (http://www.comeaucomputing.com/) translates C++ to C. It
is the first C++ compiler to provide full core language support for
standard C++.
Several Java-to-C translators out there (some translate Java source;
others translate JavaByteCode to C)
Many experimental language compilers use C as a backend, rather than
emitting assembly language directly.
SqueakSmalltalk's VirtualMachine is written in a subset of Smalltalk
which gets translated to C and fed to the C compiler. The
VirtualMachine used by Scheme48 is written in a StaticallyTyped
SchemeLanguage dialect called PreScheme which is compiled to C. (The
PreScheme compiler itself is written in full Scheme.)
Several SchemeImplementations compile to C (e.g. RScheme, Bigloo and
Chicken). These Schemes often use the technique described in
CheneyOnTheMta to provide support for ProperTailRecursion.
More recently, compilers targeting a subset of JavaScript capable of efficient on-the-fly compilation have been created - emscripten.
And if you count assembly language as well as high level languages, WebAssembly or other bytecode languages fit.
Related
I was looking at the Kotlin Github page and I noticed that the Kotlin language itself is mostly written in Kotlin:
I am just wondering, how is it possible for a language to be mostly written in it's own language? Wouldn't the compiler need to be written (in a different language) before you can even use the language being created?
The process of writing a compiler in its source language is called bootstrapping.
In fact, at its earliest stage, it involves writing the compiler in another (often a lower-level) programming language, supporting a reasonable subset of the features designed for the compiler's source language.
Then, using the subset of the features that were implemented in the first step, one can rewrite the compiler's code in the language it compiles. It gives you a compiler of a subset of the language that is written in the same language.
Afterwards, one can add new features (not using them in the code at first) and build a more powerful compiler each time, and so on iteratively.
Kotlin used the Java programming language for its initial implementation, then most of the Kotlin compiler's source code got rewritten to Kotlin. Now, most of new code that is added to the Kotlin compiler codebase is written in Kotlin.
It is possible to do OO programming in pure C.
Some strategies use pre-processor macros to make it easier and less error prone. Some strategies involve adding new syntax which is expanded to pure c by a pre-processor, along with a base object class and some methods for memory management.
It seems that Objective-C began as a project much like this
Do any tools exist that allow objective-c syntax to be processed to pure C?
Without having explored it, it seems do-able.
Just to clarify, I am not asking about compiling iOS code to other platforms, or asking about ports of the cocoa library to other platforms, I am wondering about ways of using oo techniques in pure-C, using Objective-C syntax and a preprocessor or precompilation step.
Portable Object Compiler. It's not capable of compiling modern Objective-C, but it sounds like it is perfect for what you're asking. Look here at a discussion of POC's shortcomings
The situation for C++ is more interesting. Cfront was the original C++ compiler that produced C code, but besides being long outdated it was commercial and cannot be (easily?) downloaded today. Fortunately, there is Comeau C/C++ which is supposedly very modern and standards compliant. It costs $50.
However, I wouldn't expect to get very readable C code from either of them (especially the full-featured Comeau).
It is possible to do oo programming in pure c?
Yes, as oo is a matter of philosophy. Look at glib and how you can do c style object: http://developer.gnome.org/glib/
Apple did it with Core Fundation: https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/CFDesignConcepts.html#//apple_ref/doc/uid/10000122i
By the way: Do any tools exist that allow objective-c syntax to be processed to object oriented pure c?
Yeah: gcc (GCC 4.6 according to Wiki, never actually checked ;)) and clang, tools that you are usin everyday.
This is the Objective-C Runtime who make the obj-c obj-cAble, so you need libobjc.A.dylib library too. You can write obj-c in pure c code, since all message '[]', '#' directive and other obj-c stuff are converted in c after compilation.
No it's not possible, as all special (non-identifier) symbols of Objective-C can not be used as preprocessor macros. At least not with the standard C preprocessor.
Other preprocessors may be able to define macros with non-identifier names, although I don't know of any.
When talking about preprocessors in the early days of Objective-C (and also about C++) it's probably (and in the case of C++, definitively) a custom made parser that instead of outputting assembler or objective code outputted C code.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When is a language considered a scripting language?
what is the difference between programming and scripting languages? I have worked on C/C++ for a while and now I started looking at Python, I was told it is a good scripting language this post.
But as I'm learning, I'm finding that everything that can be done with C till now can be done with Python! so what is the actual true difference between scripting and programming languages?
I actually believe the question is a bit misleading. Of course a scripting language is also a programming language. But there are differences:
Between Compiled and Interpreted Languages.
Traditionally a language like c is compiled into machine code that can be understood directly by a cpu. A "script language" on the other hand usually is not being compiled into machine code before execution but interpreted using an interpreter.
The advantage of an interpreted language usually is that it has a faster development cycle because no compilation is necessary and it is easier to move from one platform to another. E.g. python scripts can be executed on windows, linux, mac without changes.
The advantage of a compiled language on the other hand is that it executes usually much faster.
I used "usually" and "traditionally" very often because there are now technologies that make it much harder to draw the line. E.g. it is possible to compile python code directly into native code and there are also interpreters for c code. Also "Just In Time" compiler and virtual machines make it harder to draw here black and white.
More: http://en.wikipedia.org/wiki/Interpreted_language
Duck-Typed and Strong-Typed Languages
Usually script languages are duck-typed which means that a variable can be assigned any type and there is no or only optional checking of types. In compiled languages on the other side like C and C++ every variable is typed and it can and will only hold values of that type.
The advantage of a duck-typed language is usually that it requires less physical typing and less code (e.g. type names can be left of function declarations etc...) and it is easier to write reusable functions.
The advantage of a strong-typed language usually is that it "helps" the programmer finding bugs before running the application. E.g. the compiler would complain about type errors without the need to run the concrete line where the error is happening. Especially in big projects with many contributors this can become an amazing advantage.
More: http://en.wikipedia.org/wiki/Duck_typing
I was confused as to what is the difference between a Script and a Program, but a previously asked question Difference between a script and a program? clarified my doubt but that further leads me to wonder what is the difference between an Object being Scriptable versus being Programmable.
Not sure if this is what you're looking for but scripts are generally interpreted at runtime by another program which does something meaningful, whereas programs are typically executable directly on top of the CPU because they were compiled to assembly.
Notable exceptions are .NET managed languages and Java, which 'compile' to IL and bytecode and need some kind of runtime (CLR, JVM, DVM) to execute.
As noted by Michael Petrotta in the question you reference, scripts are generally interpreted and slowish , programs are generally compiled and fasterish. Compiled is often faster than intepreted because interpretation includes compilation at run time (vague and not always the case, but good enough).
Scriptable, to me, means that the object in question supports the interfaces required to be accessable from one or more script languages (for example, JavaScript and/or VBScript).
Programmable, to me, means that the object in question supports the interfaces required to be accessable from a programming language (for example, C++ or Java).
Interpreted and Compiled languages are all programming languages so it is all programming.
Summary: Scriptable vs Programmable are two vaguely synonomous terms.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Bootstrapping a language
What's the importance of having an interpreter for a given language written in the target language (for example, PyPy)?
It's not so much about writing the interpreter in itself - more about writing the interpreter in a high-level language, not in C. Ideally, doing so allows to change details of the implementation, and making the interpreter more modular.
For the specific case of PyPy, writing the interpreter and the core objects in (R)Python allows to retarget PyPy for targets (C, JVM, .NET, JavaScript, etc), and also allows to replace aspects such as the garbage collector.
I'm sure there are many different reasons for doing it. In some cases, it's because you truly believe the language is the best tool... so writing the language interpreter or compiler in the language itself can be seen as a form of dogfooding. If you are really interested in this subject, the following article is a really amazing read about the development of squeak. The current version of squeak is a smalltalk runtime written in smalltalk.
http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html
An added benefit is that if you implement good debugers and IDEs for your target language, they also work for your source language.
This way, you can prove that the target language is serious business, because being able to make it compile something is a sign that it is a good language.
OK, C++ and Java produce compilers as well... so maybe that argument is only half as good as it may seem.