built in procs [*resolved*]

Page: 1 2
Dec 10 2006, 2:59 am
In response to Kaioken
Oh yeah! that atom/movable/Move() was part of an earlier suggestion i completely forgot about.
Well, i'm not sure where this argument is going, but... thanks, this works great now.
Dec 10 2006, 4:12 am (Edited on Dec 10 2006, 12:12 pm)
In response to Jp
Adam357 wrote:
Oh yeah! that atom/movable/Move() was part of an earlier suggestion i completely forgot about.

Yeah, my suggestion. :P But that isn't how it's supposed to be used. If you look at my originally posted sample code with the for() loop, the comments and all, you will see I commented that the 'step()' proc is a kind of shortcut for the Move(). So that's how you should of used it, not just sticking the proc path in the object definition.


Jp wrote:
Kaioken has some idea of what he's doing, but that code won't work. I'm surprised it compiles.

Eh? It does work perfectly well, and obviously, of course, compiles, there's nothing wrong with it - I even tested it, after he said he had problems with it, and it did work (as you can see above, he made 2 mistakes when adding it). Your code isn't that much of an improvement. Please don't accuse code to not work or be bad when YOU have no idea about it...
Added comments to your original code (directly after your comments, separated by another //).
> mob/npc //This type path can be the ancestor of all NPCs in the game. //Yes, ideally. I already offered him to make it like this; point remains he doesn't have his game structured like that.
>     var/delay=10 //By default, NPCs will wait 10 ticks (approx 1 second) between each step. Change delay for individual NPCs to change that //Yes, but he didn't hint he wanted variable delays at all, and if he doesn'T, this is a waste of memory
>     proc
>         Wander() //All NPCs should have the Wander() proc
>             while(src) // The line for() shouldn't do anything, as far as I'm aware. while(src) will keep looping while the mob exists.
/*'for()' creates an infinite loop, and is equivalent for 'while(1)'. from the DM reference entry for 'for()':
Init and Inc may be omitted. If Test is omitted, the loop will continue forever (unless a break, goto, or return instruction is used to get out of the loop).
Note that using 'while(src)' or 'if(!src) break' is pointless; when an object is deleted, all running procs that have it set as src are automatically stopped*/
>                 step(src,pick(NORTH,SOUTH,EAST,WEST)) //This line is fine
>                 sleep(delay) //This way, we can have a variable delay with different NPCs //see definition for delay var
>     New()
>         ..() //Always a good idea to call the parent proc //yep, it usually is. Not ALWAYS good and not always essential, though.
>         spawn() Wander() //Call Wander(), make sure it's in a different call stack. Always good to make sure New() returns //Yeah, you should do this,though for now I omitted it to keep things simpler for the guy, he probably doesn't know about stuff this "deep" and may confuse him now.
>     Old_Man //Defines an Old Man NPC
>         icon = 'old_man.dmi'
>         icon_state = "normal"
>
Dec 10 2006, 9:08 am
In response to Animay3
Rather than just North()


You could try step()
Dec 10 2006, 11:36 pm
In response to Kaioken
Why use for() if while() makes more sense? You can emulate a for loop using a while loop, too, but you don't do it - because it doesn't make any sense. They're two different looping constructs used for two different things. In this case, while() makes sense, for() does not. while() should be used.

Variable delays for NPCs is always a good idea, and if you're handing out code on the forums, it should be extensible code. It's not much of a change. As for waste of memory, are you kidding me? Let's assume all BYOND numbers are 8 bytes in length, that it keeps a different copy of each variable for each mob, and he has a thousand NPCs. That's a massive overestimate, and it gives us a total memory usage from that one variable of 8*1000 = 8000 bytes = 7.81 kB.

That's nothing. And that's for a thousand NPC mobs. Yeah, that argument holds no water.

It is very much a good idea to call ..() in New(), and not telling him about it because "it's too complicated" is only going to lead to misunderstandings and confusion later. There is no reason why he would not want NPCs to call the New() that has been defined for mobs, if such a thing exists. Not putting that there is dangerous and silly. If you're going to give somebody code, make sure it's robust code, and won't break something if, for example, he has a custom New().

The 'making New() return by putting the Wander() proc in a new call stack' thing is in the same basket - you DON'T know how the rest of his code is set up, so make sure your code can't break it. For all you know, he has some sort of return code coming out of New(). For that matter, it should be .=..(), rather then ..().

Basically, make sure you give people code that will work under the vast majority of situations. There are some you can't help - for example, if he's buggerised with Move() in some way, the Wander() proc may not work. But there's really nothing you can do short of duplicating the entire Move() proc to fix that. For simple stuff like this, screw 'confusing the newbie', because it's going to be a damn sight more confusing when his program falls down because the code a helpful person on the forums gave him was brittle.
Dec 11 2006, 2:25 am
In response to Jp
Sigh.

Jp wrote:
Why use for() if while() makes more sense? You can emulate a for loop using a while loop, too, but you don't do it - because it doesn't make any sense.

What a load of crap. "makes more sense". You do it that way because it's more convenient. The reason both for() and while() were included is for just that, convenience. Like you have the 'in' operator despite list.Find(), for example.

They're two different looping constructs used for two different things. In this case, while() makes sense, for() does not. while() should be used.

Crap as well. They're similar looping constructs and both can be used for both "types" of looping. The reason you have both, is again, convenience. Using a 'for(Init,Test,Inc) Statement' loop is equivalent of: 
Init
while(Test)
    Statement
    Inc

The only [small] difference is that you can't (AFAIK) initialize a new var once to be used only in the while() itself, as you can do in the Init of for().

Using a 'while(Test) Statement' equals: 
for(,Test)
    Statement

---
Lol, "you don't do it because it doesn't make any sense", try making sense yourself.
Anyway, 'for()' is more convienent than 'while(1)', as it is shorter to type. Also, it's not like 'while(1)' makes a whole lot more sense, as you're using a static value as a condition for a looping construct, to create an infinite loop, rather than just using no condition at all. ;) You could also, of course, do for(,1).

Variable delays for NPCs is always a good idea,

Err, not really, no. It depends on the person and his own wishes and concerns.

...and if you're handing out code on the forums, it should be extensible code. It's not much of a change.

Code handed out on the forums usually really shouldn't even be copied and directly used, but just learned from.
Also, I gave the guy what he asked for - no more, no less. When/if he asked how to be able to make each mob have a different delay, I would of answered that.

As for waste of memory, are you kidding me? blah bla bla blah blah blah blah 7.81 kB.

So I suppose you're saying that if something, anything - has a relatively small negative effect, you shouldn't have any worries about doing it? Things accumulate.
Anyhow, that's not the point. It's a waste of a variable; all those mobs will "carry" it for no reason, it lengthens the code more for no reason, and it makes it more complicated for no reason. It also makes the 'vars' list variable longer.
Also, really, something such as 'if it's not broken (- aka, it does what you want it to do), don't fix it' comes in mind.

It is very much a good idea to call ..() in New(), and not telling him about it because "it's too complicated" is only going to lead to misunderstandings and confusion later.

Again, code shouldn't be directly copied from the forums. The point is, I don't know his game, and I don't know what he overrides, and how. If he overrides procs, he should know about calling parent/default procs. When he sees in my code sample that New() is overriden, he should know if he overrided it himself, and adjust it accordingly.

There is no reason why he would not want NPCs to call the New() that has been defined for mobs, if such a thing exists.

Eh? Ever heard of creativity? Anyway, of course there is. He could want some special code to run when that specific subtype is created, and not want the general type code to run as well - he wants to do something different with this subtype; make it an exception.

If you're going to give somebody code, make sure it's robust code, and won't break something if, for example, he has a custom New().

As you said yourself, you can make sure your posted code works, but you can't always know his existing code will still function as wanted. Also again, as said, posted code mostly isn't for direct copying and he should of altered it to fit in his game.

blah blah spawn() bla call stack bla For all you know, he has some sort of return code coming out of New().

Yeah, alright, that one was pretty much essential. I did think about it, though confused from other languages where sleeping passed thread focus including to the caller. It's also that way in some of the built-in DM procs.

For that matter, it should be .=..(), rather then ..().

!!!
OMG!!!1oneone1111, YOU POSTED BROKEN CODE! You don't really have an idea what you're doing. I'm surprised it even compiles!111oneone11shift!11!
;)

Don't keep this going for too long, m'kay? I'm gonna become tired of replying to this.
Dec 11 2006, 2:42 am
In response to Kaioken
Kaioken wrote:
What a load of crap. "makes more sense". You do it that way because it's more convenient. The reason both for() and while() were included is for just that, convenience.

