Programming Linguistics #6 — Pointing Fingers

February 2, 2016 · Posted in Programming Linguistics · Comment 

Part #5 of this series dove deeper into run-time type information with the type-of operator, and enabled us to have enumerated lists, as well as sequences of characters. Today, we’ll round out the type system by taking a look at unions, pointers, and references.

In addition to structures and classes, we have a third category of composite data types: unions. Unions allow us to access the same memory space in several different ways.

Another feature that we so far have not explored, are pointers and references. Through pointers and references, we can access objects by knowing where they are located, rather than needing to have the entire object on hand.

First, however…

Unions

In some cases, programmers need the ability to access data that is in the same memory location in different ways. The need to do this isn’t very common in a PC environment, but when working on an embedded platform, it often comes up. Having the ability to access the same memory location in multiple ways is often a great help when dealing with things like special function registers.

Read more

Programming Linguistics #5 — Type Away

January 26, 2016 · Posted in Programming Linguistics · Comment 

In Programming Linguistics #4, we talked about classes and the type system. This post will expand on those topics a little further.

In the previous post, I spent some time talking about run-time type information. There have been a few points that did not get covered: the type-of operator, the special Any type, enumerations, and strings. Let’s dive into those subjects, shall we?

Read more

Programming Linguistics #4 — Back to Class

January 19, 2016 · Posted in Programming Linguistics · Comment 

In part 3 of this series, I’ve talked about what namespaces and functions would look like in my hypothethical programming language. This part will start on the subjects of composite types and run-time type information.

Composite types are an invaluable part of modern programming languages. They allow us to take a collection of related variables and treat them as a single unit, which is great, because not many things can in practice be represented as a single numeric value.

In my language, a distinction would be made between two major variants of composite types: structures and classes. Even though they would be largely the same in terms of how the compiler treats them, there is a semantic difference between the two. Classes are collections of variables (properties) and functions (methods), that support many advanced features like inheritance, overloading, visibility, and so on. Data structures, on the other hand, are merely a collection of variables — they do not have methods, properties are always considered public, and they don’t support inheritance or other more complex features.

Read more

Programming Linguistics #3 — Functional Functionality

December 15, 2015 · Posted in Programming Linguistics · Comment 

Part two of this series went into a few things about the compilation process, modules, and established some of the basic data types and operators that our little programming language would have. In part 3, we’re looking at namespaces and functions.

As I’ve stated in part 1, my hypothetical language would be object-oriented. To me, it only seems natural that this is a thing, because any kind of usable data doesn’t limit itself to one or two variables. Instead, it consists of many variables grouped together into logical structures. The first thing that people try to do in a purely functional language is figure out a way to represent their data structures, and what you end up with is typically something similar to an object-oriented approach, but a lot less pretty.

Read more

Programming Linguistics #2 — Second Things… Second?

December 8, 2015 · Posted in Programming Linguistics · Comment 

In the first post of this series, I started outlining some of the basic underlying concepts of a programming language if I were to design and build it. In part 2, we’ll be looking at the first little glimmers of actual code!

If you’re familiar with languages like C or C++, you’ll understand the concept of header files. In languages like these, header files contain definitions for variables, types, classes, and functions, which are then implemented in source files. Other source files that would like to make use of the things defined somewhere else include just that header file to get the definitions, leaving it up to the linker to actually piece things together.

When you look at how compilers for these languages work, it’s understandable why a mechanism like this is needed. If you were to simply include the full implementation of a class or function in each source file that needed it, it’d take a lot longer to compile the project, and the linker is left with dozens of copies of the same code, not knowing which one to actually use. But especially if you’re not a seasoned programmer, understanding why header files are needed, how to write them, and what things belong in which file, can be very confusing subjects. And dealing with things that depend on eachother can quickly become a nightmare even for experienced developers.

Does it really need to be that difficult?

I think not.

Read more

Next Page »

A Soul Waking