规范在这个问题上说了些什么:
迭代循环的形式如下:
IM IN YR <label> <operation> YR <variable> [TIL|WILE <expression>]
<code block>
IM OUTTA YR <label>其中可以是UPPIN (增量1)、NERFIN (递减1)或任何一元函数。该操作/函数应用于临时的,并应用于循环的本地操作。TIL将表达式计算为TROOF:如果它的计算结果为FAIL,则循环再次继续,如果没有,则循环执行停止,并在匹配的it之后继续执行。WILE是相反的:如果表达式是WIN,则执行继续,否则循环退出。
问题
我对规范的不满是:
据我所知,这意味着它必须从0开始。
虽然这对于大多数UPPIN的使用来说都是可以的,但对于大多数(我的)打算使用NERFIN的用户来说,这是完全没有意义的。在其他语言中,我最常用的递减循环变量是“重复n次(n次而不是重复使用)”成语和字符串操作,这在LOLCODE中都不是一个好主意。
是否可以使用NERFIN使循环从n减少到1或0,其方式比使用UPPIN或无操作的循环形式的等价物要少一些?
备选方案比较
使用UPPIN变体打印5 4 3 2 1:
IM IN YR LOOPZ UPPIN YR COWNTR TIL BOTH SAEM COWNTR AN 5
VISIBLE DIFF OF 5 AN COWNTR
IM OUTTA YR LOOPZPros:简明。
Cons:实际循环变量不能直接访问。
采用无操作的备选案文:
I HAS A COWNTR ITZ 5
IM IN YR LOOPZ
VISIBLE COWNTR
COWNTR R DIFF OF COWNTR AN 1
BOTH SAEM COWNTR AN 0, O RLY?
YA RLY, GTFO, OIC
IM OUTTA YR LOOPZPros:循环变量直接可用。
Cons:更长。
我只能和NERFIN在一起
IM IN YR LOOPZ NERFIN YR COWNTR TIL BOTH SAEM COWNTR AN -5
VISIBLE SUM OF 5 AN COWNTR
IM OUTTA YR LOOPZPros: err.使用NERFIN?
Cons:循环变量无法直接访问;可读性较低(哈哈!)比UPPIN变体更多;在细节上没有增加。
TLDR问题,重复
是否可以使用NERFIN使循环从n减少到1或0,其方式比使用UPPIN或无操作的循环形式的等价物要少一些?
我在语言规范级别1.2上使用lci口译员。
发布于 2011-08-24 05:47:32
从2007年起,就有关于这一确切主题的设计讨论。当时的共识似乎是建议添加一个FROM作为工作组希望快速进入1.2的解决方案:
http://forum.lolcode.com/viewtopic.php?pid=2484
这个问题是摆在桌面上的,并没有被纳入1.2规范。然而,它显然在1.3规范中:
http://lolcode.com/proposals/1.3/loop2
不过,仍在进行中。我检查过了,它还没有在存储库的“未来”分支中。通过查看循环解释器代码,我们可以看到这一点。截至2011年8月24日(在修订的72c983d0667d4d650657e1b7c5c5c7054096b0dd)中,它仍然总是最初为循环变量分配一个NUMBR为0:
https://github.com/justinmeza/lci/blob/72c983d0667d4d650657e1b7c5f4c7054096b0dd/interpreter.c#L3434
然而,即使使用旧的规范,理论上也应该可以使用TROOF与针对-1的测试相结合,从而使计数从5下降到0的形式相对清晰:
BTW countdown-test.lol
CAN HAS STDIO?
HAI 1.2
HOW DUZ I COUNTDOWN YR BOWNDZ
I HAS A FIRSTIES
FIRSTIES R WIN
IM IN YR LOOPZ NERFIN YR COWNTR TIL BOTH SAEM COWNTR AN -1
FIRSTIES
O RLY?
YA RLY
COWNTR R BOWNDZ
FIRSTIES R FAIL
OIC
VISIBLE COWNTR
IM OUTTA YR LOOPZ
IF U SAY SO
COUNTDOWN 5
KTHXBYE不幸的是,存在一个“效率黑客”,它阻止循环中的代码使用R修改循环变量。
https://github.com/justinmeza/lci/blob/a6ef5811e8eb98935a16600b799bccbe4adffdde/interpreter.c#L3408
然而,由于这似乎是代码中的一个bug,而不是规范中的遗漏,所以它更有可能在1.3发布之前得到修复。修补interpreter.c可以说,if (0 && stmt->update->type == ET_OP)使countdown-test.lol的代码按预期运行。如果您不需要与未修补的安装共享代码,那么对于现有的1.2 LOLCODE部署来说,它可能是一个合适的临时解决方案。
https://stackoverflow.com/questions/6124995
复制相似问题