How do we write if elseif elseif in pharo? - smalltalk

I have to check 3 conditons using the if elseif elseif. How can I do that in pharo. I did but am not sure since I did not find any such application in pharo.
x = 25
ifTrue:[DoSomething]
ifFalse:[DoSomething else].
x < 25
ifTrue: [DoSomething]
ifFalse:[Domething else].
x > 25
ifTrue: [DoSomething ]
ifFalse:[DoSomething else].

You can choose different design (using polymorphism, lookup, ...) but that is pretty much the same for any OO language (for Smalltalk in particular, refer to this Refactoring if-chains in Smalltalk without class explosion ).
In Smalltalk (and couple other languages such as Ruby) you have one extra option and that is class extension. You can design your own "if" statements that match well your particular domain and makes the code more obvious.
E.g. in your given example, I could add a new method to the Number class called compareTo:lesser:equal:greater:, and then your code changes to
x compareTo: 25
lesser: [ do something ]
equals: [ do something else ]
greater: [ do something entirely different ]
This naturally depends on your particular domain, maybe in different case the wording would be different. E.g. in case of collections, there's col ifEmpty: [ ] ifNotEmpty: [ ], for nil there's ifNil:ifNotNil:, for detection detect:ifFound:ifNone:, for dictionaries at:ifPresent:ifAbsent:, etc.

Related

Rebol: Dynamic binding of block words

In Rebol, there are words like foreach that allow "block parametrization" over a given word and a series, e.g., foreach w [1 2 3] [print w]. Since I find that syntax very convenient (as opposed to passing func blocks), I'd like to use it for my own words that operate on lazy lists, e.g map/stream x s [... x ... ].
How is that syntax idiom called? How is it properly implemented?
I was searching the docs, but I could not find a straight answer, so I tried to implement foreach on my own. Basically, my implementation comes in two parts. The first part is a function that binds a specific word in a block to a given value and yields a new block with the bound words.
bind-var: funct [block word value] [
qw: load rejoin ["'" word]
do compose [
set (:qw) value
bind [(block)] (:qw)
[(block)] ; This shouldn't work? see Question 2
]
]
Using that, I implemented foreach as follows:
my-foreach: func ['word s block] [
if empty? block [return none]
until [
do bind-var block word first s
s: next s
tail? s
]
]
I find that approach quite clumsy (and it probably is), so I was wondering how the problem can be solved more elegantly. Regardless, after coming up with my contraption, I am left with two questions:
In bind-var, I had to do some wrapping in bind [(block)] (:qw) because (block) would "dissolve". Why?
Because (?) of 2, the bind operation is performed on a new block (created by the [(block)] expression), not the original one passed to my-foreach, with seperate bindings, so I have to operate on that. By mistake, I added [(block)] and it still works. But why?
Great question. :-) Writing your own custom loop constructs in Rebol2 and R3-Alpha (and now, history repeating with Red) has many unanswered problems. These kinds of problems were known to the Rebol3 developers and considered blocking bugs.
(The reason that Ren-C was started was to address such concerns. Progress has been made in several areas, though at time of writing many outstanding design problems remain. I'll try to just answer your questions under the historical assumptions, however.)
In bind-var, I had to do some wrapping in bind [(block)] (:qw) because (block) would "dissolve". Why?
That's how COMPOSE works by default...and it's often the preferred behavior. If you don't want that, use COMPOSE/ONLY and blocks will not be spliced, but inserted as-is.
qw: load rejoin ["'" word]
You can convert WORD! to LIT-WORD! via to lit-word! word. You can also shift the quoting responsibility into your boilerplate, e.g. set quote (word) value, and avoid qw altogether.
Avoiding LOAD is also usually preferable, because it always brings things into the user context by default--so it loses the binding of the original word. Doing a TO conversion will preserve the binding of the original WORD! in the generated LIT-WORD!.
do compose [
set (:qw) value
bind [(block)] (:qw)
[(block)] ; This shouldn't work? see Question 2
]
Presumably you meant COMPOSE/DEEP here, otherwise this won't work at all... with regular COMPOSE the embedded PAREN!s cough, GROUP!s for [(block)] will not be substituted.
By mistake, I added [(block)] and it still works. But why?
If you do a test like my-foreach x [1] [print x probe bind? 'x] the output of the bind? will show you that it is bound into the "global" user context.
Fundamentally, you don't have any MAKE OBJECT! or USE to create a new context to bind the body into. Hence all you could potentially be doing here would be stripping off any existing bindings in the code for x and making sure they are into the user context.
But originally you did have a USE, that you edited to remove. That was more on the right track:
bind-var: func [block word value /local qw] [
qw: load rejoin ["'" word]
do compose/deep [
use [(qw)] [
set (:qw) value
bind [(block)] (:qw)
[(block)] ; This shouldn't work? see Question 2
]
]
]
You're right to suspect something is askew with how you're binding. But the reason this works is because your BIND is only redoing the work that USE itself does. USE already deep walks to make sure any of the word bindings are adjusted. So you could omit the bind entirely:
do compose/deep [
use [(qw)] [
set (:qw) value
[(block)]
]
]
the bind operation is performed on a new block (created by the [(block)] expression), not the original one passed to my-foreach, with separate bindings
Let's adjust your code by taking out the deep-walking USE to demonstrate the problem you thought you had. We'll use a simple MAKE OBJECT! instead:
bind-var: func [block word value /local obj qw] [
do compose/deep [
obj: make object! [(to-set-word word) none]
qw: bind (to-lit-word word) obj
set :qw value
bind [(block)] :qw
[(block)] ; This shouldn't work? see Question 2
]
]
Now if you try my-foreach x [1 2 3] [print x]you'll get what you suspected... "x has no value" (assuming you don't have some latent global definition of x it picks up, which would just print that same latent value 3 times).
But to make you sufficiently sorry you asked :-), I'll mention that my-foreach x [1 2 3] [loop 1 [print x]] actually works. That's because while you were right to say a bind in the past shouldn't affect a new block, this COMPOSE only creates one new BLOCK!. The topmost level is new, any "deeper" embedded blocks referenced in the source material will be aliases of the original material:
>> original: [outer [inner]]
== [outer [inner]]
>> composed: compose [<a> (original) <b>]
== [<a> outer [inner] <b>]
>> append original/2 "mutation"
== [inner "mutation"]
>> composed
== [<a> outer [inner "mutation"] <b>]
Hence if you do a mutating BIND on the composed result, it can deeply affect some of your source.
until [
do bind-var block word first s
s: next s
tail? s
]
On a general note of efficiency, you're running COMPOSE and BIND operations on each iteration of your loop. No matter how creative new solutions to these kinds of problems get (there's a LOT of new tech in Ren-C affecting your kind of problem), you're still probably going to want to do it only once and reuse it on the iterations.

