Haskell is not handling atom types correctly.

[linas]

Haskell currently installs the atomspace/atom_types.script file -- this is wrong on multiple levels: there are about 5 or 6 files called atom_types.script, and haskell needs to be able to handle all of them, not just one.

Also, atom types are dynamically loadable, e.g they may come from a load of the database, so any sort of static approach to the atom type will fail.

[rTreutlein]

Well the current implemenation does complile time checking for atom types wich requires the types to be present during that time. Which is obviously wrong as we want to be able to add types at runtime.

I am tempted to just throw out the whole Haskell Atom Type code and replace it by a simple wrapper over the c++ code.

[ngeiswei]

Although adding Haskell type checking was really cool at the time and @MarcosPividori made a great job to enable it, it is progressively being added to the core AtomSpace anyway, so it wouldn't be such a big lost to throw it out.

[rTreutlein]

Fixed in #591

[linas]

@ngeiswei If I understand correctly, the haskel type system does compile-time type checking. The problem is that there is a need for run-time type checking; consider the construction; superficially, its valid, but it creates something crazy/invalid:

   (PutLink
      (EvaluationLink  (Variable $x)(Variable $y))
      (ListLink (MemberLink (Concept "foo")) (Concept "bar")))

which upon execution, would create

 (EvaluationLink   (MemberLink (Concept "foo")) (Concept "bar"))

which is invalid. One can prevent this, with run-time type checking (this works now):

   (PutLink
      (VariableList
            (TypedVariable (Variable $x)  (Type "PredicateNode"))
            (TypedVariable (Variable $y)  (Type "ListLink")))
      (EvaluationLink  (Variable $x)(Variable $y))
      (ListLink (MemberLink (Concept "foo")) (Concept "bar")))

executing the above will result in the empty set (nothing happens) because the argument fails to match the desired signature. It might be possible to convert the above into a static, compile-time type-check but it gets hard and out of control quickly: e.g. perhaps the MemberLink was not explicitly named, but was the result of some search (i.e. the result of a GetLink) and the search itself was a combination of yet more puts and gets.

This nesting of puts and gets 2 and 3 layers deep is not hypothetical: it is actually being used in the robot behavior tree. None of the gets/puts are "deep", they are just grabbing and assembling assorted state; but they do get nested.