Precisely, and I have to agree with Jp on this one. Using for() may confuse people. Try to follow a bit of "the global rulesets for BYOND Developers" aka "what the majority wants you to use". =P

Like you have the 'in' operator despite list.Find(), for example.

Except that's a bad example. There is a distinct difference between key in list and list.Find(key): key in list only returns true or false whereas list.Find(key) also tracks down the index number so you can reference to it. The latter should only be used when you need the index number. If you don't need it, you're wasting CPU cycles on finding an index number which will never be used.

Crap as well. They're similar looping constructs and both can be used for both "types" of looping.

True, except for() is "the loop for newbies": you could just use while() for everything. for() can't inherently do this: you'd have to use the break statement a lot.

Lol, "you don't do it because it doesn't make any sense", try making sense yourself.

Please don't go insulting eachother because you think your ego might be hurt.

Anyway, 'for()' is more convienent than 'while(1)', as it is shorter to type.

Except while() is what the majority wants, so just use it or get shunned by everyone else. =O

Err, not really, no. It depends on the person and his own wishes and concerns.

This is where I have to agree with you: it does depend on what the developer needs. If the developer needs to change speed a lot, it would be better to put it in a variable. On the other hand, if the developer doesn't change the delay at all, it would be better not to make a variable so the RAM is conserved, however tiny this may be.

Code handed out on the forums usually really shouldn't even be copied and directly used, but just learned from.

But it's not, and you just have to deal with that by posting 'better code'.

As for waste of memory, are you kidding me? blah bla bla blah blah blah blah 7.81 kB.

It's still 7.81 kB. It may not seem much, but that might just be that one byte that causes the PC to crash!

It is very much a good idea to call ..() in New(), and not telling him about it because "it's too complicated" is only going to lead to misunderstandings and confusion later.

No, it's not. If the newbie doesn't know what the ..() "proc" does, it should be explained before said newbie will make a mistake and post with yet another problem. I also agree that .=..() should be used. In fact, I think it should ALWAYS be used, unless you already set . to something else. It provides you with robust, efficent code which can later be adapted.

Again, code shouldn't be directly copied from the forums. The point is, I don't know his game, and I don't know what he overrides, and how. If he overrides procs, he should know about calling parent/default procs. When he sees in my code sample that New() is overriden, he should know if he overrided it himself, and adjust it accordingly.

But he might not, and your job would be to give him that information. It's what these forums are for.

!!!
OMG!!!1oneone1111, YOU POSTED BROKEN CODE! You don't really have an idea what you're doing. I'm surprised it even compiles!111oneone11shift!11!
;)

Don't overreact to such a statement. You made a mistake and were corrected. Just move along and learn from it. It's the part where you firmly stand by your decision that you look like an idiot.
Dec 11 2006, 3:30 am (Edited on Dec 11 2006, 3:47 am)
In response to Android Data
Android Data wrote:
Precisely, and I have to agree with Jp on this one. Using for() may confuse people. Try to follow a bit of "the global rulesets for BYOND Developers" aka "what the majority wants you to use". =P

Right, it doesn't matter what "the majority want me to use". :O One doesn't have to be like the majority. They teach kids this, if everybody went and jumped from the roof, would you to? Or more specifically, if the majority wanted you to smoke, would you?
And in this case, it REALLY doesn't matter, the difference is visual only. If it confuses people, then they SHOULD (ideally) just look for() up in the reference.
Except that's a bad example. There is a distinct difference between key in list and list.Find(key).

Yes there is, but it's not relevant, because the index number returned by Find() will be a TRUE value, so it can be used instead of the in operator. I doubt it takes more CPU to "determine" the index number, because either way, the CPU is looping threw list items. Look at these examples (they don't necessarily correspond though): 
proc
    InOperator(item,list/L)
        for(var/index=1,index < L.len,index++)
            if(L[index]==item) return 1
        return 0
list/proc/Find(item)
        var/list/L = src //just for easier readabillity, since list is 'src' in this case
        for(var/index=1,index < L.len,index++)
            if(L[index]==item) return index
        return 0

Crap as well. They're similar looping constructs and both can be used for both "types" of looping.

True, except for() is "the loop for newbies": you could just use while() for everything. for() can't inherently do this: you'd have to use the break statement a lot.

Lol, "you don't do it because it doesn't make any sense", try making sense yourself.

