I have a parser for math expressions. I need to redefine the QDoubleSpinBox class so that metamatics can be entered into it even after pressing enter. He figured them out. The problem is that the textFromValue method always works on input. That is, entering sin (10) +10 will calculate two values. First sin (10) and then sin (10) +10. I need it to be calculated by pressing enter or after changing the focus, but when changing the focus, the text in the field itself did not change, to the calculated expression that was written there. And the value should be received via a signal, changeValue.
Related
The following &greet function is pure, and can appropriately be marked with the is pure trait.
sub greet(Str:D $name) { say "Hello, $name" }
my $user = get-from-db('USER');
greet($user);
This one, however, is not:
sub greet {
my $name = get-from-db('USER');
say "Hello, $name"
}
greet($user);
What about this one, though?
sub greet(Str:D $name = get-from-db('USER')) { say "Hello, $name" }
greet();
From "inside" the function, it seems pure – when is parameters are bound to the same values, it always produces the same output, without side effects. But from outside the function, it seems impure – when called twice with the same argument, it can produce different return values. Which prospective does Raku/Rakudo take?
There are at least two strategies a language might take when implementing default values for parameters:
Treat the parameter default value as something that the compiler, upon encountering a call without enough arguments, should emit at the callsite in order to produce the extra argument to pass to the callee. This means that it's possible to support default values for parameters without any explicit support for it in the calling conventions. This also, however, requires that you always know where the call is going at compile time (or at least know it accurately enough to insert the default value, and one can't expect to use different default values in method overrides in subclasses and have it work out).
Have a calling convention powerful enough that the callee can discover that a value was not passed for the parameter, and then compute the default value.
With its dynamic nature, only the second of these really makes sense for Raku, and so that is what it does.
In a language doing strategy 1 it could arguably make sense to mark such a function as pure, insofar as the code that calculates the default lives at each callsite, and so anything doing an analysis and perhaps transformation based upon the purity will already be having to deal with the code that evaluates the default value, and can see that it is not a source of a pure value.
Under strategy 2, and thus Raku, we should understand default values as an implementation detail of the block or routine that has the default in its signature. Thus if the code calculating the default value is impure, then the routine as a whole is impure, and so the is pure trait is not suitable.
More generally, the is pure trait is applicable if for a given argument capture we can always expect the same return value. In the example given, the argument capture \() contradicts this.
An alternative factoring here would be to use multi subs instead of parameter defaults, and to mark only one candidate with is pure.
When you say that a sub is pure, then the you are guaranteeing that any given input will always produce the same output. In your last example of sub greet it looks to me that you cannot guarantee that for the default value case, as the content of the database may change, or the get-from-db may have side-effects.
Of course, if you are sure that the database doesn't change, and there aren't any side-effects, you could still apply is pure to the sub, but why would you be using a database then?
Why would you mark a sub as is pure anyway? Well, it allows the compiler to constant-fold a call to a subroutine at compile time. Take e.g.:
sub foo($a) is pure {
2 * $a
}
say foo(21); # 42
If you look at the code that is generated for this:
$ raku --target=optimize -e 'sub foo($a) is pure { 2 * $a }; say foo(21)'
then you will see this near the end:
│ │ - QAST::IVal(42)
The 42 is the constant folded call for foo(21). So this way the entire call is optimized away, because the sub was marked is pure and the parameter you provided was a constant.
Is the following add() function referentially transparent?
const appState = {
runningTotal: 0
}
function add(x, y) {
const total = x + y;
appState.runningTotal += total;
return total;
}
I'm unsure of the answer due to a handful of definitions I've found for referential transparency. Here are some in the order of my confidence of their correctness.
A function is referentially transparent if:
It can be replaced by its value and the behavior of the program remains the same
Given some input it will always produce the same output
It only depends on its input
It is stateless
Given each of the definitions above I would think the answer is:
Maybe - I think it depends on how appState.runningTotal is used elsewhere in the program, but I'm not sure.
Yes
I'm not sure - It only depends on its input to produce the output, but it also uses appState in the body of the function
No
Back to the specific question: is add() referentially transparent?
Thanks in advance!
P.S. - please let me know if I'm conflating multiple concepts, namely the concept of a pure function.
No, it isn't a referentially transparent function.
Referential transparency refers specifically to the first criteria you have listed, namely that you can freely substitute the values on the left and right hand side of an expression without changing the behaviour of the program.
add(2,3) returns the value 5 but you cannot replace instances of add(2,3) with 5 in your program because add(2, 3) also has the side effect of incrementing runningTotal by 5. Substituting add(2, 3) for 5 would result in runningTotal not being incremented, changing the behaviour of your program.
I'd go with
Maybe - It depends on how appState.runningTotal is used
as when it is not used, then it can be ignored. Obviously it is global state, but is it just for debugging or is it part of your actual application state? If the latter, then the function is not pure of course - it does change the state and replacing a call with the result value (or doing unnecessary calls whose result is dropped) would change the behaviour of your program.
But if you do consider appState.runningTotal to not be part of the semantics of your program, and non of its functionality depends on it, you might as well ignore this side effect. We do this all the time, every real world computation affects the state of the computer it runs on, and we choose to ignore that when we consider the purity of our functions.
A pure function is referentially transparent. I call it "copypastability", aka you can copy paste each part of referentially transparent code around, and it'll still work as originally intended.
All of the four criteria have to be fulfilled, although you can shrink them to the first statement. The others can all be inferred from that one.
If a function can be reasonably replaced, that means you can replace it with a map/dictionary which has input as keys and outputs as values. So it'll always return the same thing on the same input. The same analogy works just fine with the "only depends on input" and "stateless".
I want to analyze the pointer values in LLVM IR.
As illustrated in LLVM Value Class,
Value is is a very important LLVM class. It is the base class of all
values computed by a program that may be used as operands to other
values. Value is the super class of other important classes such as
Instruction and Function. All Values have a Type. Type is not a
subclass of Value. Some values can have a name and they belong to some
Module. Setting the name on the Value automatically updates the
module's symbol table.
To test if a Value is a pointer or not, there is a function a->getType()->isPointerTy(). LLVM also provides a LLVM PointerType class, however there are not direct apis to compare the values of pointers.
So I wonder how to compare these pointer values, to test if they are equal or not. I know there is AliasAnalysis, but I have doubt with the AliasAnalysis results, so I want to validate it myself.
The quick solution is to use IRBuilder::CreatePtrDiff. This will compute the difference between the two pointers, and return an i64 result. If the pointers are equal, this will be zero, and otherwise, it will be nonzero.
It might seem excessive, seeing as CreatePtrDiff will make an extra effort to compute the result in terms of number of elements rather than number of bytes, but in all likelihood that extra division will get optimized out.
The other option is to use a ptrtoint instruction, with a reasonably large result type such as i64, and then do an integer comparison.
From the online reference:
Value * CreatePtrDiff (Value *LHS, Value *RHS, const Twine &Name="")
Return the i64 difference between two pointer values, dividing out the size of the pointed-to objects.
I'm currently learning Elm. relatively new to functional programming. i'm trying to understand this example from http://elm-lang.org/learn/Using-Signals.elm on counting mouse-clicks. they provide the following code:
clickCount =
foldp (\click count -> count + 1) 0 Mouse.clicks
They explain that foldp takes three arguments: a counter-incrementer, which we defined as an anonymous function with two inputs, a starting state 0, and the Mouse.clicks signal.
I do not understanding why we need the variable click in our anonymous function. Why can't we just have \count -> count + 1? Is the extra input getting bound to one of our inputs into foldp?
thanks!
You need it because foldp expects a function with two inputs. In this case, the first input is just ignored by your lambda, but the foldp implementation still puts something in there. Mouse.clicks always puts a sort of do-nothing value called Unit in there.
Some signals have a value associated with them, like Mouse.position, for example. If you wanted to do something like measure how far the mouse has moved, you would need to use that parameter.
In functional programming languages such as Scala and Haskell, there is an Either type that is often used to represent a successful result or a failure/error object. An either is said to be 'left' when it contains a failure and to be 'right' when it contains a successful result.
Is there a reason why "unsuccessful" is "left" and "successful" is "right"? Why are these directions used in the first place?
From Haskell's Data. Either documentation:
The Left constructor is used to hold an error value and the Right constructor is used to hold a correct value (mnemonic: "right" also means "correct").
This is just a guess, but in Haskell Either is monadic on its second type, which is the type associated with the Right constructor. Generic monadic code will therefore change only the right type, so the left type which remains constant is used to hold the error.
So the main reason would be that swapping the type arguments to Either so that Either a b is Left b or Right a is annoying to read for no real benefit.