Replies: 18 comments 5 replies
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Said that, there is good idea in APL (IIRC) - workspace. The whole workspace can be stored/loaded. And APL has |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
I promise things should not get any messier. You have found all of the idiosyncrasies, as far as I can tell. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I think, the equivalence of single quotations is understandable and is not an issue. I will open new issue for the Here: #10 |
Beta Was this translation helpful? Give feedback.
-
|
Looks like oMiser supports normal combinators quite easily. One interesting question is: Does it support SF-calculus without any artificial encodings? That would be really interesting as SF-calculus can do things SK combinators can't. |
Beta Was this translation helpful? Give feedback.
-
I looked at http://lambda-the-ultimate.org/node/3993 and note there are a variety of problems with the so-called SF-calculus. The crux is the need to be able to distinguish the entities. There is no such capability in "pure" combinatory logic. While SF-calculus is claimed to be more expressive than the SK-founded combinators, that does not support a claim that SK can express functions that SK cannot. We do not have to dig into that, however. For oMiser, we demonstrate a representation of the SK combinators and that is sufficient for a claim of Church-Turing computability. That claim is strong enough to allow assertion that a computable SF is representable in oMiser. That does not mean we have to produce it. It is more profitable to demonstrate a Universal Turing Machine. There is more here:
It is a Miser Project goal to sharpen these distinctions around how we accomplish representations via intentional use of obs as representations of functions having intended functional type. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, of course SK-calculus is capable of doing SF-calculus by special encodings / representations, and by extension, oMiser. My note was more an observation, that maybe oMiser can do SF-calculus directly, which gives more expressiveness, kind of. As for oMiser representing Turing machines, there are some quite minimal ones out there (UTMs), but do you already have some ideas on how to encode the tape and state table in an ob(s)? There are probably quite many ways. But this is probably for another discussion. |
Beta Was this translation helpful? Give feedback.
-
I don't see what is accomplished by having SF-calculus directly. oMiser doesn't have SK directly, and there is no dependence on "normal forms." The equality in oMiser is of obs, not represented functions. How would F work in this situation? |
Beta Was this translation helpful? Give feedback.
-
Yes, there are straightforward encodings for the tape, the admissible marks, and the table of states and their rules. I suspect that tail-recursion has to be available to avoid stack-depth limitations. I will add something about that. |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions