Pika: Simplification

simplification.md

Simplification

Delegation

Delegation can be accounted for by making the delegate references into caller references, and adding an indirection to the call of the delegated actualization so that the caller now matches the intended delegate.

For example

# With _delegate_
printName: {
  print(Delegate lastName)
}

John: {
  lastName: "Wilkins"
}

John printName: printName

John printName() # > "Wilkins"


# With _caller_
printName: {
  print(Caller lastName)
}

John: {
  lastName: "Sagan"
  printName: {
    Parent Parent printName()
  }
}

John printName() # > "Sagan"

It is still to be seen if there are no side effects other than verbosity. There probably are.

Private data (not argumentable)

Empty values not intended to be filled with values provided by the argument can be accounted for by a using the Private Data Object design pattern.

For example:

actualizeMe: {
  fillable
  alsoFillable
  notSo: {
    privateProperty
    laissezFaire
  }
}

actualized: actualizeMe( "filling", "this one too", "private you say?" )

actualized fillable # > "filling"
actualized alsoFillable # "this one too"
actualized notSo # { privateProperty: Ø, laissezFaire: Ø }

In the last example, what should happen to the "private you say?" string? It all suggests that it should be stored within the actualized Description.

Re-complication

This leaves us an extraordinarily simple information model for the lower level Pika program structure. The thing is, the spirit of this model is to enable... I don't know how to describe it but by using an unnecesarily complex phrase: "iterative integration" of data into more and more complex structures by using the lesser possible amount of complexity in the underlying structures. Also, to provide a non-hierarchical, cyclic model for the abstract syntax. So, what's to complicate now that I've reached a two types, 3 and 1 properties-per-type structure? Essentially the Typing system, which allows no real integration of Descriptions since only one parent Type is stored in the resulting Description after the actualization.

Using both parents as Types raises several questions regarding theorical implicances and practical applications:

• Which Type will take precedence whenever a conflict appears? Or, stated in a more esoteric way: how should the new many-branched Type root be walked?
• Will it be possible to revert a Description's Type to that of "terminal" Type in order for the Description to be used as an argument in an actualization without side effects? Stupid question in a way since a simple algorithm for property extraction can be both added as a Description of even bundled into the core library.

In fact, thinking that straight, the original intended usage of Potentials in Pika (following the imperative tradition) was to treat the argument as an array rather than as an argument object. The fact that I can now throw a full fledged Description with a complete Typing tree into the mix is a novelty. I guess that since either throwing the full Description or using an anonymous arguments may be encouraged or discouraged by syntactic artilouges, I'd rather have the most powerful underlying structure available and allow the simplified usage (anonymous arguments) to avoid confusion in newcomers.

The thing is that Pika is about minimalism, and this is not minimalistic since the suggested extension can be represented by a programmatic extension of the actualization that keeps both the argument and the subject as references and acts as a proxy to accessing them following the algorithm suggested for multiple paternity.

What has just about striken me is that, as a matter of fact, Multiple Typing, as Delegation and so on are just design patterns particular to the Pika structure. My next aim is then mostly formulated: to boil down the core constructs to a minimum while keeping the residues and reformulating them as design patterns.