Sorry ran out of time to complete this.
My intent is to rearrange existing content out of existing pages that logically belongs together. I am a bit short of references at the moment, which I will attempt to correct. I will try to find time to add references, and go though and correct any problems.
I have re-appropriated an existing page which had a redirect through to Scope (computer science). I think the let expression has more significance in its own right, being the stepping stone through from lambda calculus through to modern functional language.
It is also significant as a construct for a named function, with restricted scope. This is significant because it avoids the problems involved in defining an anonymous function (see Curry's paradox).
I appreciate that the page is still a bit short on background, explanation and references. It also doesn't yet all fit nicely together.
Added links in to this page and removed the orphan tags. Finished removing the content that has been moved here to create this page.
That little problem has bothered me for a long time.
Notes on the problem
The result needed is,
If we start with,
So no point fiddling around with that. May as well start with,
The awkward thing is why doesn't this rule apply for Boolean F,
It applies for all other types, why not Boolean. Why do we need to use,
for Boolean. And then is there some problem still hiding in the woodwork here.
Its not the only rule that applies only to Boolean,
only makes sense if F is Boolean. What I am worried about is the derivation,
- ...... if lifting was allowed for Boolean F.
which is not true. The second problem that concerns me is if we could somehow counterfeit the Boolean type with another Boolean type that behaved like Boolean but was not Boolean. But then we would not have the rule applying if F was not actually of Boolean type.
The argument is the you need both rules to create the contradiction.
Only applies if F is Boolean, so by not allowing,
when F is Boolean, the contradiction is blocked. So I think it's OK. References ...
Narrowing is under construction.
The notation has changed from (c, v) to (v, l). c was a condition and now l is a set from which a condition is calculated. The order swapped around because it went (c, v) -> (c, v, l) -> (v, l). Anyway it was originally the wrong way round.
Using the list l as data to calculate the condition makes the function application rule less intuitive. I am not really happy about that. But it helps with describing narrowing, and removes the need for other handwaving.
Narrowing is described here within math, when it is really meta programming about math. Its a bit of a shoe horn to make it work in math. And then it is not completely clear how the narrowing is applied in meta programming.
Clear ideas in natural language, translated into math, get twisted around. There is no object identity other than the value that may be used. This is frustrating because the narrowing process is simpler than can be written in math. You don't write math, math writes you.
A lot of checking and examples still needed.
Probabilistic value sets
Value sets and probabilistic value sets
Moved to a new article Narrowing of algebraic value sets.
It was getting too big and was no longer a good fit with let expressions.
Problem with local scope
There is a problem if let expressions are considered to have local scope. It is basically the same problem as with lambda expressions. An expression,
This is OK if the scope of x is the whole expression. But if x was considered to have a scope local to the let expression, then x could be renamed to y,
which is no longer true. Not sure how to best deal with this as in common usage in functional languages the let expression is considered to define a function with local scope.