Please don't go insulting eachother because you think your ego might be hurt.
What does this have to do with ego? :O He was talking bull, and I corrected him. Also, saying someone didn't make sense isn't an insult - and, HE's the one who initially pretty much insulted me somewhat; look at his first post here's beginning. I couldn't care less about some simple words, especially in an internet forum, though,
Anyway, 'for()' is more convienent than 'while(1)', as it is shorter to type.

Except while() is what the majority wants, so just use it or get shunned by everyone else. =O

LMAO! So, BYOND is dictator-ruled? I must use coding ways that other people want? As I said above, the fact the majority wants it does NOT mean it's best OR that I have to do it as well.
And notice you're saying that about a code I voluntarily posted to help someone. -_-
Anyway, thanks for the good laughs.

Err, not really, no. It depends on the person and his own wishes and concerns.

This is where I have to agree with you: it does depend on what the developer needs. If the developer needs to change speed a lot, it would be better to put it in a variable...

Yep. Thanks for agreeing I suppose. :O

Code handed out on the forums usually really shouldn't even be copied and directly used, but just learned from.

But it's not, and you just have to deal with that by posting 'better code'.

Well, no, I don't "have to", it's not my problem ,really. >_> People should do what they're supposed to. Also, my code was alright, apart from the already discussed part where I missed a spawn() in the New(), but note that MY posted code didn't even override New(), it was Adam who added it to the code (though, granted, when skimming his re-posted-for-analysis code I didn't catch that). Using for() empty like that to create an infinite loop is perfectly fine, and it works just like while(1), no problem with it.

It is very much a good idea to call ..() in New(), and not telling him about it because "it's too complicated" is only going to lead to misunderstandings and confusion later.

No, it's not. If the newbie doesn't know what the ..() "proc" does, it should be explained before said newbie will make a mistake and post with yet another problem. I also agree that .=..() should be used. In fact, I think it should ALWAYS be used, unless you already set . to something else. It provides you with robust, efficent code which can later be adapted.

Yeah, I agree on both things. If the newbie knows about overriding more than just how to do it, he knows about ..() and can add it if needed - and if he DOESN'T know about it, then he should [--be informed about it].

Again, code shouldn't be directly copied from the forums. The point is, I don't know his game, and I don't know what he overrides, and how. If he overrides procs, he should know about calling parent/default procs. When he sees in my code sample that New() is overriden, he should know if he overrided it himself, and adjust it accordingly.

But he might not, and your job would be to give him that information. It's what these forums are for.

Yes, he might not, but he should. I can't really give him all that information he should do, if he doesn't know it, I might as well point him to read the DM Ref and DM Guide etc.
Also sometimes people really just ignore some things said to them - also not my problem, I AM already doing a volunteered "good deed of support" by initially helping them. >_>
Take for example an earlier problem in this topic; after I posted the sample code, highly commented, also mentioning I created a[n infinite] loop, he modified it by calling the posted sample proc in the loop...which of course didn't go very well at all, when actually if he just copy and pasted it without erroneously modifying it, it would of worked fine.

!!!
OMG!!!1oneone1111, YOU POSTED BROKEN CODE! You don't really have an idea what you're doing. I'm surprised it even compiles!111oneone11shift!11!
;)

Don't overreact to such a statement. You made a mistake and were corrected. Just move along and learn from it. It's the part where you firmly stand by your decision that you look like an idiot.

Well, express yourself better, as I'm not sure what you refer to in "such a statement" & "stand by your decision" and if you've read the whole topic entirely. Anyway, that quoted block I posted was sarcastic - I acted like he had in the beginning of his first post in this topic.
Dec 11 2006, 6:19 am
In response to Kaioken
Kaioken wrote:
Right, it doesn't matter what "the majority want me to use". :O One doesn't have to be like the majority. They teach kids this, if everybody went and jumped from the roof, would you to? Or more specifically, if the majority wanted you to smoke, would you?

If the majority of the BYOND Community would suddenly opt that I'd smoke or jump out of a window, I wouldn't follow it. Mind you there are people who do follow it (or we wouldn't have anymore new smokers!).
Fact is that while() is better than for() because while() is more widely available. It may teach you (and others you give it to) a bad habit if you use for() a lot: if you decide to further yourself and learn other languages, you may suddenly find that for() no longer exists and it gets a bit confusing.

Yes there is, but it's not relevant, because the index number returned by Find() will be a TRUE value, so it can be used instead of the in operator.

No. You don't know how BYOND handles this internally. From what I've heard, it takes more to see if the item actually exists and to get the index of said item. Your DM code is the thing that's irrelevant, since DM is nowhere near as confusing & sophisticated as C++ is.

What does this have to do with ego? :O He was talking bull, and I corrected him. Also, saying someone didn't make sense isn't an insult - and, HE's the one who initially pretty much insulted me somewhat; look at his first post here's beginning. I couldn't care less about some simple words, especially in an internet forum, though,

This is has to do with ego in the sense that you feel threatened and have to protect your precious reputation and respect. You also want more self-confidence. Therefor, you insult him back, which seems to be "the natural thing to do". Such an act will produce sparks which may eventually lead to a flame.
Wether or not he insulted you first isn't the issue here. If you choose to just take it like a man, chances are they'll stop. If they don't stop, they get warned/banned from these forums. It's how the system works.

LMAO! So, BYOND is dictator-ruled? I must use coding ways that other people want? As I said above, the fact the majority wants it does NOT mean it's best OR that I have to do it as well.

From your point of view, life would be ruled by dictators. Yes, BYOND is "ruled by dictators". If a majority doesn't like something, they will act upon it. And their acts will change your mind, believe me. If you stubbornly sit there and keep using for(), the community will keep pissing you off. EVENTUALLY it's going to break, and they'll have brainwashed you into using while(). It's how the system works. ;)

And notice you're saying that about a code I voluntarily posted to help someone. -_-

If you're not going to post valid code, don't bother to post at all.

Well, no, I don't "have to", it's not my problem ,really. >_> People should do what they're supposed to.

All new developers should read the DM Guide. Only few actually read it. The same applies to you: all developers should use while() in favor of for(). You keep using for().

Yeah, I agree on both things. If the newbie knows about overriding more than just how to do it, he knows about ..() and can add it if needed - and if he DOESN'T know about it, then he should [--be informed about it].

Again, the newbie should know it and should know that. Assume that the newbie doesn't know. Use .=..() and let the newbie remove it if the newbie is smart enough!

Yes, he might not, but he should.

Yes, he should. So what? We've already established people don't do what they should do, so the only thing left to do is to live with it.

I can't really give him all that information he should do, if he doesn't know it, I might as well point him to read the DM Ref and DM Guide etc.

Look at previous replies I made. Sometimes I just simply refer to the DM Guide, as people obviously didn't read it. Times like those when I just hope they'll crack and just read the bloody thing.

Also sometimes people really just ignore some things said to them - also not my problem, I AM already doing a volunteered "good deed of support" by initially helping them. >_>

True, you're already helping them and if they don't want to listen to you it's their own choice. But don't fret about it.

Take for example an earlier problem in this topic; after I posted the sample code, highly commented, also mentioning I created a[n infinite] loop, he modified it by calling the posted sample proc in the loop...which of course didn't go very well at all, when actually if he just copy and pasted it without erroneously modifying it, it would of worked fine.

Meanwhile developers also complain about the amount of copying/pasting and that you should learn from the code to then use it.

Well, express yourself better, as I'm not sure what you refer to in "such a statement" & "stand by your decision" and if you've read the whole topic entirely. Anyway, that quoted block I posted was sarcastic - I acted like he had in the beginning of his first post in this topic.

I know it was sarcastic, but you just shouldn't lower yourself to him.
Dec 11 2006, 7:18 am
In response to Kaioken
Kaioken wrote:
Yes there is, but it's not relevant, because the index number returned by Find() will be a TRUE value, so it can be used instead of the in operator. I doubt it takes more CPU to "determine" the index number, because either way, the CPU is looping threw list items.

if you run a program in debug mode and press ctrl+p you can see the execution time of procs. in this case the difference in time is small, but its such a common operation that it could be happening hundreds, even thousands, of times per tick.

Anyway, 'for()' is more convienent than 'while(1)', as it is shorter to type.

have you ever seen http://developer.byond.com/hub/LummoxJR/SticksterSource? it sure must be convenient to type code like that because its so short. and its really convenient to read it and understand it because its short.

people expect certain behavior from a for loop and certain behavior from a while loop. it doesn't really matter how convenient it is to type it, but how convenient it is to read it. that is especially the case when you're writing code to teach someone.
Dec 11 2006, 9:15 am
In response to OneFishDown
I wrote a reply to Android's post and posted it, though apparently it didn't go threw and was lost...well, heck, I'm not writing it again. In the end of that reply, I said I won't be replying to this "interesting" fruitful discussion in a while since I'm too lazy and tired of it.
This is one more reply for now, since I already read OFD's post and it's small.

