associated lists

[Davide Del Vento]

> Davide, does the description on gitHub of the problem with associated lists
> make sense?

Yes and no.

The no part:
First, The bug starts with "The wiki article on associated lists
explains how associations work." I couldn't find it. URL? (better in
github than here).

Second, I'm not completely fluent with the syntax just yet (for
example: now I understand the \ and the ^ but I'm still confused with
the single dot . and the | and the ellipsis ...)
Maybe the wiki article would make this crystal clear for me, so don't
spend your time explaining just yet.

The yes part:
I do see that the results from a single instance as opposed to the
same value passed to the same function differs (however it does not
differ as you mentioned in the bug, at least for me - see my comment
on github).

The maybe:
I haven't yet started the actual debugging to see what's happening.

Bye,
:Dav

[Bruce Long]

The wiki article is https://github.com/BruceDLong/ProteusCore/wiki/Associated-Lists-%28i.e.-Local-Variables%29

Here  is a quick explanation of some syntax:

Ellipsis mean "there may be more items in this list." Ellipsis have to be the last item in the list specification. That is, you can't say {1, 2, ..., 6, 7}.

If you have only ellipsis in a list specifier it basically means "unknown list" just as '_' means unknown integer and '$' means unknown string. (For completeness here '?' means unknown infon of any type.)

If we place a bar in front of a list specification (whether it has ellipse or something else) it means about the same thing it means in set theory: "All the items in this list do not contradict the given pattern". Thus, the bar and ellipse are often used together.  (BTW, the technical reason that I worded that in terms of non-contradiction has to do with not wanting to imply identity which would make all the items in the list identical to each other.)

--
Give me immortality or give me death!

[Davide Del Vento]

Bruce,

> The wiki article
> is https://github.com/BruceDLong/ProteusCore/wiki/Associated-Lists-%28i.e.-Local-Variables%29

Thanks, for completeness I included it in the bug on github. However,
I have a gut feeling that tells me that I am not grasping them fully,
although I think I've understood the syntax.

> Here  is a quick explanation of some syntax:
> Ellipsis mean "there may be more items in this list."

Ok, I knew this part. I was just confused by the bar |

> If we place a bar in front of a list specification (whether it has ellipse
> or something else) it means about the same thing it means in set theory:
> "All the items in this list do not contradict the given pattern". Thus, the
> bar and ellipse are often used together.

Here too I have the same gut feeling.

Anyway, back to the bug, have you seen my latest comment? I don't
think this bug is related to associated lists at all, I believe it's
just related to how unknown lists are normalized.

HTH,
;Dav

[Bruce Long]

Anyway, back to the bug, have you seen my latest comment? I don't
think this bug is related to associated lists at all, I believe it's
just related to how unknown lists are normalized.

That makes sense. And the discovery that it works correctly when the argument-item is '?' is good news because it means I can probably move on the demo again.

Do you want to keep looking at it?  I think I can begin to make progress on the demo again using '?' so we can put this off if you really want to begin writing a more comprehensive test suite. I don't have a preference; as long we have a work-around this bug would be a good test of your tests. :)

Alternatively, we could discuss the next step toward a demo/prototype and you/we could work on that.

Bruce

[Davide Del Vento]

Bruce,

> That makes sense. And the discovery that it works correctly when the
> argument-item is '?' is good news because it means I can probably move on
> the demo again.

This is very nice to hear.

> Do you want to keep looking at it?  I think I can begin to make progress on
> the demo again using '?' so we can put this off if you really want to begin
> writing a more comprehensive test suite. I don't have a preference; as long
> we have a work-around this bug would be a good test of your tests. :)

Yes, I prefer to have a larger test suite, especially including unit
tests. I believe that trying to debug this (or any) issue without a
robust unit test suite could make more harm than good: the risk of
fixing that and breaking something else is very high (unless you think
that your smaller end-to-end test suite already covers everything).

> Alternatively, we could discuss the next step toward a demo/prototype and
> you/we could work on that.

However, I'd rather start here, at least for a while. I strongly
prefer coding, but (as you have seen from my questions) I need to
better understand the language syntax and semantics before actually
doing anything useful.

Davide

[Bruce Long]

The tests that I have created are a fairly good regression suite. Whenever I verify some functionality that isn't tested already I add a new test. So "fairly good" here means that if the tests pass you probably have not broken anything.

What it isn't, however, is a black-box, requirements based test suite. It would be great to have a test suite that exercised all the major input 'partitions' of the language. It could be used to validate other implementations too. Is this what you are talking about creating?

However, I'd rather start here, at least for a while. I strongly
prefer coding, but (as you have seen from my questions) I need to
better understand the language syntax and semantics before actually
doing anything useful.

 

Awesome. What do you need to go forward? Perhaps you could start a new thread and tell me briefly where you are on that. I probably need to outline how I see the demo/prototype working?

Bruce

[Davide Del Vento]

Bruce,

sorry for being cryptic. I'll try to be clear here.

> The tests that I have created are a fairly good regression suite. Whenever I
> verify some functionality that isn't tested already I add a new test. So
> "fairly good" here means that if the tests pass you probably have not broken
> anything.
> What it isn't, however, is a black-box, requirements based test suite. It

I have some, but not a lot of experience on regression and
requirements based tests suites (I have experience of smoke testing
too, but those are of limited use here, at least for now). What I know
for sure is that there is a lot of confusion about the naming, so to
be sure that I understand you correctly, what is the difference
between your regression suite and the black-box, requirements based,
test suite? I assume that it is only in "size", i.e. knowing the
details of your implementation, your regression test is not testing
every requirement, because "you know" that if test for feature A
passes, than test for feature B would pass too, so you didn't write it
at all.

If that is the case, then yes, I want to write these black-box tests,
but only as part of the documentation of the language, to be included
in the examples and tutorials. They will be surely useful for
additional future implementations, but their coding usefulness would
just be limited to the understanding of the language (both of myself
writing them and of others reading them). So this will be strictly
part of the writing models for the demo/prototype, not of the
coding/debugging.

> would be great to have a test suite that exercised all the major input
> 'partitions' of the language. It could be used to validate other
> implementations too. Is this what you are talking about creating?

However, I am talking *also* about completely white-box, unit tests,
for some kind of TDD, which is the coding style I feel most
comfortable with:
- first I say: "next hour I'm going to write a piece of code that does X"
- then I wrote a trivial test (or a few trivial tests) that calls my
code and verify that "X is done" (it will of course fail), because I
haven't written that code yet. Since these are trivial tests, it
doesn't take more than 1-2 minutes to write them, but it often shows
that my definition of X was incomplete or contradictory or needed
something more: so I have to refine X to some Y.
- only as a last step, I actually write the code that "does Y",
usually saving lot of time *not* writing the code that "does X" which
would have been useless or bugous

>> However, I'd rather start here, at least for a while. I strongly
>> prefer coding, but (as you have seen from my questions) I need to
>> better understand the language syntax and semantics before actually
>> doing anything useful.
> Awesome. What do you need to go forward? Perhaps you could start a new
> thread and tell me briefly where you are on that. I probably need to outline
> how I see the demo/prototype working?

The answer is pretty simple, so I'm not starting a new thread on this:
I have no idea :-)
Why don't *you* start a new thread with your plans for this (or just
point at the wiki, if you have already written something).

Thanks,
Dav