Please FIX THAT!!!!!

Please fill out these questions for all feature requests and bug reports. If you're requesting a feature, please let us know why this feature is important or useful, not just what it should do.
Thanks!

  1. What browsers show this problem?
    any
  2. Please share an example project (if possible).
    Nope,Its the manual
  3. Describes the steps to reproduce this issue.
    Turn the manual to page 71
  4. What does Snap! currently do?
    show:
    if(<(parent) is a reporter>){
    return(call(parent)with inputs(message))
    }
  5. What should Snap! do instead?
    show:
    if(<(parent) is a command>){
    return(call(parent)with inputs(message))
    }
    Objects are functions with locals and can be callen at any time.They are commands , NOT reporters !

I think this is the third time you've posted this, and you're still not understanding what a command is and what a reporter is. Instead of just saying the same thing again, maybe ask a question?

open this test program and see inside eg

OH! Sorry, now I see what you're saying. But it's not the manual that's wrong; it's the IS_A_ block that gives the wrong answer for anonymous functions. That's a bug, but I'm not promising it'll be fixed soon, since it's a little difficult to know what type of procedure an anonymous one is. For named procedures, we can look at the declared type -- the shape of the block. But for anonymous ones there is no block and no declaration.

In principle we could look inside the body for REPORT blocks, and maybe we should do that. Or maybe we should just collapse Command, Reporter, and Predicate into one Procedure type in the IS_A_ block.

But, again, the manual is right: the object reports a method when called, so it's a Reporter.

Yes,it IS a Reporter block,but its type is'command(unevaluated)'

Hi!
Maybe I'm missing something... and maybe we can check some definitions, but I don't see a bug here.
My ideas (maybe wrong): a reporter block is a reporter, a command block is a command, and a stack of blocks (a script) is also a command (that script can report or not).

Then, this is running fine. In your project:

  • "new block" is a reporter and it reports a script. You say an "unevaluated script", yes, becuase if it was evaluated it would not return that script, it would return the evalutation.

reporters0

  • Yes it's a reporter.

reporters1

  • But its report is a command (a stack of commands)

reporters3

reporters4

  • And doing this with variables, it's the same... but you have to take care if you are pointing to the reporter or to its evaluation.

reporters5

That's all,
Joan

I think you guys are missing the point. Is this:
apl script pic apl script pic (1)
a command or a reporter? Clearly a reporter, right? Even though its script has a command block in it. Well, then, what about this:
apl script pic (2)
Command or reporter? Well, let's see, can we CALL it?


Yes, we can! It's a reporter.

(We can also RUN it:
apl script pic (4)
but then the value it reports is lost.)

I see that the REPORT block is a command block, so I understand your point of view. But, when viewed as a script, it's a reporter script, i.e., the script of a reporter, not a command script. So I guess this terminology is ambiguous.

To make everyone happy, since this issue isn't the point of the OOP example, I propose to say
apl script pic (5)
in the manual.

Round reporters can be run (the value is lost).

that's because round reporters can report a script (so can booleans, but that's notwhat they're meant to report)

But what about this topic?

Hi Brian,
I think I understand your ideas, and yes I understand the meaning of "report". But I think we are talking about blocks, and about our Snap! metaphor. And I think it is consistent and great.

Talking about "scripts" we will find there are not reporters and commands, only functions or scripts. For example...
reportering

Is this script a reporter? I don't know. Depending of "bool" it reports or not. No!! Because maybe "some code" is reporting first!

You know more than me about programming and about Snap! The only I want to point is that we can take advantage of our metaphor and enjoy it. I understand the predicates "is reporter" or "is command" (or "is predicate") are asking for the type of Snap! element: is talking about blocks (not about their inner scripts)

Then I think my last post can help and answer the "error" of the first question. It explain the behavior of this predicates, and their logic is only "formal", reporting which Snap! elements are.

  • A reporter block is a reporter (even if it reports nothing, it will be a bad reporter (error) but it's a reporter block)
  • A command block is a command (even it can report something)
  • A stack of commands are a command.

Joan

OK,everyone,that block tells us the return value's type of the input.So its correctness depends on what value do you think its reporting...the block type or the return value's type!

I was thinking the same thing and I was about to post it, but the difference was I would use <(pick random (0)to(1)) = 1> instead of (bool).