Lojban for Programmers Part 2: Implicit and Rearranged Sumti

«« Part 0 | « Part 1 | Part 2 |

This lesson, paralleling Wave Lesson 2 (read it!), teaches how to rearrange and omit sumti in your bridi, similar to named and default parameters in some programming languages. As this just builds upon and tweaks the concepts of the previous lesson, this will be a shorter post the Lojban part will be much shorter than the messy programming part.

Programming concepts

Parameter order

When making a programming language, it is arbitrary which order to require a function's parameters to be given in. In fact, C-like languages already have at least two different ways of ordering a function and its parameters.

1. functionName(parameter1, parameter2, parameter3, ...)
2. parameter1 mathematicalOperation parameter2

The first case may look like add(number1, number2) and the second may look like number1 + number2, each of which returns the result of adding the two numbers.

To list a third way of ordering a function's parameters, I must diverge from C-like examples and will drop to shell scripting, which treats programs as functions. This is how using named parameters looks for a hypothetical program ran from a Bash script.

3. commandName parameterAlpha="$THIS" parameter1="$THAT" parameterApple="$YOU_GET_THE_IDEA"

Assuming the program commandName is made to handle it, the caller can use however many parameters are needed in whichever order desired. However, without additional library support, the values received by commandName are going to look something like this:

args=[]string{"parameterAlpha=\"Contents of Bash variable $THIS\"", "parameter1=\"Contents of variable $THAT\"", "parameterApple=\"Contents of other var\""}

This gets messy on the receiving end. Also, the ability to make such a named parameter call depends greatly on how the receiving program is written, with many different ways of naming the parameters having to be remembered, potentially one for each program.

Ignoring the complications for the program receiving these parameters, things are still messy. Even if it's easy enough to read the named parameter call, writing it requires knowing the particular grammar and vocabulary of the command. Is the parameter to specify which server to connect to serverName, domainName, or remoteServerDomainName? Do you use parameter=value, -parameter=value, --parameter value, or something else entirely? There are several different standards and even more nonstandard programs. There is no way to know without looking at that particular program's documentation.

While optional and named parameters are nice if you know exactly how the program you're dealing with handles them, it's a mess, far more complicated than just taking a function, remembering its parameters, and calling all of them per standard convention in your programming language of choice. Lojban permits similar named and optional parameters for its selbri, but with standardized grammar and vocabulary.

Null and default objects

Sometimes in programming you want a simple instance of an object, something where you care more about the object's type than its contents.

For example, if you're writing a custom sorting routine for a collection of Entity objects, you might not want to waste time making a bunch of randomized dummy objects just to test the sorting function. So instead of filling out each Entity object's fields completely, you just get a default Entity object with object fields set to null and number fields set to 0. Then you change the sorting-relevant parts of the object and run the test, saving a lot of the mental and computational overhead of writing the whole thing.

How null and default objects are handled varies a lot by language within the C family, so I'm giving an example in the one I'm most familiar with, Go.

package main

import "fmt"

type Entity struct {
 id     int
 name   string
 age    int
 parent *Entity
}

func main() {
 fmt.Println(new(Entity))
}

This outputs &{0  0 <nil>}, indicating that new(Entity) filled the ints with the default of zero, the string with the empty string (note the two spaces between the zeros, with an empty string of nothingness betwixt), and a nil (Go's version of C's null, indicating a pointer that doesn't point to anything., i.e., a thing of the correct type but lacking content).

Lojban concepts

Vocabulary

Other than grammar terms that rearrange stuff, here's the only word for this lesson. As copied from Wave Lesson 2, here's a selbri:
vecnu = x1 sells x2 to x3 for price x4

Skipping selbri parameters

If you want to skip a sumti and have the listener know that it's just "something", then fill the appropriate sumti place with zo'e. You can also skip sumti, which results in an implicit zo'e.

For example, mi vecnu zo'e do means that I sell something to you [for some price]. Yes, it's that simple.

Rearranging sumti

Lojban allows sumti in a bridi to be rearranged via the FA words fa, fe, fi, fo, and fu. Respectively, they mean that the next sumti fills the x1, x2, x3, x4, or x5 position of the selbri. After using a FA word, the next place filled is the next one numerically. This is especially useful for skipping zo'e when skipping sumti.

For example, fi mi fa do dunda ti can be understood via x3 mi x1 do dunda [x2] ti, which becomes x1 do dunda [x2] ti x3 mi,which simplifies to do dunda ti mi. Recalling that dunda = x1 gives x2 to x3, the first bridi translates in English to I am by you given this, while the simplified Lojban translates to You give me this.

Note that dunda wasn't in its standard place. This is because the position of selbri, though conventionally after the second sumti, is actually arbitrary. However, without using fa or skipping the x1 sumti, the selbri cannot be the first word in a bridi.

For example, vecnu ti do fa mi means is sold, an item to you, by me. So with the right modifiers Yoda-speak is valid Lojban!

Lojban vs programming

I think the Lojban solution for optional and reordered sumti parameters to its selbri is like an abstraction and standardization of the named and optional parameter situation when calling a program from a script or calling some functions in some programming languages. Even being orders of magnitude more familiar with programming than with Lojban, I find the Lojban numbered and implicit default parameters much clearer than named and sometimes-optional parameters in programming. The only arguments I can think of for a programming language to be better at handling optional and named parameters are:

1. It might be easier to remember what something is and a unique name for it than just what it is.
2. The samtrosku specification has no known implementation yet.

However, as will be seen in Lessons 3 and 5, there are constructs for making unique (albeit formulaic) names for selbri parameters. Also, even without an implementation of Lojban-as-a-programming-language, it seems from the grammar that it would be simpler to think of optional and named programming parameters in Lojban terms.¹

</opinion>

Summary

Skipping a sumti with either explicit or implicit zo'e in Lojban is like passing null or nil as an argument to a function or letting the function use some default value. FA words indicate which selbri parameter a sumti is filling, like a set of programming keywords for switching which order you're filling a function's arguments in while maintaining meaning and skipping over implicit null parameters.

Closing

Make sure to read Wave Lesson 2. It can't hurt to get ahead with Wave Lesson 3 or look of some Lojban videos somewhere.

¹ Disclaimer: I'm learning Lojban because I believe that the linguistic relativity effects compounded over even my non-singularitarian expected remaining lifespan is worth spending hours each day for a year. Given this bias, I expect there may be a better argument in favour of named vs numbered parameters than I've come up with. Please add a comment if you've thought of such a reason.