This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Combinator Representation and Interpretation-Preserving Procedures #7
Comments
|
Just a check on understanding. Represented here means can be implemented , that is, computations can be done with them? Also, it means, that combinators are not first-class in miser but composed of some number of building blocks. I do not like macros (Python lacks them for good), but one powerful feature seems to be missing from miser, and I guess it's not even in the frugal-1: named reusable entities. For example, even with assembler language I can call routines by some names to reuse or I can put makefiles to different files and call by name. This is very powerful organizational technique, which is outside of scope for miser (this is fine), but does it mean it's up to implementation and computation environment or are there some blueprints that way? For example, obs "global" identity can become and issue I see. I believe in technical systems evolving in a more or less predictable way (ref to TRIZ here again), and in computing especially sub/supersystems are usually very fast to appear. So I tend to think on 2-3 supersystems' layers habitually (sometimes hard to stay inside a box). But the question was very practical: if I want to play with combinators in my playground, is there any standard way to call and reuse them at frugal-1 level or should I just invent something to go forward? |
For the inquiry into combinator representation, the idea is finding obs having computational interpretations that satisfy essential characteristics of combinators.
The diagram expresses the pattern I am offering for representation/interpretation. We will see how a chosen interpretation as combinators fits into that picture. There is more discussion of this under the topic "Computation as Performance" on the Facebook-page sketch I've been working on.
That's correct. Combinators are not first-class in oMiser. The only first-class entities in oMiser are obs. My hypothesis is that taking/providing combinators as first-class is a mistake. My concern, as a theoretical matter, is that the Church-Rosser condition is a negative result. How that matters, and where it impacts oMiser, remains to be explored in a definitive manner. |
That's correct about oMiser. There is no storage and identification of reusable assets. If you look at "The Software Project" diagram and description, it should be clear that oFrugal has that task. My thinking at the moment has been inspired by the SML/NJ REPL where the same problem is addressed. Update Based on recent experience of @rnd0101 in attempting a REPL, as reported in comments below, I have expanded (1-7, here) for what is intended as the eventual complete Read-Eval-Print operation of oFrugal. Update 2018-02-09 with further adjustments to an intended concrete syntax.
ob ^name = ob-exp; yield the same output ob-exp text form as that for the single statement ob-exp NOTE Keep in mind we are at 0.0.n in the early definition of oMiser and oFrugal software. Breaking changes must be considered likely. That's why mockups are exploratory and not the yet-to-be-introduced mainline source-code and its development/deployment. Experiments at this preliminary level is priceless and the willingness of such early exploration earns much appreciation and gratitude. |
|
Interesting, that now that I have implemented interactive frugal shell (with auto-completion and saving history), I see that certain things are a matter of taste. For example, I am using So for example if I were to design it, I't simply used plain identifiers for variables: And used them also without any additional syntax. For multilines I'd just added open "(" and the line can continue as long as there is no closing ")". Right now I've added |
|
Said that, there is good idea in APL (IIRC) - workspace. The whole workspace can be stored/loaded. And APL has |
So oMiser is not confluent? I have noticed, that when I forget to enclose combinator S, it is evaluated to some shorter form, which does not work as expected. Is it that my frugal/miser implementation still somewhat buggy or true behavior? |
|
I've found one surprising result: Does this match the proper comparison semantics or is it a defect in my miser implementation that enclosure does not affect comparison? Update: I guess, I am not using precedence axiom. |
|
And another one also bothers me: It is surprising, that something is evaluated to These are some other calculations with constructions from above: Unless it's some bug in my implementation, this may be a sign of pair's |
I think you are running into a pure-lindy-trace problem and some application-ordering matters also. When using lindies as application operator scripts, it is important to avoid premature determination of a pure-lindy-trace. Here, the So the unexpected result, Given all of that, I think the way to get what you want, is with using literal operands to the comparison and avoiding any automatic trace creation when it is the ob you want to use, not its applicative interpretation. |
|
That last of course gives the result, but raises the question of how miser can process complex ob structures of lindies? One more strange case, related: comparison depends on which operand has more enclosures. |
Let's take it apart. produces the expected and correct result. evaluates as ob.a(eval( has a few problems. First, as a practice I would use Secondly, Ahah! So the above application produces |
There's something I don't understand about this. It looks like a parsing problem. There's an extra "(" in front of the first Oh! This is failing to detect the special form eval( This seems to have worked properly in your evaluation of ap(ap(ap(cS,x),y),z) so I am not clear what happened. Oh, wait. I understand. You are using the functional sugaring, so it is interpreted as Try Note. Without adding an infix "=" another way to handle the pure applicative approach is by writing |
|
I promise things should not get any messier. You have found all of the idiosyncrasies, as far as I can tell. |
I don't know a better term. These are little "source"-level plug-in that are of partial scripts useful in writing common idioms that will arise. Let's revisit this question when there are some of those. |
|
Thank you for this effort. It is showing me places where the informal description needs more care. Also, I see some speed-bumps that need to be resolved by the care taken to specify the REPL functions, the input syntax, and the two-stage read-then-eval arrangement. I'll provide more over where we have been discussing that. |
|
What I've tried to convey with this example
is that I assumed the Of course, I understand, that sometimes evaluation needs to be guarded from happening (that is what is my understanding of backtick, which is QUOTE in LISP, if I remember correctly.). But I do not understand how can I introduce expression, which produces Again, I do not know how faithful my Python implementation is. |
|
I've changed implementation of equality in my Python's miser, introducing "state": pairs and enclosures are represented in state as tuples of subelements states, primitives and lindies' state is their name. Python automatically compares such structures, so hopefully this is desired comparison semantics for miser. Revisiting the above with more minimal examples: Now the picture is clear: both operands are evaluated, so single tick cant be distinguished from a lindy. |
|
I think, the equivalence of single quotations is understandable and is not an issue. I will open new issue for the Here: #10 |
Confirm that some primitives work directly as interpretation-preserving combinator representations, along with the non-uniqueness of representations.
Begin to layout the theoretical basis of the combinators in preparation for establishing their representation in oMiser.
The recursion cases in oMiser without use of a Y combinator are setup for consideration of how the Y-combinator is represented in the by-value handling of application in oMIser
A provisional Y combinator representation, cY is demonstrated as having the essential qualities of a Y combinator that only deapens when conditionally applied.
Tidying up some of the text and managing TODOs
The interpretation that will require preservation is that of functional type and the functional types of combinators give us minimum cases.
The Y-combinator development is forked from combdemo.sml for independent development and demonstration of this important case.
First full pass that works from combinators to functional types to interpretation preservation and the levels of computational abstraction around intended interpretations
The manual bracket-abstraction of script obs is compared with the composition of combinators for the same utility combinator. In only one case is there no difference.
… end of section 3 #7 Provide draft that works from theoretical combinators through functional type as an interpretation-preserving level of abstraction and interpretation of oMiser script obs as combinators
Connect the dots between combinators.txt, ob.txt, obap.txt, ob.txt, ob-exp.txt and the sound implementations in the SML/NJ mockup with combdemo.sml
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
In an important connection between computation theory and the oMiser computation model, the mathematical-logic combinatory functions, the combinators, are representable. Supporting combinators is characteristic of applicative- and functional-programming systems. There is a strong connection with λ-expression usage to be taken up later.
In the pure case, combinators are applicative entities that, viewed operationally, operate on combinators and yield combinators as results. With oMiser, there are only obs and functions on obs. Then how can obap.ap(p,x) and obap.eval(exp) be said to to achieve combinators when the arguments are always obs and all functions only yield obs?
The question is, "How do combinators arise, specifically, with oMiser?" And, "Of what importance is that for oMiser programming? What purchase does that give on aspects of practical software development?"
With oMiser, combinators are represented, not taken as given, primitive, or somehow directly present. An important aspect of the chosen representation of combinators is being interpretation preserving of suitable scripts to which combinators are applied. There is great utility beyond the "pure" case,
Combinator representation provides the first of many cases where higher-levels of abstraction are manifest by constructions using lower levels already at hand. With oMiser, this abstraction-raising depends on how structure ‹ob› is devised and exploited as a vehicle for stored-program computation via the chosen universal functions. This capability is representative of how the same is achieved with today's general-purpose computers and of how great utility is achieved thereby.
This question topic extends from the material in Question #2, employing notational variations introduced in Question #3.
The text was updated successfully, but these errors were encountered: