Tag Info

Hot answers tagged

96

In layman's words: All programs can have bugs. Compilers are programs. Ergo, compilers can have bugs.


45

Yes You tend to find them more in languages that are actively being developed than in those that are relatively mature (and thus don't see a lot of change on a frequent basis). This is probably why most languages are released at various 'stages' of stability. A nightly build is far less likely to be stable than a release candidate, which itself is less ...


22

There can bugs even in hardware; a famous example is the Pentium FDIV bug. Without doubt there is the possibility that the compilers contain bugs.


21

Yes, you are missing something. Encapsulation is often described with metaphors of "hiding" or acting "defensive", as if client programmers were your enemy and you had to act stealthily and sneakily to defend yourself against their evil intentions. That is sometimes helpful; for instance, if you program extremely popular frameworks that have to maintain ...


20

It's worth noting that languages are not interpreted or compiled, but rather language implementations either interpret or compile code. You noted that Ruby is an "interpreted language", but you can compile Ruby à la MacRuby, so it's not always an interpreted language. Pretty much every Python implementation consists of an interpreter (rather than a ...


17

It is neither. Objective-C is a programming language. A programming language is an abstract concept. A programming language is a set of mathematical rules and definitions. Programming languages aren't compiled or interpreted, they just are. Compilation and interpretation aren't properties of a programming language, they are properties of, well, a compiler ...


13

It's important to remember that interpreting and compiling are not just alternatives to each other. In the end, any program that you write (including one compiled to machine code) gets interpreted. Interpreting code simply means taking a set of instructions and returning an answer. Compiling, on the other hand, means converting a program in one language to ...


13

Various comments have pointed out several ambiguities in the question and nuances to the answer, but the simple answer is no. The JVM and .NET Framework are Just-In-Time Compilers. They are still compilers, and do all of the work of a compiler. They take an intermediate language (bytecode), optimize it, and convert it into machine code. The only difference ...


13

The simple answer to your question is to try Lisp, preferably in conjunction with SICP. Then you will be enlightened. That said... Code is Data Most languages make a sharp distinction between code and data; Lisp does not. This makes it possible to, for example, trivially write a Lisp parser in Lisp, and to manipulate Lisp code within Lisp. The best ...


12

Python will fall under byte code interpreted. .py source code is first compiled to byte code as .pyc. This byte code can be interpreted (official CPython), or JIT compiled (PyPy). Python source code (.py) can be compiled to different byte code also like IronPython (.Net) or Jython (JVM). There are multiple implementations of Python language. The official one ...


11

The Python documentation, in the Lexical Analysis section, describes briefly how the indentation parsing works. In short, the tokeniser generates special INDENT and DEDENT tokens that are used by the parser when deciding where blocks of code start and end. These tokens (roughly) correspond to the { and } tokens in C-like languages.


9

There are two options here. 1) Don't implement if as a function. Make it a language feature with special semantics. Easy to do, but less "pure" if you want everything to be a function. 2) Implement "call by name" semantics, which is much more complicated, but allows compiler magic to take care of the lazy evaluation problem while keeping if as a ...


8

There is no technical standard that defines a scripting language. It's just a word that is defined by common usage, and like any other word in common usage, there is no guarantee that all the usages are consistent. Tackling your specific questions: The dynamic code generation they are talking about is machine code. In a classic interpreted language (think ...


8

Remember that whitespace appears as just another character to the interpreter. A tab is 0x09 in ASCII A space is 0x20 in ASCII An interpreter is little more than a pattern matcher that then triggers predefined rules.


8

Compilers and interpreters are software too, and thus they aren't free from any of the problems of other software. This is an example from a compiler as recent as MSVC 11 (2012), and here's an article on how they test the backend.


8

A processor executes machine instructions. They are the only thing that a processor understands. Java bytecode is an intermediate, compact, way of representing a series of operations (for want of a better term). The processor can't execute these directly. The Java Virtual Machine processes that stream of bytecode operations and interprets them into a ...


7

This definition would clearly put the usual execution of Java bytecode in the domain of interpretation, no matter how much JIT compilation is done. I have encountered opinions in discussions on this site that clearly and vehemently state the opposite, i.e. that Java Bytecode execution thingies are compilers. Well, the two definitions aren't mutually ...


7

Here is a more recent paper by Simon Peyton Jones on the Spineless Tagless G-machine, which was (and still is) used as an intermediate language in the Glasgow Haskell Compiler: Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine (1992).


7

Yes, but more than that. All of the interpreter's code is interpreted by a lower level, including the "scan a piece of code" step. However, there are less levels than you think - more than three levels is rare. Jython is one example of an interpreter running on an interpreter. It runs Python code, and is itself written in Java, which is interpreted by a ...


7

Why is the study of an interpreter that is written in the language it interprets so emphasized? In general, studying an interpreter gives you insight into its language and features. In general, studying code in a programming language is like practicing a spoken language by listening and reading: it familiarizes you with what that language can do, how ...


6

TD;DR: Strings are mutable. Symbols are not. Strings and symbols serve different purposes. an interpreter still has to parse the word that you typed in order to match it to a symbol :foo == "foo" could be determined by interning the string or turning the symbol into a string. In any event, if the interpreter interned every string it saw, it would have ...


6

There are many differences. First of all, think of the difference between a bytecode interpreter and a language interpreter. It's easy to interpret bytecode, because all commands follow a predictable format, but interpreting a language involves parsing and lexing -- operations that can be quite taxing, depending on the language. C# and Java don't only ...


6

This brings back the old times... I have a copy of the book, 3rd printing, 1975. I checked your listing and it's non-original. In the original source code the statements have no spaces and assignments have the keyword LET. For example 200 LETK=M:GOSUB600 The dialect is DIGITAL PDP-11 BASIC (not Basic-plus or BASIC-80). From experience, not all of these ...


6

An interpreter is generally understood to execute a program without compiling the program in a separate step. However, most modern interpreters do not interpret the source code directly – this isn't really possible anyway for anything more complex than BASIC. Instead, they first parse the code, then produce an intermediate representation, and finally execute ...


6

A VM is a piece of software that offers a machine-like abstraction. In the context of virtualization, a VM might abstract hardware resources. In programming language VMs, the VM offers a machine model, e.g. with a specific instruction set, a number of stacks, and a memory model. It is true that we can interpret any language as an instruction set, but ...


5

Dynamically compiling to JVM byte-code is essentially out of the question, because of the difficulty of implementing the stated feature set (excluding first-class functions) using a virtual machine that is not designed to support it. There are a lot of languages supporting most of the features you describe already that compile to JVM byte-code (JRuby, ...


5

In CPython, allocation of tuples (basically immutable lists) can be slightly faster than an allocation of the equivalent mutable type with the same items. I vaguely remember similar rumors about immuable sets, but timeit didn't confirm it. Tuples can also be smaller than lists, from a few bytes to 50% (if you hit a spot where the list had to resize, and ...


5

It would probably be easier to use a build tool, like Ant. You could have a target to compile, a target to run your tests, a target to run, and so forth. You can set up different dependencies between them (for example, always make test clean your build files and compile before running). Alternatively, a shell script would be the next best bet. However, that ...


5

No, it is definitely not the usual to throw away good analysis results. For a stark difference you may want to check out the Scala compiler. It is based on execution phases and you can add plugins which will be executed after certain phases. It is particularly interesting to place your plugin after the typing phase, because that gives you all of the inferred ...


5

Most languages do something like #1, that is, they specify a particular binary encoding, but said encoding is almost invariably IEEE-754 because that is the floating-point standard that a majority of architectures implement. A “double-precision” IEEE-754 floating-point number is defined to be 64 bits. Examples: The Java class file format specifies the ...



Only top voted, non community-wiki answers of a minimum length are eligible