[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Complete LRM posted
Matthew,
I agree completely that the semantics of "list in list" are suspect as
they behave more like "list in set", but my point is that this needs to
be resolved in the operator first. Constraints should not change the
semantics of the underlying boolean expression. For future development,
I would definitely support sets as a type; however, for backward
compatibility, a new operator would have to be chosen to replace "in"
for the desired "list in list" behavior.
Mark
-----Original Message-----
From: Matthew Morley [mailto:mjm@cadence.com]
Sent: Wednesday, August 03, 2005 9:17 AM
To: Mark Strickland (mastrick); Vitaly Lagoon; Yaron Kashai
Cc: 1647-l@ieee1647.org
Subject: RE: Complete LRM posted
Mark, you are making a real confusion between lists and sets; lists have
order semantics in most everyday usages and are roughly "ordered sets"
in mathematical terms. but regular sets, as you recall from elementary
school, have no order amongst the elements.
the semantics of keep list1 in list2 merely needs to determine whether
the containment means only a contiguous sublist, or whether the elements
of list1 can be ordered in list2 without being contiguous.
your preferred semantics makes sense for sets, not lists (and certainly
not ordered sets). unfortunately e does not provide a datatype for sets,
and modelling sets with lists is always an unhappy arrangement. why not
lobby for e support for sets as first class citizens of the language?
M
> -----Original Message-----
> From: owner-1647-l@verificationvault.com [mailto:owner-1647-
> l@verificationvault.com] On Behalf Of mastrick@cisco.com
> Sent: Wednesday, August 03, 2005 1:40 PM
> To: Vitaly Lagoon; Yaron Kashai
> Cc: 1647-l@ieee1647.org
> Subject: RE: Complete LRM posted
>
> Vit,
>
> For the record, I think the current semantics are the best because the
> generator should be able to create the entire set of values that make
a
> boolean expression true, not some subset. Because "{1;2} in {3;2;1}"
is
> TRUE, "keep x in {3;2;1}" must allow the generator to choose x =
{1;2}.
> If the language adopts a new operator such as "in_order" which is true
> only if the relative order is preserved, then the constraint semantics
> could match that.
>
> Mark
>
> -----Original Message-----
> From: Vitaly Lagoon [mailto:lagoon@cs.mu.OZ.AU]
> Sent: Wednesday, August 03, 2005 6:54 AM
> To: Yaron Kashai; Mark Strickland (mastrick)
> Cc: 1647-l@ieee1647.org
> Subject: RE: Complete LRM posted
>
>
> Hi Yaron, Mark,
>
> Sorry, it's my mistake, not Mark's. The (list in list) indeed returns
> permutations of what I called a "sublist". That's quite embarrassing
> because I was the one who implemented the functionality a few years
> back. :-( Anyway, sorry for the confusion.
>
> I suggest that we stick with the current semantics and correct the
draft
> accordingly.
>
> For the record, I don't think that the current semantics is the best
> one. If "list in list" returns an ordered sublist then getting a
> permutation is easy. In contrast, if "list in list" returns a
> permutation of a sublist, then it is useless if we want the
unscrambled
> sublist. We'll have to look for some other, less elegant ways. So, if
we
> were starting from the scratch, I'd vote for the "unscrambled sublist"
> semantics. However, given the backward compatibility burden, it looks
> like we don't have much choice.
>
> Vit
>
>
> Yaron Kashai writes:
> >
> > Mark,
> >
> > Your test case does demonstrate that the implementation >
disagrees
> with the proposed semantics.
> >
> > As Vit points out, this behavior combines the semantics > of the
> proposed "list in list" with "is_a_permutation".
> >
> > I see two options:
> >
> > 1. stick with the proposed semantics for the two operators, > at
the
> cost of breaking compatibility. The two operators > will have to be
> combined to deliver the behavior you use > today.
> >
> > 2. add a new operator, e.g. "list in_order list", with the >
> semantics proposed. Define "list in list" to have the > de-facto
> behavior you reported, semantically defined by > composing
> "is_a_permutation" with "list in_order list".
> > This is not as minimal and orthogonal as one would like.
> >
> > I'll log this as an issue (491) and wait for more inputs.
> >
> > Cheers,
> > -- yaron
> >
> >
> >
> > >-----Original Message-----
> > >From: mastrick@cisco.com
> > >Sent: Tuesday, August 02, 2005 11:29 AM > >To: Yaron Kashai;
> 1647-l@ieee1647.org > >Cc: Vitaly Lagoon > >Subject: RE: Complete
LRM
> posted > > > >Yaron, > > > >Maybe I am mistaken about semantics,
but
> I can see results from Specman > >that show the generated list having
> elements that are NOT in the same > >relative order. My testcase is
>
> ><'
> > > struct foo {
> > > x : list of byte ;
> > > keep x in {1;2;3;4;5};
> > > post_generate() is also {
> > > print x ;
> > > };
> > > };
> > > extend sys {
> > > flist [20]: list of foo ;
> > > };
> > >'>
> > >
> > >and my results include such values for x as
> > > 4 5 3 1 .0
> > >and
> > > 4 1 3 2 5 .0
> > >
> > >We rely on this behavior extensively at Cisco.
> > >
> > >Mark
> > >
> > >-----Original Message-----
> > >From: Yaron Kashai [mailto:yaron@cadence.com] > >Sent: Tuesday,
> August 02, 2005 12:20 PM > >To: Mark Strickland (mastrick);
> 1647-l@ieee1647.org > >Cc: Vitaly Lagoon > >Subject: RE: Complete
LRM
> posted > > > > > >Hi Mark, > > > >I see Vit send a reply, but
there
> seemed to be an issue with the e-mail > >addresses. I'm reposting his
> answer here:
> > >
> > >_____________________________________________________
> > >Hi Yaron, Mark,
> > >
> > >I'm afraid Mark is mistaken about the semantics of "list in list".
> The > >semantics implemented currently by Specman's generator is
> exactly the > >one I described in the IEEE draft. Namely, (list1 in
> list2) means that > >list1 consists of elements of list2 IN THE SAME
> RELATIVE ORDER.
> > >
> > >So, there's no change in the semantics.
> > >
> > > >
> > > > 1. should "list in list" allow permutations?
> > >
> > >I think it shouldn't for two reasons: #1 is backward compatibility
> and > >#2 permutations can be easily programmed by combining "list in
> > >list" and > >"is_a_permutation".
> > >
> > > > 2. did it allow that in the past?
> > >
> > >No, as I said above.
> > >
> > > > 3. should there be another construct that allows that?
> > >
> > >Here's the way.
> > >
> > >keep list1 in list2;
> > >keep list1_permutation.is_a_permutation(list1);
> > >
> > >I don't thing we need to coat that in any kind of new syntactic
> sugar > >(though, users can always define a macro for that).
> > >
> > >Vit
> > >_____________________________________________________
> > >
> > >>-----Original Message-----
> > >>From: mastrick@cisco.com
> > >>Sent: Monday, August 01, 2005 9:23 AM > >>To: Yaron Kashai;
> 1647-l@ieee1647.org > >>Cc: Vitaly Lagoon > >>Subject: RE: Complete
> LRM posted > >> > >>Yaron, > >> > >>I have not heard from Vit, but
> even if generators to come may handle > >>this differently, the LRM
> should also allow the current > >implementation; > > > >>otherwise
> new tools will not handle legacy code well.
> > >>
> > >>Mark
> > >>
> > >>-----Original Message-----
> > >>From: Yaron Kashai [mailto:yaron@cadence.com] > >>Sent: Tuesday,
> July 12, 2005 5:18 PM > >>To: Mark Strickland (mastrick);
> 1647-l@ieee1647.org > >>Cc: Vitaly Lagoon > >>Subject: RE: Complete
> LRM posted > >> > >> > >>Hi Mark, > >> > >>There is no such list,
> and in fact I hope there are no such > >>differences.
> > >>At best, the standard may remain silent about some aspects that
are
> > >>implemented currently, leaving the freedom for future >
> >implementation to > > > >>either follow or diverge from the current
> implementation. I would > >>prefer not to rule out behavior that's
> currently implemented.
> > >>
> > >>I propose that you pick up the specific issue with Vit Lagoon,
who
> is > >>the author of that particular part. I suspect Vit has good >
> >reasons for > >>casting that restriction - some prior knowledge of
the
> generators to > >>come...
> > >>
> > >>Vit is copied on this e-mail.
> > >>
> > >>Cheers,
> > >>-- yaron
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: mastrick@cisco.com
> > >>>Sent: Tuesday, July 12, 2005 1:13 PM > >>>To: Yaron Kashai;
> 1647-l@ieee1647.org > >>>Subject: RE: Complete LRM posted > >>> >
> >>>Yaron, > >>> > >>>Is there any list that highlights the elements
of
> this LRM > >that would > >>>"break" existing e code that is written
> for Specman? As an example, > >>>7.2.7.4.5 says that "keep list1 in
> list2" cannot put list2 > >>elements in > >>>a different order
within
> list1. While existing code would > >>still parse, > >> > >>>a
> generator that follows this LRM would not fill the coverage > >>space
> as > >>>thoroughly as the Specman generator currently does (which
does
> allow > >>>list element reordering).
> > >>>
> > >>>Mark
> > >>>
> > >>>-----Original Message-----
> > >>>From: owner-1647-l@verificationvault.com
> > >>>[mailto:owner-1647-l@verificationvault.com] On Behalf Of Yaron
> Kashai > >>>Sent: Monday, July 11, 2005 9:35 PM > >>>To:
> 1647-l@ieee1647.org > >>>Subject: Complete LRM posted > >>> > >>>
>
> >>>Dear all, > >>> > >>>As requested in today's meeting, the
complete
> LRM is now > >>posted as one > >>>PDF file, to ease the review of
the
> complete flow of the document.
> > >>>(This version still lacks the preliminary clauses, such as
> overview).
> > >>>
> > >>>A direct link to the file:
> >
>>>http://www.ieee1647.org/downloads/D0.3-PDF-files/ieee_P1647_d3.pdf
> > >>>
> > >>>The file is accessible from the Revision 0.3 download page at >
> >>>http://www.ieee1647.org/download_03.html along with the >
> >>per-clause PDF > >>>files.
> > >>>
> > >>>Please take the time to review the latest version, we only >
> >have a few > >>>weeks to complete the work.
> > >>>
> > >>>Cheers,
> > >>>-- yaron
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
>