I don't even know how to express this question.
A assume there's a pointer to a non evaluated expression. If it's requested (by some strict function that coerces it) then the pointer value is replaced by the value evaluated. Right? Am I wrong?
So I assume every pointer has a flag stating if it has been evaluated or not.
And what if the evaluation is undefined, like the head of an empty list? What is stored in the "pointer"?
I assume there's a pointer to a non evaluated expression. If it's requested (by some strict function that coerces it) then the pointer value is replaced by the value evaluated. Right? Am I wrong?
That's the gist of it.
So I assume every pointer has a flag stating if it has been evaluated or not.
Every pointer points to some structure where you can find that kind of information.
And what if the evaluation is undefined, like the head of an empty list? What is stored in the "pointer"?
The pointer points to an expression whose evaluation throws an exception.
The details are in the following page of the GHC wiki; see in particular "Types of objects": https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-objects
Data constructors, function closures, thunks ("unevaluated expressions") are the main ones.
Related
From the examples given for the THE function (http://clhs.lisp.se/Body/s_the.htm) when i change the following form
(the (values integer float) (truncate 3.2 2))
to
(the (values integer integer) (truncate 3.2 2))
I still don't get any compiler warnings, whereas (the integer 1.2) gives
;Compiler warnings :
; In an anonymous lambda form at position 0: Type declarations violated in (THE INTEGER 1.2)
Can some one explain why the above doesn't produce warnings? I test these on CCL.
You have misunderstood what the does. The specification tells you in so many words:
the specifies that the values returned by form are of the types specified by value-type. The consequences are undefined if any result is not of the declared type.
(My emphasis.)
In other words, what the does is to allow you to say to the compiler 'I undertake that these things have these types and you may compile appropriate code for that, with no checks needed; if that's not true then I fully accept that you may need to set my hair on fire and gouge out my one remaining eye'.
Now, famously, CMUCL and its derivatives such as SBCL take a rather different approach to type checking. From the SBCL manual:
The SBCL compiler treats type declarations differently from most other Lisp compilers. Under default compilation policy the compiler doesn’t blindly believe type declarations, but considers them assertions about the program that should be checked: all type declarations that have not been proven to always hold are asserted at runtime.
Thus the system treats the as an assertion about types which, if it is not already known to be true, must be checked. This is, I think, conformant, since 'unspecified consequences' can obviously include 'raising an exception in a nice way' (personally I prefer eye-gouging compilers but that's just me).
But if you want to write portable code, you should not assume that the does this. Rather you need either to accept the risks that it does not, or use some form like check-type or assert with a type check as the thing you are asserting.
I can use methods like Text() on a big.Int and it works fine, but if I return a big.Int then use "myfunc().Text()" throws an error, whereas if I return a *big.Int, I get no error. Why can I use Text() on a big.Int, *big.Int, and on a function that returns *big.Int but not on a function whose return value is big.Int?
https://play.golang.org/p/ovgeQDHFstP
Based on this and other behavior (such as how it prints), it seems like *big.Int is the type that is intended for use, is that correct?
Also, if I make and use a variable of type big.Int or *big.Int, it is passed by reference. That's fine. But if I wanted to pass one by value, how is that best done?
Should I make a new big.Int and set it to the original value using Set() and pass that? Or should I pass the original big.Int in, and copy its value to a new big.Int using Set() inside the function? Or is there some other, better way of doing it?
The Text() method is defined for receiver type *big.Int, so obviously you can call it on variables of that type and on return values of functions returning *big.Int. You can also call it on variables of type big.Int, because Go automatically takes the address of a variable when you're trying to call its pointer methods, just to save you the trouble of typing an extra ampersand.
However you can't call it on return value of a function returning big.Int, because that value is not addressable. Here's what the spec says about addressability:
For an operand x of type T, the address operation &x generates a
pointer of type *T to x. The operand must be addressable, that is,
either a variable, pointer indirection, or slice indexing operation;
or a field selector of an addressable struct operand; or an array
indexing operation of an addressable array. As an exception to the
addressability requirement, x may also be a (possibly parenthesized)
composite literal.
Your return value is none of those things, so you can't use the pointer method any more than you can write foo := &myFunc(). To work around this, you could save the return value on a variable to make it addressable. But most likely your function should return a pointer in the first place.
Also note that there are no references in Go. Everything is passed by value, and pointers are values just like any other.
https://golang.org/pkg/math/big/ the Text() method has a pointer receiver, which means that you can only call a.Text() if a is *big.Int.
*big.Int is a pointer to big.Int, see https://play.golang.org/p/dD70b0tPeGp for a fixed version of your code
Let's consider a complex structure in fortran
TYPE ComplexStrType
! Static as well as dynamic memory defined here.
END TYPE ComplexStrType
Defined a physical space (allocated on the stack memory I think) to use two variables of ComplexStrType:
TYPE(ComplexStrType) :: SomeComplexStr
TYPE(ComplexStrType) :: AnotherComplexStr
TYPE(ComplexStrType),POINTER :: PointerComplexStr
Then, I use SomeComplexStr to define a few stuff in the stack and to allocate a big space in the dynamic memory.
Now, suppose I want to point AnotherComplexStr to SomeComplexStr and forget space I have defined in the stack memory to AnotherComplexStr. To do that I use a simple but useful trick which converts some variable in a Target:
FUNCTION TargComplexStr(x)
IMPLICIT NONE
TYPE(ComplexStrType),INTENT(IN),TARGET :: x
TYPE(ComplexStrType),POINTER :: TargComplexStr
TargComplexStr => x
END FUNCTION TargComplexStr
And then I point PointerComplexStr to SomeComplexStr:
PointerComplexStr => TargComplexStr(SomeComplexStr)
Finally, I do AnotherComplexStr equal to PointerComplexStr:
AnotherComplexStr = PointerComplexStr
After that, it's supposed SomeComplexStr as well AnotherComplexStr are pointing to the same static and dynamic memory.
The thing is:
How can I free the space used by AnotherComplexStr used when I defined it at the beggining?
How do you recomend me nullify the pointers?
Is that practice safe, or do I have to expect some strange memory leaks on the execution?
If it's possible, how can I point the "pointed variable" to its original form? (Just in case I have to use it again as normal variable)
NOTE: It's useful because at the execution we can be decided if we want to use AnotherComplexStr as what it is, a complex and allocated structure, or we can switch it to be treated as a pointer and points it to another thing which already has the information we need. If there is another and easy way to do that, please tell me.
The "trick" that you are using in TargComplexStr does not work the way you think - that function offers nothing useful over simple pointer assignment.
You can associate a non-TARGET actual argument with a TARGET dummy argument, as you are doing, but when the procedure with the TARGET dummy argument completes, any pointers that were associated with the dummy argument become undefined (F2008 12.5.2.4 p11).
(Pointers can only be associated with targets, therefore something that isn't a target cannot have a pointer associated with it.)
This means that the result of the function is a pointer with undefined association status. It is not permitted to return a pointer with undefined association status from a function (F2008 12.6.2.2 p4).
The pointer assignment statement would then make PointerComplexStr become an undefined pointer. PointerComplexStr is then referenced in the assignment to AnotherComplexStr. It is not permitted to reference a pointer with undefined association status (F2008 16.5.2.8 p1).
Intrinsic assignment creates a copy of a value. This is the case even if the object on the right is a pointer - a copy of the value of the target of that pointer is created. Intrinsic assignment does not, at the level of the top data object being assigned[1], make one variable reference the storage of another. As far as I can tell, the intent of your entire example code could be replaced by:
AnotherComplexStr = ComplexStr
If you are trying to do something different to that, then you need to explain what it is that you are trying to do.
[1]: If the type of an object being assigned is a derived type that has a pointer components, then the definition of the value of the object includes the pointer association status of the pointer component, but not the value of the target of the component itself (F2008 4.5.8).
I am not able to distinguish between various precondition and post-condition in ACSL. As I know that requires, terminates and assume comes in precondition and ensures and assigns in post-condition. But in which set rest like decrease etc are??
Can any body is able to help me in figuring out??
thanks in advance
This is a trick question. Basically, decreases would serve as a pre-condition of a recursive call: if you have a function f with decreases x;, if it happens to make a call to itself, you have to prove that x<\at(x,Pre) at this call site. Additionally, you have a pre-condition that x>=0 when you call f (recursive call or not).
Regarding other clauses (based on their order of apperance in ACSL 1.7:
complete and disjoint clause are basically a logical property of the assumes clause of the contract, they do not imply anything for the implementation, but act as a sanity check of the specification itself.
allocates and frees are post-conditions (like for assigns but regarding dynamic allocation)
exits (and returns, breaks and continues) are post-conditions (they are evaluated when we exit the function -or the statement).
dependencies (\from) are post-conditions (like assigns).
decrease clause of ACSL is basically used for recursive function calls.
if you have specified decrease clause with a pointer variable x like: decrease *x;
then what it means is, every time when control enters the function related to this decrease clause, it checks whether the value pointed to by the pointer x is 1 less as compared to the value pointed to by x during the pre-state of the function. For the very first time when the function is called, pre-condition checked is: (*x) >= 0 as the function is in its pre-state so there is no pre-state value to compare to.
Is it safe calling QObject::deleteLater() when pointer equals 0? I googled it and searched in documentation, but I didn't find any helpful information.
You should not be able / should not do any call to a function of a 0 pointer.
It should be treated as a delete operation but it's a function of the object itself, so no object no function.