search

coli-saar / alto

Alto, the Algebraic Language Toolkit
Other
17 stars 2 forks source link

enable parametrized use of TreeAutomaton in Algebra#decompose #54

Open jgroschwitz opened 4 years ago

jgroschwitz commented 4 years ago

Algebra#decompose currently returns an unparametrized TreeAutomaton (i.e. just TreeAutomaton instead of TreeAutomaton for some class F). This might be a bit of work. This might be a bit tricky since the default interpretation returns a TreeAutomaton for the Algebra parameter class E, but in general that is not the case.

jgroschwitz commented 4 years ago

A simple "solution" could be to add documentation to the decompose method that advises users to just manually cast the result to a more specific TreeAutomaton when they use a specific algebra. This would not solve the problem completely, but would at least establish a (I think reasonable) best practice.

Maybe the decompose methdod could be turned into a generic method too, but I think that would require the return class to also show up in the inputs, which would be impractical.

Another different issue I noticed which I'm just gonna mention here to not spam too many issues: Several algebras have an evaluate method that can fail (in particular the AM algebra, but a few others as well). There is currently no consensus on what to do in such a case: some algebras return null (mostly just yielding a null exception later), some throw a RuntimeException, some a IllegalArgumentException. I suggest making the latter the standard, adding documentation for this and having the base evaluate method throw an IllegalArgumentException. Since that exception type is a runtime exception it doesn't have to be caught, so no code must be changed, but it would be more visible what kind of exception we expect it to throw.

alexanderkoller commented 4 years ago

Another different issue I noticed which I'm just gonna mention here to not spam too many issues: Several algebras have an evaluate method that can fail (in particular the AM algebra, but a few others as well). There is currently no consensus on what to do in such a case: some algebras return null (mostly just yielding a null exception later), some throw a RuntimeException, some a IllegalArgumentException.

Ah, this is an interesting problem that should probably go into its own issue. We should probably add clear documentation to Algebra#evaluate how a partial algebra should signal that an operation was not defined on the given inputs. I would not be opposed to adding a new type of Exception which is not a subclass of RuntimeException and thus must be handled explicitly. Whoever calls evaluate needs to deal with the possible failure anyway.