-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
oFrugal Syntax Updates Needed #24
Comments
The proposed solution to (3) is by using the declarative form
with ! signaling the special operation. Update 2023-07-01: I think I now want to use
so it is more like a type usage. I also want to save
for something, including different views of objects, such as one that retains binding names maybe. (I suppose, since these are command-signaling prefixes, I should use the Spanish forms :). The sort of thing I end up musing about in the middle of the night while recovering from a surgical procedure. |
I also want to change the definition of '〈binding-name〉1 to allow alphanumerics and also allow it to start with a special charafacter. So one could have ^0 and ^+ as binding names. Thia only works because of the prefix '^' and it allows some useful, and mnenomic, simplificatioins. |
I have a problem with the expansion of binding-name syntax in the previous comment. In the expanded syntax and semantics for oFrugal, there is an issue when a binding name occurs in an expression and there is no prior definition for that name. One way is to explicity say that results in a syntax error -- a mention with no referenced entity. Another approach, which is not foreign to other aspects of oMiser, is to have the result be the Lindy of the same name. In that case, to allow extended syntax we need to allow it for Lindies too. I am not thrilled about that. Another solution would be to have the result of an undefined binding name be a lindy of that name, with the ^ prefix, even though there is no way to enter such a lindy intentionally (well, only with foreknowledge that it is undefined). This fails with regard to the output being a canonical form that is oFrugal-environment independent. This then becomes a terrible hack, creating a serious ambiguity where there should be noe. Back to the drawing board. |
OK, the idea is to not use the ^ prefix but otherwise create a revealing Lindy that, just the same, cannot be entered directly? The prefix '?' might be applicable to this. I don't know about preventing entry though. So far outputs are enterable and I don't think that should change. Hmmmm |
Here's a trick. ^mumble and ?mumble are both binding names. If ^mumble is defined, either produces the defined value. If ^mumble is not defined, either produces ?mumble. Now, there are Lindies named ?something, and they can appear in a canonical form produced by oFrugal. However, you can't force the Lindy to exist via oFrugal, which treats it as a special form of binding name spelled the same as the Lindy of that form replaced if there is a definition when oFrugal establishes the semantics of ?somethiing. More hmmmm |
The notation mirrors method selection as argued for in Issue #24
Several matters need to be addressed in the Frugalese grammer, including ob-exp.txt.
requires back-tracking or creation of a reserved word. Whatever form is settled on, those two considerations must be addressed.
4. There may be a bug in the semantics for I〈obap-form〉.
5. There needs to be a "." operator that allows chaining, and fits with introduction of the Capsule Hack (#22). This would have "methods" group properly. In general, the productions
are such that the expression ^lambda.x(mumble) is sugar for (^lambda x)(mumble) while right-associativity is preserved with
The text was updated successfully, but these errors were encountered: