I decided to rename several characters in my Smash fanfic.

In summary:

• Job 1: Clear up the confusion between Celestia, Ceilidh, and Cela
  • Cela Porter => Rona Porter
  • Ceilidh Minh Bustamante => Siobhan Minh
• Job 2: Fix Sunny and Solaria
  • Solaria => Solana Sondager
  • Sunny Delight => Pleasant Beauty
• Job 3: Fix Alex and Alif
  • Alif => Leph

The First Great Renaming was changing the title and expy-izing the main characters when I restarted this fic.

I ficced up some background on the referee Starman, a minor character. I had wanted to tell his story in Season 1 but decided it wasn't a good fit, so this will probably all get cut. I could work it into Season 2. ( Read more... )

Via lobste.rs, the Elvish shell:

Pipelines in Elvish can carry structured data, not just text. You can stream lists, maps and even functions through the pipeline.

Not too long ago I was thinking that shells should bring in high level language features and pipes should be matched with data types. It sounds promising.

Optimizable Malleability

The life of a productive environment may look like:

1. High malleability - you can do almost anything, with few restrictions.
2. Exploration - certain workflows are found to be better than others.
3. Optimization - simplified interfaces increase productivity while leaving out lesser-used features.
4. Stagnation - The existence of a standard way of doing things discourages the development of alternative ideas.
5. Replacement - Somebody invests a new system that replaces the entire old system.

Examples of malleable systems and optimized systems:

• Assembly language lets you do anything, leading to goto spaghetti. C gives you formal looping and function call patterns along with a subset of assembly's features. Higher level languages have additional formal implementations of common programming patterns and lack some of C's features to prevent entire categories of bugs. Driver writers and OS programmers still need the lower-level features, but 90% of programming can be done without them.
• Text files allow you to store data in any format. Every Unix tool invented its own text file format. INI, CSV, JSON, and XML are types of text files that are optimized toward storing certain types of information.
• Tail call recursion is an optimizable subset of recursion.
• Excel lets you freely place data without structure. Access requires you to define the structure first.
• Static typing versus dynamic typing. A language could be dynamic by default with optional static typing and optional type constraints. In this case the optimized system (static typing) came first and the malleable system came later.

Stagnated systems and their replacements:

• Why aren't webforums based on Usenet/NNTP? The environment of HTML+SQL allowed for the development of alternatives at a lower cost.
• Why don't new languages use object files? The burden of compatibility is not worth it.
• Why aren't most programs made of shell scripts? Fewer features, security concerns, etc.

Reconsidering the notion of a "program"

Let us view the entire operating environment as a set of mechanisms for directing input to a function.

Consider the command line shell.

• The user provides the program with representations of the function's arguments. The arguments are not passed directly, but you provide a string that represents the argument. Code inside the program converts the string to a filename or URL, parses the data, and provides that as the argument to the function.
• The program provides standard input and output methods, using pipes
• The program may allow the user to set the initial state of the program, using switches

We could say that a program is a wrapper that sets state, has the standard input and output, and provides access to the desired function(s). Let us consider a future operating environment that separates these tasks.

• The future system could automate the generation of wrapper code.
• The future system may use dynamic type casting, late binding, just-in-time compilation, etc to rewrite part of the program based on the user's input.
• The future system might allow the caller to directly set global variables / class members by name, doing away with the need to parse switches.
• Inputs and outputs may be something other than raw byte streams. The pipes may have a class type. The system may provide a standard iterator for a given type and handle casting automatically. The standard Unix tools may be rewritten to work on interfaces.

Incomplete classes and comprehensive dynamic typing

Consider the evolution of classes.

• 1970s - C - A struct is, basically, a way to arrange data
• 1980s - C++ - A class is, basically, a way to arrange functions around the data they operate on
• 1990s - C#/Java - An interface is, basically, a definition for a set of functions that we will expect any given type to implement.

The struct, class, and interface are all key/value pairs.

Consider the function:

sub doStuff(x){ return x + 1 }

In the "message passing" concept we might consider x:Dynamic and expect the runtime to check whether the given x has a ._plus() method at call time. (A more complex system could check for this when the object to be passed as x is known.) In the "interface" concept we might check that x implements the INumeric interface which includes a ._plus() function. "INumeric" is a way of saying that a dynamic type will implement a standard set of methods, what C# calls a contract.

An interface might be seen as an incomplete data type. An incomplete data type might be seen as a type of filter. A data type filter could describe the partially resolved value of a dynamic type, or could be used to implement very strict typing.

interface IPercent:UInt8 {
  _value = 0..100 // Value is between 0 and 100 inclusive 
} 

interface asdf {
  foo:String and len = 0..8 // .foo will be a string whose length is > 8
  