Is it possible to create LOCAL variable dynamically in rebol / red?

It is easy to create GLOBAL variables dynamically in rebol / red with set like
i: 1
myvarname: rejoin ["var" i]
set to-word myvarname 10
var1
but then var1 is global. What if I want to create var1 dynamically inside a function and make it LOCAL so as to avoid collision with some global variables of same name ?
In javascript it is possible:
How to declare a dynamic local variable in Javascript
Not sure it is possible in rebol/red ?
In Red you have function, in Rebol2 you have funct. Both create local variable words automatically. Here an example for Rebol2
>> for num 1 100 1 [
[ set to-word rejoin ["f" num] funct [] compose/deep [
[ print [ "n =" n: (num) ]
[ ]
[ ]
>> f1
n = 1
>> f2
n = 2
>> n
** Script Error: n has no value
** Near: n
How it is done, you can see with source funct
In Rebol, there is USE:
x: 10
word: use [x] [
x: 20
print ["Inside the use, x is" x]
'x ;-- leak the word with binding to the USE as evaluative result
]
print ["Outside the use, plain x is" x]
print ["The leaked x from the use is" get word]
That will give you:
Inside the use, x is 20
Outside the use, x is 10
The leaked x from the use is 20
One should be forewarned that the way this works is it effectively does a creation like make object! [x: none]. Then it does a deep walk of the body of the USE, looking for ANY-WORD! that are named x (or X, case doesn't matter)...and binds them to that OBJECT!.
This has several annoying properties:
The enumeration and update of bindings takes time. If you're in a loop it will take this time each visit through the loop.
The creation of the OBJECT! makes two series nodes, one for tracking keys (x) and one for tracking vars (20). Again if you are in a loop, the two series nodes will be created each time through that loop. As the GET outside the loop shows, these nodes will linger until the garbage collector decides they're not needed anymore.
You might want to say use [x] code and not disrupt the bindings in code, hence the body would need to be deep copied before changing it.
The undesirable properties of deep binding led Red to change the language semantics of constructs like FOR-EACH. It currently has no USE construct either, perhaps considered best to avoid for some of the same reasoning.
(Note: New approaches are being investigated on the Rebol side for making the performance "acceptable cost", which might be good enough to use in the future. It would be an evolution of the technique used for specific binding).

Is it possible to implement DO + function in pure REBOL?

When DO is followed by a function, that function is executed and the remaining values are consumed as arguments according to the arity of the given function, e.g.,
do :multiply 3 4
multiply 3 4
These two statements are identical in their effects. But I think DO + function receives special treatment by the REBOL interpreter, because I don't believe it's possible to implement your own DO (with the exact same syntax) in pure REBOL, e.g.,
perform: func [f [any-function!]] [
; What goes here?
]
Is this correct?
Clarification
I am not asking about the DO dialect. This is not a "beginner" question. I understand REBOL's general syntax very, very well: Bindology (an old blog post I did on it), the implications of its homoiconicity, the various flavors of words, and all the rest. (For example, here is my implementation of Logo's cascade in REBOL. While I'm at it, why not plug my Vim syntax plug-in for REBOL.)
I'm asking something more subtle. I'm not sure how I can phrase it more clearly than I already have, so I'll ask you to read my original question more carefully. I want to achieve a function that, like DO, has the following capability:
do :multiply 3 4
double: func [n] [n * 2]
do :double 5
Notice how the syntax do :double or do :multiply consumes the appropriate number of REBOL values after it. This is the key to understanding what I'm asking. As far as I can tell, it is not possible to write your own REBOL function that can DO this.
You'll have answered this question when you can write your own function in pure REBOL that can be substituted for DO in the examples above—without dialects, blocks, or any other modifications—or explain why it can't be done.
The cause of the behavior you are seeing is specifically this line of code for the Rebol native DO.
/***********************************************************************
**
*/ REBNATIVE(do)
/*
***********************************************************************/
{
REBVAL *value = D_ARG(1);
switch (VAL_TYPE(value)) {
/* ... */
case REB_NATIVE:
case REB_ACTION:
case REB_COMMAND:
case REB_REBCODE:
case REB_OP:
case REB_CLOSURE:
case REB_FUNCTION:
VAL_SET_OPT(value, OPTS_REVAL); /* <-- that */
return R_ARG1;
This OPTS_REVAL can be found in sys-value.h, where you'll find some other special control bits...like the hidden "line break" flag:
// Value option flags:
enum {
OPTS_LINE = 0, // Line break occurs before this value
OPTS_LOCK, // Lock word from modification
OPTS_REVAL, // Reevaluate result value
OPTS_UNWORD, // Not a normal word
OPTS_TEMP, // Temporary flag - variety of uses
OPTS_HIDE, // Hide the word
};
So the way the DO native handles a function is to return a kind of "activated" function value. But you cannot make your own values with this flag set in user code. The only place in the entire codebase that sets the flag is this snippet in the DO native.
It looks like something that could be given the axe, as APPLY does this more cleanly and within the definitions of the system.
Yes, in Rebol 3:
>> perform: func [f [any-function!]] [return/redo :f]
>> perform :multiply 3 4
== 12
>> double: func [n] [n * 2]
>> perform :double 5
== 10
You might find it interesting to read: Why does return/redo evaluate result functions in the calling context, but block results are not evaluated?
This is a good question, and I will try to explain it to the best of my understanding.
The two statements above are identical in effect, but it is worth diving deeper into what is happening.
The :word syntax is known as a get-word! and is equivalent to writing get 'word. So another way of writing this would be
do get 'multiply 3 4
multiply is just another word! to Rebol.
The do dialect is the default dialect used by the Rebol interpreter.
If you want to implement your own version of do you need to be evaluating your code/data yourself, not using do. Here is a trivial example:
perform: func [ code [block!]] [ if equal? code [ 1 ] [ print "Hello" ] ]
This defines perform as a function which takes a block of code. The "language" or dialect it is expecting is trivial in that the syntax is just perform an action (print "hello") if the code passed is the integer 1.
If this was called as
perform [ multiply 3 4 ]
nothing would happen as code is not equal to 1.
The only way it would do something is if it was passed a block! containing 1.
>> perform [ 1 ]
Hello
Expanding on this slightly:
perform: func [ code [block!]] [ if equal? code [ multiply 3 4 ] [ 42 ] ]
would give us a perform which behaves very differently.
>> perform [ multiply 3 4 ]
== 42
You can easily write your own do to evaluate your dialect, but if you run it directly then you are already running within the do dialect so you need to call a function of some kind to bootstrap your own dialect.
This jumping between dialects is a normal way to write Rebol code, a good example of this being the parse dialect
parse [ 1 2.4 3 ] [ some number! ]
which has it's own syntax and even reuses existing do dialect words such as skip but with a different meaning.

How to create dynamic links in Netlogo? - Global variables change values for agents, agents interact and then change their type accordingly

I have a system where the two global/systemic variables economic-output-x and environmental-damage-y depend on the distribution of four types of worldviews (utility-assumptions) of the agents in the model. These two state variables get distributed as internal values among all agents as income and exposure. These two marginal or individual distributed valus determine power to persuade (P2P) and susceptibility for persuasion (S4P). Each agent therefore has P2P-x and P2P-y as well as S4P-x and S4P-y.
When two agents meet (Compare former related question) they exchange their internal values of P2P and S4P, which could be conceptualised as a debate, a discussion or a clash of opinions. If the substraction of these values results in a number above a particular threshold, i.e. the range between the two values is high, the 'losing' agent changes his worldview to the other one's worldview (transition), which in turn has an impact on the global variables.
Therefore we have quite a nested network of interrelationships and feedback loops. I am having problems putting this into practice. I have also looked at quite some opinion-influence-models but none quite grasps it the way I am approaching it.
My first attempt looked like this:
ask turtles [ ; Agents are doing their thing
[if occupied = "yes" [
ifelse count-down > 0
[set count-down (count-down - 1)]
[; get the hell out of here
rt 180
fd 2
set occupied "no"
set count-down 3]
]
if occupied = "no" [ ; Wandering around, ignoring occupied agents
set neighbourhood other turtles in-radius 2]
; If someone interesting and unoccupied is near, communicate!
set nearest-neighbour one-of neighbourhood with-min [distance myself]
ifelse nearest-neighbour != nobody [ ; In case someone has been set as nearest-neighbour, encounter is set in motion
if ([ occupied ] of nearest-neighbour = "no") [
face nearest-neighbour
set occupied "yes"
[if ([ S4P-x ] of self < [ P2P-x ] of nearest-neighbour) [
set worldview [ worldview ] of nearest-neighbour ]
ask nearest-neighbour [
face myself
set occupied "yes"
if ([ S4P-x ] of self < [ P2P-x ] of myself) [set worldview [
worldview ] of myself ]
]
But that did not really work out. Plus, I am not quite sure whether this is the most elegant way. I doubt it.
Is there maybe an entry on this topic on Stackoverflow which I overlooked, which is a little easier to grasp? Or another functionality in NETLOGO, which might fit my needs more appropriately?
Thanks in advance.
I think you probably mean just P2P-x instead of [P2P-x] of myself, and I think you mean set worldview [worldview] of myself instead of set worldview [worldview of myself]. Does that fix it?
You probably don't need to use links unless you want to represent a relationship between turtles that persists over time. If the encounters between turtles are fleeting, involving links doesn't buy you anything.
I'd suggest you look at Communication T-T Example in the Code Examples section of the Models Library, and at other models where pairs of turtles meet and interact, such as PD N-Person Iterated.

How to avoid if... else and switch cases

I have been programming for alot of time. Generally i program in some languages like PHP, ASP.net, Java, JavaScript and others. In all languages i have to use alot of if else statments . Like if value= 10 then ... if i review my code then i find alot of if conditions. So i would like to minimise them but how not sure.
one point was using classes somewhat minimised but still they are more...
like task, cat, sec and type:
if task = 'add' then
if cat = "animal" then
if sec = "man" then
if type = "male" then
'do the following stuffs
else
'do the following stuffs
end if
elseif sec = "horse" then
if type = "run"
'do the following stuffs
else
'do the following stuffs
end if
elseif....
end if
elseif cat = "plant" then
if sec = "land" then
if type="tree" then
'do the following stuffs
elseif type = "grass" then..
'do the following stuffs
elseif...
end if
elseif sec = "water" then
...
...
...
more n more continue n continue
so wonder how can i minimise them and write some efficient codes?
Sorry to inform lately that there may be alot of values for task, cat, sec, and type. My if statements are going nested n nested.
More explanatory my code also looks like same as :
http://thedailywtf.com/Articles/Coding-Like-the-Tour-de-France.aspx
Many if..else statements is often a symptom the Polymorphism is not being used.
It's called 'Arrow Antipattern'
Some of the methods of dealing with it are described here: http://c2.com/cgi/wiki?ArrowAntiPattern
One of the ways you migt consider, is to refactor code in nested levels to separate functions like
if cat = "animal" then
functionForAnimal();
elseif cat = "plant" then
functionForPlant();
elseif...
function functionForAnimal()
if sec = "man" then
functionForMan();
elseif sec = "horse" then
functionForHorse();
elseif...
etc...
This splits code into smaller fragments which are easier to maintain, and possibly reusable.
Assuming you're always doing equality comparisons, and comparing all four fields, a simple data-driven approach is quite practical. All you need to do is construct a map from (task, cat, sec, type) to a function to call:
handlers = {
('add', 'animal', 'man', 'male'): add_man_func,
('add', 'animal', 'horse', 'run'): run_horse_func,
# ...
}
handler = handlers[(task, cat, sec, type)]
handler(some_args)
Polymorphism might be useful when you have different implementations but the task is conceptually the same. Sometimes it's hard to find a natural class structure, and approaches like the state pattern or the strategy pattern might be more appropriate.
You described a matrix with 4 incoming parameters - task, cat, sec, type and one outgoing - stuff. So you have to code it someway.
For example, XML map and an XPath query, i.e. String.Format("task[#value={0}]/cat[#value={1}]/sec[#value={2}]/type[#value={3}]", "add", "animal", "man", "male") but this approach points to a data, not a method delegate.
Another way:
void DoStuffA() { }
void DoStuffB() { }
var arr = new[]
{
new { Task = "Add", Cat = "Animal", Sec = "Man", Type = "Male", Method = (Action)DoStuffA },
new { Task = "Add", Cat = "Plant", Sec = "Land", Type = "Tree", Method = (Action)DoStuffB },
// etc..
};
var action = arr.FirstOrDefault(i =>
i.Task == "Add" &&
i.Cat == "Animal" &&
i.Type == "Male").Method;
action();
Also you can use not anonymous members but declare a class, describe your variants in XML and deserialize them from XML to a number of your class instances.
I think there are some fundamental flaws in your design. I don't know what problem you are trying to solve with this code, but such code should be very rare in an object oriented language. Your code also seems a bit illogical to me, because, for example, the variable type means gender the first time it's used (male) and then it means an action (run). Have you noticed this?
Anyway, if you're indeed using Java (or anything with classes), what you need is abstraction. Next, move all logic you can to your objects -- don't handle it in one monstrous routine. Think this way: my objects know how to do their part.
Actually it's a bit difficult to give good advice in this situation, I suspect your problems have source on some high level in your application and this case code is only a symptom. Try to redesign your program to use object-oriented approach and perhaps a better solution will come to your mind as you go.
If you're not sure what polymorphism, abstraction and other OO terms mean, you will need to read up on this.
If choices for each of those variables are finite, then you can even use tricks like bit fields with OR operation.
Example:
// give each field a byte so that each can have 256 possible values
#define TASK_ADD 0x01
#define TASK_SUB 0x02
...
#define CAT_ANIMAL 0x01
...
#define SEC_BOY 0x03
#define SEC_MAN 0x04
...
#define TYPE_FEMALE 0x01
#define TYPE_MALE 0x02
...
if ((task << 24 | cat << 16 | sec << 8 | type) == 0x01010402) {
// do stuff
}
Somewhere you will need to check the conditions with if-elses, to make sure you do the right thing. You could create new subs if you don't want to cram one sub
Sub AddAnimalManMale()
If task = 'add' And cat = 'animal' And sec = 'man' And type = 'male' Then
'perform the add animal man male action'
End If
End Sub
Sub AddAnimalHorseRun()
If task = 'add' And cat = 'animal' And sec = 'horse' And type = 'run' Then
'perform the add animal horse run action'
End If
End Sub
then in your main sub
...
Call AddAnimalManMale()
Call AddAnimalHorseRun()
...
Breaking the code up is all what the game is about.
Historically you would do (and there had been good, or at least stable code, and still there is in all of these)
as you are doing it now, monolithic in huge functions, with lots of comments
split it into small well defined and well named functions
naming functions was tricky for complex stuff and also if you keep on passing references to big structures then objects were a natural thing to invent (however, once you go object way then it makes sense to do everything and through reusing the code object oriented patterns emerge... )
Recognizing the patterns is in a way similar to giving good names to functions (plus you get naturally useful methods thrown in, which can be huge win).