05-28-2021, 01:24 PM
(05-17-2021, 06:27 AM)Eric Piette Wrote: Hi,
Sorry, it has taken me a long time to get round to looking at this.
(05-17-2021, 06:27 AM)Eric Piette Wrote: All the ludemes concerning Cards are in a preliminary version, so for the moment we advise to not use them (moreover they are not our priority, I hope to continue to work on them next year).This is not at all a problem for me.
(05-17-2021, 06:27 AM)Eric Piette Wrote: Concerning your example file, what you currently do in it is right, that should be a (then ...) (I just modified the "to:Mover" to "to:All").I don't see why you did this. I know it's only a silly example but I think I did mean to:Mover. In the silly example at least it makes a difference. I don't understand why you would do this.
(05-17-2021, 06:27 AM)Eric Piette Wrote: So I am not sure why you want to use a (do ....) here?No, in battleships the order really does matter. Do I need to go into more details? Post number 33 attached the battleships code, though it is the current "working" code, with the code I am trying to implement commented out. So I don't think it is that easy to follow in that state.
If that's because you already have a (then ...) in your battleship, you can just use a (and ....) to do both set of actions, no?
The Unhide code is much simpler. It does not have (do...) ludemes nested inside other (do ...) ludemes. It simply shows that a (set Hidden) statement breaks when inside a (do .. ludeme). Why is (do ..) so fragile? If we are only meant to use it in some circumstances it is not documented what those circumstances are, not are they trapped by the compiler. And I currently I don't have an alternative, though I could look into nested (then....) ludemes.