I get the following error message:
"failure in proveterminate Error: Partial application of function convert_btree_to_tree in its body is not allowed while using Function"
from the following piece of Coq script, but I have no idea what is wrong. Can anyone give me some advice?
Function convert_btree_to_tree (t: btree (non_terminal' non_terminal terminal) terminal) {measure (fun t => bheight _ _ t)}:
tree (non_terminal' non_terminal terminal) terminal:=
let tl:= decompose t in
let ttl:= map convert_btree_to_tree tl in
let ttl':= convert_list_tree_to_tree_list ttl in
match broot _ _ t with
| inl n => node _ _ n ttl'
| inr t => node_t _ _ t
end.
Documentation on Function is very limited in the Reference Manual, does anybody know of a more complete and detailed reference, if possible with comments and examples?
I don't know much about Function but in your match, you return a node and a node_t. Since you didn't give the definitions, I don't know if these two constructors are from the same type, but I think you have a typo and the second case should return node t _ _ t.
EDIT after feedback from Marcus:
node_t is a constructor of tree which signature is terminal -> tree: given a term foo of type terminal, node_t foo is of type tree. node has the signature non_terminal -> tree_list -> tree.
Do you have any implicit parameters declared ? Otherwise, in your match cases, you apply too many arguments to node and node_t, which might be interpreted as partial application.
Related
I am trying to make multi-file form input. I am using Handling a collection of data in a Yesod Form as a reference.
Here I am trying to make association list of field names to files.
multiFileInput :: Monad m => RenderMessage (HandlerSite m) FormMessage =>
[Text] -> FormInput m [(Text, FileInfo)]
multiFileInput = mapM $ secondM (ireq fileField) . (getFieldKey &&& id)
I get error:
Could not deduce (Monad (FormInput m))
arising from a use of ‘mapM’
But I don't know how to handle this. If I just add this as a constraint I have to propagade this constraint "(Monad (FormInput Handler))" up to a call site, where I don't know how to handle it. FormInput m is an instance of Monad, so I don't understand the issue.
fileInfos <- runInputPost $ multiKeyFileInput "files"
-> No instance for (Monad (FormInput Handler))
arising from a use of ‘multiKeyFileInput’
I will try to use runRequestBody instead, but it would be nice to understand the problem.
The FormInput data type was supposedly changed from Monad to Applicative, so you have to use traverse, which is an Applicative version of mapM.
I am following various Thermite tutorials about setting up task lists. The only tutorial with a lot of explanation is also quite far out of date, so I am modifying it to fit the current Thermite. However, I have one call in which I cannot make the data types match.
import Optic.Lens (lens)
import Optic.Prism (prism)
import Optic.Types (Prism', Lens')
import Thermite as T
_TaskAction :: Prism' TaskListAction (Tuple Int TaskAction)
_TaskAction = ...
_tasks :: Lens' TaskListState (L.List TaskState)
_tasks = lens _.tasks (_ { tasks = _ })
taskList :: T.Spec _ TaskListState _ TaskListAction
taskList = T.focus _tasks _TaskAction taskSpec
However, this gives me an error message:
Could not match type
p0
with type
Function
while trying to match type p0 t1
with type Function
(List
{ text :: String
}
)
while checking that expression _tasks
has type p0 t1 t1 -> p0 t2 t2
in value declaration taskList
where p0 is a rigid type variable
bound at line 213, column 20 - line 213, column 26
t1 is an unknown type
t2 is an unknown type
The error message is specifically talking about the _tasks parameter I am passing to T.focus. But I do not know what the error is trying to tell me. I also know that the type signature for T.focus is...
focus :: forall eff props state2 state1 action1 action2.
Lens' state2 state1
-> Prism' action2 action1
-> Spec eff state1 props action1
-> Spec eff state2 props action2
So, the first parameter is a lens.
More frustratingly, I've checked more modern (but larger and less comprehensible) example code, and it shows exactly the same definition for _tasks as I have here.
So, what does this error message mean, and what do I need to do to fix it?
The fact that you're importing Optic.Lens suggests that you're using the wrong lens library here. purescript-lens provides traditional van-Laarhoven lenses (like Haskell's lens library), but Thermite uses the profunctor-lenses library.
I'm trying to proof that the evaluation of the untyped lambda calculus according to the following function:
def eval(t: Term): Option[Term] = t match {
case App(t1, t2) => eval(t1) match {
case Some(Abs(x, body)) => eval(t2) match {
case Some(v2) => eval(subst(x, v2, body))
case None() => None[Term]()
}
case _ => None[Term]() // stuck
}
case _ => Some(t) // Abs or Var, already a value
}
returns either None or a value. However, I was pointed out that this function might not terminate. My question is how can introduce as a precondition in Leon/Stainless that a function must terminate?
I'm unaware of a way to introduce a precondition that specifically says "this function terminates (at the arguments given)". You should try to figure out a more high-level predicate which is equivalent to that. In your case, that's not going to work out, because you can't give a computable predicate that determines whether a term in untyped lambda calculus has a normal form.
Not all is lost though: The usual approach here is to introduce an additional "fuel" argument of type BigInt. It represents the maximal number of reduction steps to be performed. In each step, you decrement the fuel by one. If the fuel is zero, you abort the recursion and return None. This will trivially make your function terminate.
However, you always need to supply a "big enough" fuel. Usually the fuel will be a parameter and the lemma has a precondition that eval(fuel, t) = Some(u).
I am new to scala , I have written same code in 2 ways . But i am bit confused between 2 ways. In Second way argument type of f are derived automatically but in type1 scala compiler is not able to do the same . I just want to understand what is the thought behind this .
Type1: Gives compilation error
def rightFold[A,B](xs:List[A],z:B,f:(A,B) => B ): B = xs match {
case Nil => z
case Cons(x,xs) => f(x,rightFold(xs,z,f))
}
def sum1(l:List[Int]) = rightFold(l,0.0,_ + _)
Type2 : Works fine
def rightFold[A,B](xs:List[A],z:B)(f:(A,B) => B ): B = xs match {
case Nil => z
case Cons(x,xs) => f(x,rightFold(xs,z)(f))
}
def sum1(l:List[Int]) = rightFold(l,0.0)(_ + _)
Type inference flows from left-to-right through argument lists. In other words, type information from left argument lists is available in right argument lists, but argument types within the same list are inferred independently.
This is not about function types need to be passed in a separate group of arguments (currying).The problem is with your usage of + on types that the Scala doesn't know about yet.
When you curry a function, the compiler is able to infer the type of the first two arguments as being List[Int] and Double already. This allows the + to be resolved as it knows that the types are Int and Dobule on the two sides.
Now why can't the compiler do the same with the single arguments list - that's just how it is, type information is not available within an argument list.
Type 1 would work if instead of passing in _ + _ you pass in (a: Int, b: Double) => (a + b)). Currying the function lets you use the underline syntax, because the scala compiler has inferred what types A and B are by the time you try and pass in the addition function.
With single list an inferred type of A depends on the types of xs and f. But with the two lists of arguments it depends just on the xs type.
When I pass a record to javascript, it works:
data Record = Record {
elem :: String
}
doSomethingForeign :: Record -> Fay ()
doSomethingForeign = ffi " callJsFun(%1) "
But when the function is not monomorphical, the record is not evaluated, one needs to do it manually:
class Passable a
instance Passable Record
instance Passable Text
doSomethingForeign' :: (Passable a) => a -> Fay ()
doSomethingForeign' = ffi " callJsFun(Fay$$_(%1)) "
This is the simple case, when the extra typing of Fay$$_ isn't that annoying, but if I pass more complex structures with type parameters to js, then adding just Fay$$_ won't solve it. I'd like to know the rule, when the evaluation to native js types is applied and where not.
The thunks will remain and type conversions won't happen if you have a type variable or Ptr X in the FFI, in contrast to a concrete type or Automatic a where the opposite applies.
I think what you want here is :: Passable a => Automatic a -> Fay () to force any thunks. It should be equivalent to separating this into two functions with a monomorphic argument. Using Automatic with a foreign type such as Text will only force the thunk and not do any type conversions.