  // let's propose something outrageous... 
  baz: fnord(_) between &("camel"), dronf("llama") and & > 3 
  // * we will have a .baz member
  // * the namespace will also include functions fnord() and dronf()
  // * the result of fnord(baz) has a comparator that puts its result
  // between the results of fnord("camel") and dronf("llama"),
  // * and the value of fnord(baz) will be greater than 3
  // * or else the program throws a type mismatch exception,
  // preferably at compile time 
} 

This would be of little use to a programmer, but might be useful to a compiler, runtime, or IDE.

// as written by the programmer
function doSomething(futz): 

// as interpreted internally 
function doSomething(futz:{
  foo:String = "foo" // string with a known value 
  bar():Int // an undefined function that returns int
  } 
)

The same sort of filter or incomplete class can also be used as a search object.

interface SalariesOver30000:Employee { 
  salary:Numeric >30000   
}

select SalariesOver30000 from Employees // pseudo-sql

Function constraints

A compiler could theoretically determine that it is impossible for a function to do certain things:

• a given function may not modify its inputs
• the function may not make any asynchronous calls
• the function may not open any additional inputs or outputs
• the function's inputs may have values known at compile time or runtime

A compiler could potentially use this information to optimize the function, possibly running it at compile time if enough information is known.

My TODO list for language design is to look into:

• intermediate languages
• continuation-passing-style (CPS) interpreters
• A-normal form (ANF) representations
• static single assignment (SSA) representations
• Haskell's universal machine and Higher Order Abstract Syntax
• read: static single assignment for functional programmers
• ANTLR

Has-A pattern:

class MyClass { 
 FooType foo;
 BarType bar;
}

• each MyClass allocates space for a FooType and a BarType.
• foo and bar establish their own namespaces.

Inheritance:

class MyClass extends FooType, BarType { }

• each MyClass allocates space for a FooType and a BarType.
• The namespaces for FooType and BarType are incorporated into the MyClass namespace.

So what's the problem? Something in FooType or BarType might overlap.

General outline of a solution:

• All namespace conflicts must be resolved by the programmer.

Considering specific examples:

1. Both FooType and BarType have a .x property?

• Solution 1: Forced upcasting. All attempts to access MyClass.x must be upcasted to the parent. All parent methods work on their own .x property.

2. Both FooType and BarType have a .fooMethod()?

• Solution 1: Forced upcasting. The compiler should warn if the programmer fails to resolve the conflict, and throw an error if the programmer tries to run MyClass.fooMethod() without overriding it. This can cause problems (see case 4).

3. MyClass has its own .x property?

• Solution 1: Override parent access methods. If the property is interface-compatible with the parent's .x property, the FooType/BarType methods will run on MyClass.x instead of their own .x properties. If the property is not interface-compatible with the parent's .x, the compiler should throw an error and refuse to compile. PROBLEM: FooType and BarType may intend for their .x property to mean different incompatible things or to hold separate pieces of information. Sharing the same piece of data will introduce bugs.
• Solution 2: Do not override parent access methods. Parents continue to operate on their own .x properties.

4. MyClass has its own .fooMethod()? Theoretically, this should override the FooType/BarType methods. However, it introduces a double-call problem.

• Solution 1: Override parent methods. This introduces a double-call problem. If both parents have a method called every second that calls their own fooMethod(), this causes the overridden fooMethod() to be called twice per second instead of once per second.
• Solution 2: Do not override parent methods. Parent calls to fooMethod() will call the parent version of fooMethod().

Conclusions

More thought needs to go into this.

• Multiple inheritance is fine until you have a namespace collision, and then you're in trouble.
• If you have the parent classes share data when both have a .x property, then you have the problems that each might treat .x as a different conceptual thing and that conflicting actions on the same .x may introduce race conditions that do not exist when each class uses its own data.
• If you do not have the parent classes share data, then you have multiple copies of what might be the same conceptual thing, updates to one do not affect the other, and the state of ".x" is unclear.
• If the child class .x overrides the property for both parent classes, then you risk the parent methods modifying the data in ways you did not intend.
• If the child's .foo() overrides the method for both parent classes, then you might get a double-call problem when methods in both parent classes call their overridden .foo() method.
• If the child's .foo() does not override the parent method, then you lose the ability to extend the parent class by having its .foo() method do something different.
• The programmer may want to resolve namespace collisions in a different way for different properties and methods in the same class.

This appeal ended up in my inbox:

(If you are not the person who is in charge of this, please forward this to your CEO, because this is urgent. If this email affects you, we are very sorry, please ignore this email. Thanks)

We are a Network Service Company which is the domain name registration center in China.

We received an application from Huayi Ltd on January 16, 2017. They want to register " hfb " as their Internet Keyword and " hfb .cn ", " hfb .com.cn ", hfb .net.cn ", " hfb .org.cn ", " hfb .asia " domain names, they are in China and Asia domain names. But after checking it, we find " hfb " conflicts with your company. In order to deal with this matter better, so we send you email and confirm whether this company is your distributor or business partner in China or not?

Here is a link to my "company" that distributes HFB. In fact, you can look at all of the HFB that I am distributing.