Theoretical Experiment: Imperative Operator
BlitzMax Forums/BlitzMax Programming/Theoretical Experiment: Imperative Operator
| ||
| Hey, this is EXTREMELY theoretical, I do NOT think about any real implmentation, its just on top of my head. And I would appreciate any opinion.. so.. here goes: Basically, you can see any equation in two ways: Either as a boolean evaluation, like .. If a = 1 .. .. or as an imperative .. a = 1 .. right? Now, what about an "imperative operator", that ENFORCES a certain equation to be true. lets say, that imperative operator is the !Exclamation Mark. Pseudocode, with the ! in bold: a = 1 ! 'alright, not a big deal ( a >= 0 ) AND ( a <= 10 ) ! 'now, that would be cool if it actually always checks out that interval, right? b <= 5 ! 'just another condition a^2 + b^2 = 125 ! 'so, here its to become usefull: a has to become 10, because b is max 5. I realize that an implementation would have to include some sort of computer algebra system.. but thats just the beginning: Local myObject:TBaseObject TExtendingObject (myObject) ! 'tadaa now its a TExtendingObject This would even have something in common with the lambda operator: ( f(x) = (x^2) ) AND ( f(x) <= 10 ) AND ( f(x) >= 0 ) AND Float(x) ! I know that idea is in a very chaotic state and there would be a LOT of loopholes to consider, but the basic concept should be clear.. now what do you think? Potentially useful? Interesting? Reinvention of the wheel? Incarnation of boredom [like so much other stuff in our society] ? |
| ||
| Question What should be the 'result' of this b <= 5 ! if B=3 a. B=TRUE b. B=3 c. Did I miss something? For the 'casting object thing' it seems logic but - I think - you lose the fact the MyObject has a different type from the original implementation... and this makes harder reading code if you 'jump' that particolar line. |
| ||
| I think it's trying to do far too many things, and actually it's just acting as a symbol that tells the program to switch to a different language for a bit. The casting thing would break type-checking: Local a:Float = 5.1 If SomethingUnpredictable() String(a) ! EndIf Local b:Float = a/2 When would you need to change the type of a variable and keep the same name instead of just using a different name and casting? Is the lambda example trying to define f(x)? It's arguably a more complicated line than normal lambda notation, and it doesn't really define f(x) - it says x^2 has to be between 0 and 10, but doesn't say what happens to values of x that don't obey that. To get the computer algebra stuff, just use a computer algebra system! You could even wrap it up in a function, so something like satisfy( ' x<10 and x>0 ' , scope) would do what you want. The function would either pick a random satisfactory value of x, or return an object representing the possible values, or something like that. Maybe have a look at prolog and haskell for the logic and lambda stuff, respectively. |
| ||
| Awesome, thanks for your replies so far!! @degac: Maybe you would have to differenciate a "can be" and an "is" operator .. but this experiment should at least be fun if anything, so what would you expect? @Warpy: I know, I know .. I am mixing up OOP, Computer Algebra, the Lambda Calculus, and who knows what.. And as I said, theres A LOT of loopholes to contemplate. Regarding the casting .. My guess is, that the runtime would have to keep multiple versions of the programs "universe" .. look at your example: Local a:Float = 5.1 If SomethingUnpredictable() String(a) ! EndIf Local b:Float = a/2 a/2 would ask for the version, where a is a float. Lets call this type of programming where everything is possible and the programer feels lost in an endless chaos of possibilities MULTIVERSE PROGRAMMING :) .. Oh well, to be honest, this theoretical experiment is mind-bending, even to me :}, considering that Local b:Float = a/2would be the same as b = a/2 AND Float(b) ! What I find personally interesting, is that, in a lot of ways, this reflects how we would speak out the definitions if we had to. |
   |