OneFishDown wrote:
Kaioken wrote:

Anyway, 'for()' is more convienent than 'while(1)', as it is shorter to type.

have you ever seen http://developer.byond.com/hub/LummoxJR/SticksterSource? it sure must be convenient to type code like that because its so short. and its really convenient to read it and understand it because its short.

You people keep comparing different stuff together. 4K-Challenge-ish coding is NOTHING like just writing "for()" instead of "while(1)", give me a break.

people expect certain behavior from a for loop and certain behavior from a while loop.

Yes, they expect them to loop. It's been established that both can be used for either "types" of looping.
Also, people should expect other people to behave as THEY see fit, not as others do.

it doesn't really matter how convenient it is to type it,

Well then, I'm the one who typed it, and it matters to me, so there.

...but how convenient it is to read it. that is especially the case when you're writing code to teach someone.

Hmm, lets have a look. How to use both while() and for() is described in the DM Reference, and people should expect them to behave like described there. Well, this usage is described there, m'kay?
In addition, let's take ANOTHER glance. When I posted the code, I commented the line with "create an infinite loop". Readable enough for you?
Also, by the way, again, "for()" actually does make more sense than "while(1)" for reasons mentioned in a previous post by me, though that doesn't really matter.
Dec 11 2006, 9:45 am
In response to Kaioken
Kaioken wrote:
In the end of that reply, I said I won't be replying to this "interesting" fruitful discussion in a while since I'm too lazy and tired of it.

Translation: You win. I can't think of anything that would allow me to turn the tides in my favor.

Thanks.

You people keep comparing different stuff together. 4K-Challenge-ish coding is NOTHING like just writing "for()" instead of "while(1)", give me a break.

Bad example or not, the point still stands. It's about readability of the code, not how short it is.

Yes, they expect them to loop. It's been established that both can be used for either "types" of looping.

Yet, using the while statement is better since it's used by the majority as a sign of creating an infinite loop.

Also, people should expect other people to behave as THEY see fit, not as others do.

Again with the should. You SHOULD accept our critism and learn from it, but instead you make a big deal out of it.

Well then, I'm the one who typed it, and it matters to me, so there.

It doesn't matter how it's for you. It's supposed to matter what it is for the person you're helping. But that makes a "should", now doesn't it? ;)

Hmm, lets have a look. How to use both while() and for() is described in the DM Reference, and people should expect them to behave like described there. Well, this usage is described there, m'kay?

Should.

In addition, let's take ANOTHER glance. When I posted the code, I commented the line with "create an infinite loop". Readable enough for you?

Yes, but it isn't very clear on that. How is it an infinite loop? "I always thought while(1) or something like that made an infinite loop. How come it's been replaced with for()?"

Also, by the way, again, "for()" actually does make more sense than "while(1)" for reasons mentioned in a previous post by me, though that doesn't really matter.

while(1) makes more sense than for(). for() what? while(1=1)!
Dec 11 2006, 11:47 am
In response to Android Data
#define FOREVER while(1)


FOREVER
//...


do
//...
FOREVER



Everyone's happy! =)
Dec 11 2006, 2:14 pm
In response to Jtgibson
Please put your code in <DM> tags next time. I-- You're not a newbie. Wait a minute.
TRAITOR! GET HIM!

I already know your response:
#define NEVER while(!1)

NEVER
    ...

do
    ...
NEVER
Dec 11 2006, 5:17 pm
In response to Kaioken
 
proc/FillList(list/l) {for(l=list(), prob(90), l+=rand(1,10)) {;}}


That works. It fills a list up with a random amount of random numbers between one and ten, inclusive.

It's not a whole lot readable, is it? This is it with while():

proc/FillList(list/l) {l=list(); while(prob(90)) {l+=rand(1,10)}}


That makes much more sense.

Do you see what I'm getting at? Just because you CAN emulate a particular loop structure with another loop structure doesn't mean you should.

while() is designed for creating infinite loops or loops that should check a condition each iteration. for() is designed for running through some set of statements some number of times. You shouldn't use them for things they aren't designed for, because it results in ugly, unreadable code. Get it?
Page: 1 2