TRANSCODE Explorations into the Code Transcendental.

Revelation Knowledge

September 4, 2013

I just had a revelation about programming languages.

Coming into this project, my primary goal was to rate a Forth derivative, that added types, polymorphism and functional-orientation to the language. That goal is proceeded reasonably well. However, in the course of thinking about all the varying aspects of the design I hit upon a very interesting concept. I asked, “What does the computer know?” In other words, how are we really informing the computer about our systems as we program. It only stands the reason that the more the computer knows the more we easily we can communicate our intent.

So lets start with the bread and butter the algorithm, and seeing that we want to stay in the realm of functional-programming ultimately will strictly speak of functions. But to proceed, lets get our barrings by asking what other languages tell the computer about such these things, whether they be procedures, functions or methods.

Forth is probably the most basic in this regard of all languages, with the exception of Assembly. It doesn’t tell the computer anything at all about a word (Forth’s term for these things) other then the procedure by which it is calculated. Some Forth words provide terse stack diagrams but they are simply comments, ignored by the computer.

Other languages, like Ruby, are essentially the same as Forth. Ruby is a dynamic language, so it doesn’t provide types for method arguments. To a limited degree names are provided for them, but they are promptly thrown away by the interpretor, so the computer is no more knowledgeable in that regard either. We do get one piece of extra information though. We can ask Ruby what the arity of a method is.

Python takes us a tad step further with regards the argument names. One can pass arguments to a method by name. That’s an improvement, but that’s about as far as it goes.

On the other side of things, there are languages like Java which are very strictly typed. But the types do little more than inform the compiler how to do it’s job better. In the language itself we can’t really ask about them. The names of the parameters are still ultimately disposable to the computer. (I wouldn’t be surprised if there is some insanely complicate reflection library out there for Java that would make some of this possible, but regardless it is not part of the real language.)

Then there are languages like Haskell which are strictly typed and can tell us all about those types.

Haskell’s about the state of the art at this point. There isn’t a language I know of that informs the computer more about it’s functions.

So then I asked, what would be a knowledgeable design such that the computer would know about these things we computers use day in and day out, and really be able to converse with us about them, so to speak. Well, lets break it down. What is there to know about a function?

  • Arity
  • Types of the arguments
  • Types of the return values
  • Name of the function
  • Name of the arguments
  • Definition of the function

Beside these, it may even behoove us to inform the computer about aliases for the various names, so it is easier to talk about these things for different programmers who might not be as with the code, or just to give us some programmer to speak more naturally, rather than always being so tortured to use the exact term.

Lets try and example, by writing out some pseudo-code for a function. Let’s keep it simple, say, calculating the tip for a check.

function tip(amount, percentage)
  typeof amount Currency
  typeof percentage Float

  default amount $0
  default percentage 20%

  aliases percentage percent pnct pct
  aliases amount price cost

  definition amount * percentage

  return-type Currency
end

aliases tip gratuity

But notice we also said “tip for a check”. That means something, so in our pseudo-code lets try to express that.

context tip check

aliases check bill

Okay. So what do we have after all that? Well, at the very least we have a way to speak to the computer about the various parts of our function.

tip.parameters  => [amount, percentage]
tip.return_type => Currency
tip.parameter(amount).type  => Currency
tip.parameter(pcnt).default => 20%

And so on. We can also call the function of course, but we could do so in unique way now. We can do it in an object-oriented way. After we do have a thing that is our function.

mytip = new tip
mytip.amount = $100.00
mytip.return  => $20

Now in the larger scheme of things, if that is all there were it might not get us too much further than the programming languages we mentioned above. But, we might now be able take all this new found knowledge granted to the computer about our program and start asking it to do some things we might normally do ourself.

For example, lets describe to the computer the concept of paying for lunch.

function pay(bill, tender)
  type bill Bill
  type tender Currency
  definition
    tender - (tally + gratuity(pcnt: 20%))  # this right here!
  return-name change 
  type change Currency

object Bill(menu-items, tax)
  type menu-items List(Product)
  type tax Percentage

function tally(bill)
  type bill Bill
  definition
     net = sum(bill.menu_items.each.cost) 
     net + net * tax
  aliases tally price cost
  return-type Currency

object Product(name, price)
  aliases price cost
  type name String
  type price Currency

Look closely at the line tally + gratuity. Notice we didn’t say bill.tally + tip(bill.tally). Not I know my pseudo code doesn’t really get us to the point where it’s clear how we can be so concise. But I think the basic notion is there. The idea is that by explicitly defining the various parts of our model, drawing relationships between those parts via aliases then the computer itself can start to make the connections between the return values and the input parameters for us.

I suspect if this kind of approach is taken to it’s natural conclusion, it should ultimately allow us to write much more reusable code, write that code in a much more natural and information rich manner.

Taking a step back, I believe it would be too much of undertaking for me to endeavor upon at this point. Nonetheless it does move me in a smarter direction with March –to make the language more knowledgeable.

← All posts