Re: It would be a lot cooler if:

That is *really* debatable.

So people have to learn a language that has no specification and that has
no working implementation (and which is typed inconsistently with respect
to indentation and punctuation) because you don't want to worry about
language-specific implementation details?

I bet I could write javascript that, ignoring supporting libraries, looked
at least as good as the pseudo code and hid any language-specific details.
The idea that inventing a new language helps people avoid worrying about
the language is kind of ridiculous.

The pseudo-code obviously hasn't ran and obviously will never run and no
one is assured that what they are reading actually works.  We just reason
through it and hope and then we spend months to years on the mailing list
finding problems and debugging issues that wouldn't have existed had the
'pseudo-code' been actual code (because it would have worked or not
instantly without some monkey brain trying to run it).  So I completely
disagree that the pseudo-code makes clarifying intended semantics easier
and furthermore it makes verifying that anything is actually correct near
impossible.

Right off the bat, we had a list of questions such as 'what the hell do
these types do for transitions'.  Because the code to type the transition
was 'helpfully' omitted, important semantics were lost.  And these
semantics would have been ironed out completely *if* the code has been
actually implemented.  I *just* implemented an SCXML engine and I would
have rather had a reference implementation than the pseudo-code.  I think
you are completely wrong with your first assertion (it made clarifying
semantics easier due to lack of implementation details).  It would seem
that based solely on that there should be at least a hint of doubt that the
pseudo-code is the right way to go.

Making the pseudo-code correct is at least as hard as getting any language
correct.  I think that the time will come to completely drop the
pseudo-code and just have a reference implementation.  Although, as you
note, having a thorough test suite with 'correct' answers is better than
having a reference implementation or anything else.

Chris



On Wed, Feb 13, 2013 at 1:13 PM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  Chris,****
>
> The point of the pseudo-code is to  clarify the intended semantics, which
> is easier if you don’t have to worry about language-specific implementation
> details.  There are open source implementations that people can examine,
> including one in Javascript.  I agree that we need to publish our set of
> tests, which we are working on.  Once we do, and the open source
> implementations run them, everyone will have access to: pseudo-code,
> running code, and tests.  ****
>
> ** **
>
> **-          **Jim****
>
> ** **
>
> *From:* chris nuernberger [mailto:cnuernber@gmail.com]
> *Sent:* Wednesday, February 13, 2013 1:06 PM
> *To:* VBWG Public (www-voice@w3.org)
> *Subject:* It would be a lot cooler if:****
>
> ** **
>
> 1.  The pseudocode was a reference implementation in javascript.****
>
> 2.  Hosted on github or gittorious.****
>
> 3.  Ran a set of accepted SCXML tests.****
>
> 4.  We could then all propose refactoring and such with pull requests and
> discuss them and we would know if things were working or not pretty quickly.
> ****
>
> ** **
>
> We can't be all that far from this.  I bet it would take all of like 3-4
> days of work and I thought someone already had a reference implementation
> somewhere.  I think a lot of problems with the pseudocode would be better
> discussed with a failing test than with theoretical observations.****
>
>
> ****
>
> ** **
>
> Chris****
>
> ** **
>
> --
> A foolish consistency is the hobgoblin of little minds - Emerson ****
>



-- 
A foolish consistency is the hobgoblin of little minds - Emerson