I write a strange Alloy demo about "assert" out of curiosity.
Assume there is a "Program", the "Program" has 2 "Varieties", and each "Variety" has a "Value" from "Data" set.
Then I also set a "fact" that all of the "Value" of the "Variety" are "data1".
Finally, I set an "assert" that for all "Program", all of "Value" of the "Variety" in the "Program" are "data1".
I think the "assert" satisfies the "fact", however when I check the "assert", it gives a counterexample, I cannot understand about this, why it has the counterexample?
The code appears as follows:
enum Data{data1,data2}
sig Program{
Var1:Variable,
Var2:Variable
}
sig Variable{
Value:Data
}
fact{
all v:Variable{
v.Value=data1
}
}
assert test{
all p:Program{
all v:(Program->Variable){
p.v.Value=data1
}
}
}
The counterexample is as follows:
I'm a bit confused about your example because the var1 and var2 fields don't seem to be used. But the reason you're getting a counterexample is probably because v can be empty, in which case p.v.Value evaluates to the empty relation, and data1 evaluates to a singleton, so they're not equal.
There are two mistakes in my question, I modify the code, and it is right now.
enum Data{data1,data2}
sig Program{
Var1:Variable,
Var2:Variable
}
sig Variable{
Value:Data
}
fact{
all p:Program{
//In theory, there should be "all v:(Program->Variable)", but Alloy does not support HOL.
//all v:(Program->Variable){
p.Var1.Value=data1
p.Var2.Value=data1
// }
}
}
assert test{
all p:Program{
p.Var1.Value=data1
p.Var2.Value=data2
// And here is another mistake, Var1 and Var2 is only the subset of "all v:(Program->Variable)"
// all v:(Program->Variable){
// p.v.Value=data1
// }
}
}
check test for 10 but 1 Program
Related
I'm working on a DSL using groovy, and as i'm new to this language, i'm struggling on something.
i have this code
def from(state1) {
def closure
closure = { sensor ->
[becomes: { signal ->
// someProcess;
[and: closure]
}]
}
[to: { state2 ->
// someProcess
[when: closure]
}]
};
what i do is to read this kind of sentances
from "on" to "off" when "button" becomes "high" and "button2" becomes "high"
the and "button2" becomes "high", is optional. So grammatically, everything works as i wanted to.
the problem is that i wanted to add the possibility to treat or also, like this:
from "on" to "off" when "button" becomes "high" or "button2" becomes "high"
but i don't know how to do that. How can i do to add that, and also the possibility to know if it's and or or to have a control statement and a different process for each
it have been two days that i'm on the problem..
Thanks :)
1st of all, I like your question!
Not knowing what your //someProcess is supposed to do and what the whole use-case is all about (IoT-ish?), you can implement the or operator like that:
...
[to: { state2 ->
[when: closure, whenEither:{ Map conds -> conds.any{ sensor, signal -> 'high' == signal } } ]
}]
then you can write:
from "on" to "off" whenEither button:"high", button2:"high"
I am developing a DSL with Groovy and I have run into the following problem. I have a method which performs some action on an object with the given parameters.
def run(x) {
[with:{ y -> foo(x,y) }]
}
run "thing" with "param" // evaluates to foo("thing","param")
Now, assume I want to add a default functionality to my DSL:
def runDefault(x) {
foo(x)
}
runDefault "thing" // evaluates to foo("thing")
Is there a way to combine the two into a single function, such that the with "param" part becomes an optional clause? I want to be able to use the DSL as shown below:
run "thing" with "param" // should do foo("thing","param")
run "thing" // should do foo("thing")
if you are able to distinguish both calls in the run-method, you could do something like this:
def run(x) {
switch (x) {
case 'foo':
println "foo($x)"; break;
case 'bar':
[with:{ y -> println "bar($x,$y)" }]; break;
}
}
run "bar" with "param"
run "foo"
Here's a part of (groovy) class that stores some data in Mongodb:
long save(Object data) {
def customerReference = getNextCustomerReference()
def map = ['customerReference': customerReference, 'data': data, 'created': new Date()]
BasicDBObject basicDBObject = new BasicDBObject(map)
collection.insert(basicDBObject)
customerReference
}
private long getNextCustomerReference() {
1234
}
even though I have explicitly said i want a primitive long, what ends up in the database is an object:
{ "_id" : ObjectId("52f3c0597d844b0fcee29013"), "customerReference" : NumberLong(1234), "data" : "original data", "created" : ISODate("2014-02-06T17:03:21.411Z") }
However, if I change the return type to def for the private method this happens:
{ "_id" : ObjectId("52f3c1477d84698725f50fe5"), "customerReference" : 1234, "data" : "data", "created" : ISODate("2014-02-06T17:07:19.055Z") }
which the behaviour I want (a primitive stored in the db).
Can someone explain this because its baffling. Surely if I go out of my way to define a type, Groovy should try and honour it?
Groovy almost always automatically autoboxes primitive types to their number reference type-equivalent:
long test_long() { 123l }
int test_int() { 123 }
def test_def() { 123 }
def test_def_long() { 123l }
long l = 42l
assert test_long().class == Long.class
assert test_int().class == Integer.class
assert test_def().class == Integer.class
assert test_def_long().class == Long.class
assert l.class === Long.class
If you remove the long return type, the object is autoboxed to java.lang.Integer. Seems your code handles the Integer like a "primitive".
Some time ago Groovy 1.8 introduced primitive type optimization, an internal fallback to use primitive types under the hood in certain situations. This can help in some situations but is an internal performance optimization you can't directly make use of (by using some syntax construct or something like that).
Sometimes you can force a primitive by an explicit cast, but chances are high it will be converted to a reference type along the way through methods calls and stuff.
In the following fragment, how can I distinguish the second invocation instance of my sub foo from the first?
while ($whatever) {
foo(); foo(); # foo() and foo() have the same caller package, file, and line
}
Something like a super-caller() that returned file, line and column would do the trick. I'd prefer not to use source filters.
Background, or, isn't this a bit of an XY Problem?
I have a convenience module, Local::Thread::Once, that exposes functionality like pthread_once/std::call_once in an OO-ish way and also as a subroutine attribute. These are easy enough, since there is a natural and unambiguous "once_control" or "once_flag" in either case.
However, there is additionally a procedural interface — once { ... } — that currently serializes based on the $filename and $line returned by caller. Something like this:
sub once(&) {
my $user_routine = shift;
my (undef, $file, $line) = caller;
my $once_control = get_a_shared_flag_just_for_this_invocation($file, $line);
lock($once_control);
if (! $once_control) { $once_control++; $user_routine->(); }
return;
}
That's not precisely how it works — the real one is more efficient — but the point, again, is that invocation is keyed off of the file and line of the caller. This works, except that it cannot distinguish two invocations on the same line.
while ($whatever) {
once { foo(); }
once { bar(); } # OK, foo() and bar() each called only once
once { baz(); }; once { buz(); }; # :( buz() not called, not even once
}
Note that the address of $user_routine cannot be used as an additional discriminant, since subs are copied from one ithread to another.
I can live with this problem as a documented limitation for a very contrived use case, but I'd prefer to fix it somehow.
Devel::Callsite was written precisely for this purpose.
I had to read this a couple of times before I understood what you are talking about. How about a "super caller" function like:
my #last_caller = ("","","",0);
sub super_caller {
my ($pkg,$file,$line) = caller(1 + shift);
if ($pkg eq $last_caller[0] &&
$file eq $last_caller[1] &&
$line eq $last_caller[2]) {
$last_caller[3]++;
} else {
#last_caller = ($pkg,$file,$line,1);
}
return #last_caller;
}
It's like caller but the 4th element is a count of how many times we've seen this exact package, file, and line in a row.
The optree is still so much black magic to me, but here are my observations:
in walking the optree of a code reference, you encounter one B::COP structure
The B::COP structure has file, line, and cop_seq properties (among others)
The cop_seq property is different for different subroutine definitions
Ass-u-me-ing these are true and not a horribly incomplete model of what is happening, you can use file, line, and cop_seq as a key, or maybe even just cop_seq. Here's a proof of concept:
use B;
sub once (&) {
my $code = shift;
my $key = get_cop_seq($code);
print "once called with code '$key'\n";
}
my $optreedata;
sub get_cop_seq {
my $code = shift;
$optreedata = "";
B::walkoptree( B::svref_2object($code)->ROOT, "find_cop_seq" );
return $optreedata;
}
sub B::OP::find_cop_seq {
my $op = shift;
if (ref $op eq 'B::COP') {
$optreedata .= sprintf "%s:%d:%d", $op->file, $op->line, $op->cop_seq;
}
}
sub foo { 42 }
sub bar { 19 };
once { foo }; # this is line 26
once { bar };
once { foo }; once { bar };
once { bar } for 1..5; # line 29
And here's the output (your results may vary):
once called with code 'super-caller2.pl:26:205'
once called with code 'super-caller2.pl:27:206'
once called with code 'super-caller2.pl:28:207' <--- two calls for line 28
once called with code 'super-caller2.pl:28:208' |- with different cop_seq
once called with code 'super-caller2.pl:29:209'
once called with code 'super-caller2.pl:29:209'
once called with code 'super-caller2.pl:29:209' <--- but 5 calls for line 29
once called with code 'super-caller2.pl:29:209' with the same cop_seq
once called with code 'super-caller2.pl:29:209'
I would like to return from a closure, like one would if using a break statement in a loop.
For example:
largeListOfElements.each{ element->
if(element == specificElement){
// do some work
return // but this will only leave this iteration and start the next
}
}
In the above if statement I would like to stop iterating through the list and leave the closure to avoid unnecessary iterations.
I've seen a solution where an exception is thrown within the closure and caught outside, but I'm not too fond of that solution.
Are there any solutions to this, other than changing the code to avoid this kind of algorithm?
I think you want to use find instead of each (at least for the specified example). Closures don't directly support break.
Under the covers, groovy doesn't actually use a closure either for find, it uses a for loop.
Alternatively, you could write your own enhanced version of find/each iterator that takes a conditional test closure, and another closure to call if a match is found, having it break if a match is met.
Here's an example:
Object.metaClass.eachBreak = { ifClosure, workClosure ->
for (Iterator iter = delegate.iterator(); iter.hasNext();) {
def value = iter.next()
if (ifClosure.call(value)) {
workClosure.call(value)
break
}
}
}
def a = ["foo", "bar", "baz", "qux"]
a.eachBreak( { it.startsWith("b") } ) {
println "working on $it"
}
// prints "working on bar"
I think you're working on the wrong level of abstraction. The .each block does exactly what it says: it executes the closure once for each element. What you probably want instead is to use List.indexOf to find the right specificElement, and then do the work you need to do on it.
If you want to process all elements until a specific one was found you could also do something like this:
largeListOfElements.find { element ->
// do some work
element == specificElement
}
Although you can use this with any kind of "break condition".
I just used this to process the first n elements of a collection by returning
counter++ >= n
at the end of the closure.
As I understand groovy, the way to shortcut these kinds of loops would be to throw a user-defined exception. I don't know what the syntax would be (not a grrovy programmer), but groovy runs on the JVM so it would be something something like:
class ThisOne extends Exception {Object foo; ThisOne(Object foo) {this.foo=foo;}}
try { x.each{ if(it.isOk()) throw new ThisOne(it); false} }
catch(ThisOne x) { print x.foo + " is ok"; }
After paulmurray's answer I wasn't sure myself what would happen with an Exception thrown from within a closure, so I whipped up a JUnit Test Case that is easy to think about:
class TestCaseForThrowingExceptionFromInsideClosure {
#Test
void testEearlyReturnViaException() {
try {
[ 'a', 'b', 'c', 'd' ].each {
System.out.println(it)
if (it == 'c') {
throw new Exception("Found c")
}
}
}
catch (Exception exe) {
System.out.println(exe.message)
}
}
}
The output of the above is:
a
b
c
Found c
But remember that "one should NOT use Exceptions for flow control", see in particular this Stack Overflow question: Why not use exceptions as regular flow of control?
So the above solution is less than ideal in any case. Just use:
class TestCaseForThrowingExceptionFromInsideClosure {
#Test
void testEarlyReturnViaFind() {
def curSolution
[ 'a', 'b', 'c', 'd' ].find {
System.out.println(it)
curSolution = it
return (it == 'c') // if true is returned, find() stops
}
System.out.println("Found ${curSolution}")
}
}
The output of the above is also:
a
b
c
Found c
Today I faced a similar problem while working with each closure. I wanted to break the flow of execution based on my condition but couldn't do it.
The easiest way to do in groovy is to use any() on a list instead of each if you wish to return a boolean based on some condition.
Good ole for loop still works in Groovy for your use case
for (element in largeListOfElements) {
if(element == specificElement){
// do some work
return
}
}