I encountered a confusion , when i pass a variable x to variable y by reference then both x and y should now point to same location, but the output that i am getting is not same.
Full detail discussion is here: http://gateoverflow.in/94182/programming-output
I have tried my best to explain the stuff to user but i am still unable to convience him fully, maybe i am lacking some concept.
rough code sample:
var b : int;
procedure M (var a, int)
begin
a= a*a;
print(a);
end;
procedure N
begin
b= b+1;
M(b);
end;
begin
b=12;
N;
print(b);
end;
I assume that as in question it is given that variables are static , so the value of a b should not change from 13 , but the value of a should be 13*13=169 , but my reasoning is counter to what call by reference is about.
pascal code from unauthorized book, please throw some insights.
I had to review scoping terminology. I had myself confused between static and dynamic scoping. Static scoping is used in all modern programming languages. I conclude that both a and b should have a value of 169 at the respective print statements.
Related
Why do I see
proc simple(a, b: int) : int =
result = a + b
so often in nim code when it seems as if
proc simple(a, b: int) : int =
a + b
would suffice? Is there any semantic difference between those two that I'm missing?
The only reference to implicitly returning the last statement I found on nim-lang wasn't in the manual but in the tut where it states that
[...] a proc's body can consist of a single expression whose value is
then returned implicitly.
Which seems misleading: it seems as it works for every 'last expression' (unless result was already set, then the result of the statement has to be discarded)
In the coding conventions (https://nim-lang.org/docs/nep1.html#introduction-coding-conventions) they recommend to use return only if it's needed in the flow.
The book Nim in Action says 'it's not idiomatic to use the return keyword as the last statement of the proc', but it's not explicit about result = a + b vs a + b. From the snippets around the book, the convention seems to be:
Prefer a + b.
Use result = a + b only if you are modifying result, as in result.add(b).
Use return a only to do an early exit from the proc.
The book also list this gotcha that won't compile:
proc resultVar: string =
result = "The result"
"This cause an error"
The reason behind code like result = a + b or return a is that people can't get all the idiomatics, specially when they are beginners like me. I still see for i in range(len(variable)) in Python code, which is not only non-pythonic but ugly and underperformant.
One of the more exotic features is the implicit result variable: every procedure in Nim with a non-void return type has an implicit result variable that represents the value that will be returned [Wikipedia].
just a short question regarding how to use TThreadList. Is it safe to use it with "with" statement as follows:
with FEngineList.DAQEngines.LockList do
begin
try
for Idx := 0 to Count - 1 do
Items[idx].Param1 := cos(2*pi*I/Count);
...
...
finally
FEngineList.DAQEngines.UnlockList;
end;
end;
or should I explicitly do it like here:
uEngines := FEngineList.DAQEngines.LockList;
try
with uEngines do
begin
for Idx := 0 to Count - 1 do
Items[idx].Param1 := cos(2*pi*I/Count);
...
...
end;
finally
FEngineList.DAQEngines.UnlockList;
end;
Thanks!
It's upon you which variant you choose. with only tells the compiler where to get members you write in your code. So yes, it is safe, as long as you're accessing members you wanted to. It doesn't affect the runtime.
I would prefer the first way, just without that begin..end block (if I'd be forced to use with), but it's just my personal preference and you are free to write it as you wish:
with FEngineList.DAQEngines.LockList do
try
...
finally
FEngineList.DAQEngines.UnlockList;
end;
Neither variant is to be recommended. If you had to choose between these two, the former is preferable since there is no real need for an extra local variable.
However, with is to be avoided. The problem is that is introduces potential for scope overlap. If the original scope and the object that is the subject of the with have members with the same name, then the with scope hides the outer scope. This catches you out when you add a new member to the subject of the with that happens to have the same name as a member of the outer scope. At best your program won't compile. At worst it compiles and you have a defect. Quite possibly a defect that you don't readily spot.
Code it like this:
uEngines := FEngineList.DAQEngines.LockList;
try
for Idx := 0 to uEngines.Count - 1 do
uEngines.[Idx].Param1 := Cos(2*pi*Idx/uEngines.Count);
....
end;
finally
FEngineList.DAQEngines.UnlockList;
end;
Related: Is Delphi "with" keyword a bad practice?
Suppose i want to know what unions(referencing environment) are active in the point marked with (*), how do i acknowledge that ? Which unions are in fact active ?
procedure P(A,B ; real)
X: real
procedure Q(B,C : real)
y : real
...
procedure R(A,C : real)
Z:real
........ --(*)
It's basic nesting basically. But you don't specify the full blockstructure (with begin..end pairs) to fully fixate the structure.
Assuming from indentation that the begin end; block of P is at the end, and of Q and R is directly after resp. the y and z declarations, then in Q: Q is searched first, then P, then the scope above P (mainprogram/unit or another procedure), in R R, P,unit etc.
I'm currently writing an interpreter for a simple programming language and just wanted to ask on the best approach would be to tackle it.
The environment for a program is as follows:
type Env = [[(Var, Int)]]
So I've coded the lookup and update but I'm a bit stuck on how to deal with the the scope for each begin block. An example is shown below:
begin [a,b,c]
read i
n = 1
while i < 0 do
begin
n = 2 * n
i = i - 1
end;
write n
end
From my understanding the scope of the first begin would be [a,b,c,i,n]
and then the second begin would contain [i, n]
therefore the env would be
[ [ ("a",0), (b",0), ("c",0), ("i",3), ("n",2) ], [("n",8), ("i",0) ] ]`
Currently my lookup function returns the first occurrence of a variable, so I'm having problems with the 2nd scope (2nd begin).
I'm not quite sure how I can make the update and lookup function return the value associated with that particular scope.
Basically I have the code working for one begin statement, but I am having issues with 2 or more statements in the sample program.
I am trying to compare two strings in Smalltalk, but I seem to be doing something wrong.
I keep getting this error:
Unhandled Exception: Non-boolean receiver. Proceed for truth.
stringOne := 'hello'.
stringTwo := 'hello'.
myNumber := 10.
[stringOne = stringTwo ] ifTrue:[
myNumber := 20].
Any idea what I'm doing wrong?
Try
stringOne = stringTwo
ifTrue: [myNumber := 20]`
I don't think you need square brackets in the first line
Found great explanation. Whole thing is here
In Smalltalk, booleans (ie, True or False) are objects: specifically, they're instantiations of the abstract base class Boolean, or rather of its two subclasses True and False. So every boolean has type True or False, and no actual member data. Bool has two virtual functions, ifTrue: and ifFalse:, which take as their argument a block of code. Both True and False override these functions; True's version of ifTrue: calls the code it's passed, and False's version does nothing (and vice-versa for ifFalse:). Here's an example:
a < b
ifTrue: [^'a is less than b']
ifFalse: [^'a is greater than or equal to b']
Those things in square brackets are essentially anonymous functions, by the way. Except they're objects, because everything is an object in Smalltalk. Now, what's happening there is that we call a's "<" method, with argument b; this returns a boolean. We call its ifTrue: and ifFalse: methods, passing as arguments the code we want executed in either case. The effect is the same as that of the Ruby code
if a < b then
puts "a is less than b"
else
puts "a is greater than or equal to b"
end
As others have said, it will work the way you want if you get rid of the first set of square brackets.
But to explain the problem you were running into better:
[stringOne = stringTwo ] ifTrue:[myNumber := 20]
is passing the message ifTrue: to a block, and blocks do not understand that method, only boolean objects do.
If you first evaluate the block, it will evaluate to a true object, which will then know how to respond:
[stringOne = stringTwo] value ifTrue:[myNumber := 20]
Or what you should really do, as others have pointed out:
stringOne = stringTwo ifTrue:[myNumber := 20]
both of which evaluates stringOne = stringTwo to true before sending ifTrue:[...] to it.
[stringOne = stringTwo] is a block, not a boolean. When the block is invoked, perhaps it will result in a boolean. But you are not invoking the block here. Instead, you are merely causing the block to be the receiver of ifTrue.
Instead, try:
(stringOne = stringTwo) ifTrue: [
myNumber := 20 ].
Should you be blocking the comparison? I would have thought that:
( stringOne = stringTwo ) ifTrue: [ myNumber := 20 ]
would be enough.
but I seem to be doing something wrong
Given that you are using VisualWorks your install should include a doc folder.
Look at the AppDevGuide.pdf - it has a lot of information about programming with VisualWorks and more to the point it has a lot of introductory information about Smalltalk programming.
Look through the Contents table at the beginning, until Chapter 7 "Control Structures", click "Branching" or "Conditional Tests" and you'll be taken to the appropriate section in the pdf that tells you all about Smalltalk if-then-else and gives examples that would have helped you see what you were doing wrong.
I would like to add the following 50Cent:
as blocks are actually lambdas which can be passed around, another good example would be the following method:
do:aBlock ifCondition:aCondition
... some more code ...
aCondition value ifTrue: aBlock.
... some more code ...
aBlock value
...
so the argument to ifTrue:/ifFalse: can actually come from someone else. This kind of passed-in conditions is often useful in "..ifAbsent:" or "..onError:" kind of methods.
(originally meant as a comment, but I could not get the code example to be unformatted)