Pure Lindies as Text Forms?

[orcmid]

A limitation of oFrugal is that REPL outputs are always canonical forms for obs.

Because there are no character strings and input-output in the oMiser computational implementation, it makes presentation of results in terms of a representation rather difficult.

The rules for pure lindies may provide an useful hack.

This might make the oFrugal output more complicated to produce and to understand.

This discussion is to ascertain how valuable this might be.

[orcmid]

A sequence of space-separated lindies is a form of applicative expression.

The ob-exp interpretation of

x y z

is as

x :: y :: z

and the question is whether it is more valuable to present that as

x y z

instead.

This makes obstring.txt more complicated and maybe it should not be for CFob after all. Maybe we want CFob to be the pure case without the hack.

[orcmid]

I am more-attached to this hack because it makes things like reporting test results and providing messages more straightforward. And one can form operands this way too.

This is a tiny bit like the LISP SEXPR use to provide list-structured operands and even texts to applications rather than always serving as a LISP EVAL expression. That involves the LISP reader (hack).

I didn't want to do that except for the fact that oMiser has no string data type and no good way to introduce one at what I want to keep the fundamental level.

That Lindies are bare symbols and have no individual applicative interpretations is intentional.

The pure-Lindy short-circuit is intended to provide evidence to users of where that is happening by trapping as high as possible. It also provides a kind of symbolic execution for confirming the operation of applications, as done for the computational interpretation of
combinators.

To do the same for an interpretation of pure Lindies as a kind of (actually-applicative) text is an unexpected wrinkle that I am becoming fond of. This does not involve the reader, so it is not about SEXPRs, and the illusion might be confusing.

Of course, it does not take anything to allow the input. The question is whether it should be provided in output.

The output case is still an invariant. On re-input, the output is the same, rather than a ::-combined list.

Finally, allowing it in the input does not require any change, though we might want to allow a non-lindy singleton terminator. I think the only non-lindy individual allowed in such an arrangement should be .NIL though.

A tricky case has to do with when a pure-lindy case is used as an operand to a non-pure-lindy operator. We already have that case, however.

[orcmid]

PROPOSED APPROACH

1. obaptheory.txt will be adjusted to allow trappable singleton cases. We will need to be careful about that, to provide consistency to users who exploit this.
2. determination of how to express these in output will remain to be done as an extension of CFob.

[orcmid]

To make Lindy text parseable, we need to have a terminator. The LISP solution is to silently use NIL for the empty list and as an explicit terminator. That won't work here.

It is difficult to come up with an idiom that has a differentiated empty/terminator case. There is [] as a case of .NIL which might seem a bit easier, although it makes an explicit ending.

The basic problem is that the eval of a b c is as a :: b :: c and we can have it print as a b c. But as an intermediate form it cannot be treated as a list structure the same as [a, b, c]. and [a b c] doesn't get what we want, producing (a :: b :: c) :: .NIL instead. We can make a b c [] work though.

For now we can just leave things alone and have applications decide what to do about the ending lindy when a lindy text occurs as an operand. We can do the applicative presentation.

PROPOSAL
The only modification is to have ap(lindy, .NIL) produce lindy :: .NIL rather than lindy :: '.NIL and have that count as pure lindy. When presenting a pure lindy text, any .NIL will render as [].

[orcmid]

I AM ALL WET HERE. IT IS NOT THE CASE THAT APPLICATION OF A NIL-TERMINATED LINDY LIST WILL APPEND THE OPERAND TO THAT LIST. IT MUST BE A .ARG-TERMINATED LINDY LIST.

[ ... ]

Reviewing the Bidding: Arrival at this point is by wanting a string of white-space separated lindies to be presented in the same form, providing an intended-interpretation of such a sequence as a form of text strings that can be manipulated as an emergent type and also produced in that format in output. The problem comes with wanting a terminator so that the last "bead" in such a sequence does not end up as a terminator. This clashes with the desire to have 0-singleton list structures. The use of .NIL or [] is an external convention that simply works so long as the result is not seen to be a pure lindy case.

So, is simply having ap(lindy, primitive) produce lindy :: primitive really OK? On resubmission of such a string, rather different things can happen (e.g., when .SELF or .ARG is the primitive). This is different than the .NIL case. Not exactly terrible: different. But the trace principle is violated. The assumption that an output can be resubmitted and result in itself appears to be violated although under eval, it looks like everything works. CHECK THIS FOR ALL PRIMITIVES.

We are passing the buck to the output procedure though. If that's too difficult, I may be going around in circles here, looping on the previously-unsolved problem.

[orcmid]

I got lost in this. There is not particular need for .NIL, and we don't have to do anything different if we don't want.

I think it is all right that (a b c) becomes the same as [a, b, c:], and we can pretty-print the second as the first. I think [a b c:] will also work but I need to verify that.

It is still annoying that the standard treatment of lists, with a bumper for an empty list is not quite right in this case.

I am looking at a number representation that reads well in the form [0 0 1 0:] (for Z2adic notation interpreted as the number 4). This will work well with other lindy sequences. Lists of lindies can still be written with a proper terminator, as[a, b, c]. and a b c [].

Still musing ... .

[orcmid]

It is confirmed that [a b c:] is a case of [<ob-exp>:] which is essentially just a b c in the extended format.

And [a b c] is a case of [<ob-exp>] which is [<ob-exp>, NIL:) so that's not quite right. The expression [a b c []:] will do that job though.

For enhanced output, the input form [0 0 1 0:] is not likely to be produced. And that's not the way to input that number, although it works just fine. But so does (0 0 1 0) and that's more likely to be the output without any tricky creation of list forms. I favor [0 0 1 0:] and I wonder how to provoke that output without making a mess, generally.

This is rather hokey. Although using [ ... ] forms will work, I think it is better to just use parentheses if needed. If a singleton termination is needed, that's going to be very tough unless it is [] or a parenthesized final term. In any case, I know this can work without any changes to the grammar.