Three Dollar Quill

Yesterday I mentioned having some weird ideas to try out for NABTO's syntax. I've been thinking about them some more, and I figured I could try describing them.

Here's the basic idea: the same underlying semantics can be represented with different syntaxes. See, for example, Hy, which allows writing Lisp code that ultimately runs on the Python VM. So, I can experiment with how different surface syntaxes work to express the concepts in NABTO without worrying that it will compromise the underlying semantics in some way. The basic rule I think I need to follow is that a language concept has to either map to an idea that I want to take from another language, or it needs to be possible to implement it as a local syntax transformation.

With all that said, researching for NABTO has exposed me to a bunch of different ways to express concepts, and, like, they're fine, but... So, what set this off is how unfamiliar the type construction syntax in OCaml is, but then I found myself considering the corresponding syntax in other languages, and the way that many widely-used languages represent function application... Maybe it's just because some of my coworkers don't seem to have a problem writing horrifyingly long parameter lists, but I think the usefulness of making functions in programming visually resemble functions in mathematics breaks down when simply enumerating the parameters (not even explaining what they're for) looks like it would take a full paragraph of prose.

Well, I don't know how effectively I'm "advocating" for anything, but I'm not saying nobody should ever write a fifteen-parameter function. I just think that they should work to justify the contribution of each parameter to the cohesive concept that the function represents. f(x, y, z) is good enough as it goes, but I've found myself longing for something a little more verbose. More talk. Perhaps a... small bit more talk?

I don't see many people using Smalltalk, and I'm not sure if Objective-C got traction for any reason besides "On Mac, you kind of had to use it", so the idea I'm dancing around, of expressing a function as a phrase, with the parameters slotted into predetermined gaps in the function's name, may alienate some people. To them, I say, "Don't worry! NABTO isn't object-oriented in the Smalltalk sense, so this is probably going to also alienate the people who were nodding along before."

Let's get some examples. Suppose you have a list called lst. In Python, you'd get the length of it by calling len(lst), or maybe lst.__len__() for... some reason. In OCaml, length lst or lst |> length. In Koka, length(lst) or lst.length.

I am pondering something like length-of: lst. In this, a typical function would be named as a noun phrase with one or more gaps within it. I'm currently leaning towards omitting articles for the sake of brevity. If I put them in, they'd end up functioning as a means of distinguishing values (have articles) from types (don't have articles). But for the moment I'd rather see how well things go with a mild headlinese influence. ("For moment, rather see how things go with mild headlinese influence"?) Once I have the mental image of code mimicking prose more closely, I imagine stuff like replacing the = in let ... = with be, and changing out Koka's := operator for set ... to.

Not all functions "return nouns", though. A function returning () must be some kind of verb, and a predicate is very much like an adjective. Therefore, suppose that we allow to ... do as an alternative to let ... be, and allow a sort of "one-argument pipelining" with an is operator. So, like if 4 is even:: then ..., and even:: could be defined like when n is even:: then .... Or iff n is even:: then .... I'm not seeing good sugar for something like element: e is-in: l, so maybe that needs to settle for let element: e is-in: l be ..., unless it's permissible to use the non-is syntax in iff ... then as well.

One obstacle to this idea is that I'm not always sure what noun to use for various higher-order function concepts.

For pipelining, I have an idea that amuses me: let somewhat-large be fibonacci-number: 1700; factorial-of: that. That is, using that in all code like _ in the Python REPL. And speaking of _, increment: number by: _, literally letting the function definition fill in the blank.

There is a lot of syntax to try and fit into this paradigm, but I want to see how far I can push this.

For now, I'm going to wind down.

Good night.