Permalink
Switch branches/tags
Commits on Jun 9, 2015
  1. Got rid of the 'Dao.Rule.PatternClass' and it's

    'Dao.Rule.patternCompare' method. The 'patternCompare' method should
    now be passed explicitly when evaluating 'Dao.Rule.queryAll' or
    similar functions.
    committed Jun 9, 2015
  2. Made the 'Dao.Rule.Rule' data type extremely complicated and nearly

    impossible to understand, but unfortunately, it was necessary.
    
    I really don't like data types which are polymorphic over more than 3
    variables. 'Dao.Rule.Rule' was at my limit, it a monad transformer, so
    already it is polymorphic over the return type and the lifted monadic
    type. Then it allowed a polymorphic error type, and that was my limit.
    I was squeamish to add the polymorphic stateful type, but there is
    just no better way backtrack updates to state as rules are evaluated.
    
    But now I have really gone and done it: I have made the token type
    polymorphic (where it used to be 'Dao.Object.Object'), and I have made
    the pattern type polymorphic (which also used to be a
    'Dao.Object.Object'). So now 'Dao.Rule.Rule' is polymorphic over six
    types.
    
    But using duck typing for patterns and tokens in 'Dao.Rule.Rule's was
    just too limited, it was too easy to confuse patterns with tokens, and
    it was too difficult to define functions that can define matching
    behavior for patterns.
    
    Now the 'queryAll' and related functions all take a function of type
    'Dao.Rule.MatchFunction', which can be monadic, which defines how to
    match a token to a pattern. This is more appropriate than requiring
    your pattern type to install a matching method when instantiating
    'Dao.Object.ObjectData'.
    
    All code has been tested, and the modifications are working properly.
    committed Jun 9, 2015
  3. Added the 'Dao.Predicate.isPFalse', 'Dao.Predicate.isPTrue', and

    'Dao.Predicate.isPError' functions which could be useful when
    filtering through lists of 'Dao.Predicate.Predicate' values.
    committed Jun 9, 2015
  4. The "Dao.Grammar" module now imports "Dao.Object", and instantiates

    many of the built-in grammar data types into the
    'Dao.Object.SimpleData' and 'Dao.Object.ObjectData' classes.
    committed Jun 9, 2015
Commits on Jun 4, 2015
  1. I got rid of the 'Dao.Object.infer' function and removed the

    'Data.Typeable.TypeRep' data type from the list of 'Dao.Object.Simple'
    data type primitives. The 'Dao.Object.Simple' data type is intended to
    be used as a kind of wire-protocol like JSON, and there is no easy way
    to receive a 'Data.Typeable.TypeRep' from over a wire.
    
    I have also instantiated several fundamental data types into the
    'Dao.Object.SimpleData' and 'Dao.Object.ObjectData' classes.
    
    I have also now provided a default instance of the 'Dao.Object.fromObj'
    method of the 'Dao.Object.ObjectData' class, which greatly simplifies
    the instance declarations for numerous data types.
    committed Jun 4, 2015
  2. Added instances of the 'Dao.Text.PPrint.PPrintable',

    'Dao.Object.SimpleData', and 'Dao.Object.ObjectData' classes for the
    'Dao.Text.Regex.Regex' data type and all of it's subordinate data
    types and associated error reporting data types.
    committed Jun 4, 2015
  3. Added instances of the 'Dao.Text.PPrint.PPrintable' class for the

    'Dao.Interval.Inf', 'Dao.Interval.Interval', and 'Dao.Interval.Set'
    data types
    committed Jun 4, 2015
  4. I have created a few more instantiations for the

    'Dao.Text.Location.TextPoint', 'Dao.Text.Location.TextRegion', and
    'Dao.Text.Location.Location' data types, namely instantiations into
    the 'Dao.Object.SimpleData' and 'Dao.Object.ObjectData' classes. I
    have also instantiated 'Dao.Text.Location.Location' into the
    'Dao.Text.PPrint.PPrintable' and 'Prelude.Show' classes.
    committed Jun 4, 2015
  5. I made the 'Dao.Tree.partitions' function more general, making it

    monadic, renaming it to 'Dao.Tree.partitionsWithM', and requesting a
    matching function (the function used to match the given path of the
    partition to the actual paths of the tree) be passed as a parameter,
    rather than using the 'Prelude.==' function for matching. The
    'Dao.Tree.partitionWith' function is provided to conveniently call the
    monadic 'Dao.Tree.partitionWithM' function with a
    'Control.Monad.Identity.Identity' monad and automatically unwrapping
    the result from the monad. The 'Dao.Tree.partition' function remains
    as it was, except now it calls 'Dao.Tree.partitionWith' passing
    'Prelude.==' as the matching function.
    committed Jun 4, 2015
  6. The 'Dao.Lens.Lens' interface allows for imperative programming style

    updates of pure data types in situations where pure functional style
    is less elegant than imperative style. 'Dao.Lens.Lens's also provide
    an opportunity for introducing data types like the
    'Data.Array.ArrayIterator' for iterating over a 'Dao.Array.Array' with
    a somewhat imperative programming style. I am not sure if I want to
    keep these iterator APIs, but they have already come in handy for
    iterating over parsed tokens, so I may decide to keep them.
    committed Jun 4, 2015
  7. After all this time, I had never derived the 'Data.Typeable.Typeable'

    instance for the 'Dao.Count.Count' data type.
    committed Jun 4, 2015
  8. The instantiation of the 'Dao.Interval.Set' data type into the

    'Prelude.Ord' class made use of a the 'Dao.Interval.enumSize'
    function, which required the polymorphic element data type of the
    'Dao.Interval.Set' to be an instance of 'Prelude.Bounded'. This was OK
    for most data types, but I recently ran across a situation where I
    needed to create a partial 'Prelude.Ord'-ering a 'Dao.Interval.Set' of
    'Prelude.Integer's (which are not 'Prelude.Bounded'), and I could not
    because the instance of 'Prelude.Ord' required a 'Prelude.Bounded'
    type. I realized it made absolutely no sense to require the element
    data type to be bounded to instantiate 'Prelude.Ord', so I needed a
    new algorithm for defining partial ordering on 'Dao.Interval.InfBound'
    'Dao.Interval.Set's, so I added the 'Dao.Interval.cardinality'
    function.
    
    I also added the 'Dao.Interval.fromPair' function to make it easier to
    construct 'Dao.Interval.Interval's from pairs of possibly
    'Dao.Interval.Inf'-inite elements.
    committed Jun 4, 2015
Commits on Apr 26, 2015
  1. Changed the weight data type of the 'Dao.Rule.QueryState' from a

    'Double' to a 'Dao.Certainty.Certainty' data type. I also changed the
    'Dao.Rule.queryAll' function return the updated user state values with
    each returned value.
    committed Apr 26, 2015
  2. Added the 'Dao.Grammar.withLocation' function and

    'Dao.Grammar.inlineCommentGrammar' function. I also added the
    'Dao.Grammar.OptSpaceToken' data type. I also fixed the
    'Dao.Grammar.NewLineToken' data type to return the correct newline
    characters that were originally parsed.
    committed Apr 26, 2015
Commits on Apr 25, 2015
  1. Cleaning up some of the mistakes from my previous commit. I had not

    instantiated certain types into certain classes, and I had forgot to
    declare several data types as 'Dao.Object.printable' in the
    various instantiation of types into the 'Dao.Object.obj' function, so
    the test programs were working but not printing any results. This has
    been fixed.
    committed Apr 25, 2015
  2. This commit publishes a major rewrite to the "Dao.Object" module. I

    have updated the 'Dao.Object.Simple' data type such that it may no
    longer contain 'Dao.Object.Object' data types, only other 'Simple'
    data types. As a result, 'Simple' is now something of a protocol for
    transmitting and receiving data types.
    
    Similarly 'Object' no longer contains the 'Simple' data type unless a
    'Simple' type is converted to an 'Object' by way of the
    'Dao.Object.fromForeign' or 'Dao.Object.obj' functions. 'Object' is
    now essentially a superset of the 'Data.Dynamic.Dynamic' data type, as
    in it is like 'Data.Dynamic.Dynamic' but has more features, for
    example the ability to be converted to a 'Simple' type or the ability
    to be 'pPrint'-ed without unwrapping it.
    
    However, the 'Dao.Object.SimpleData' class is still a superclass of
    'Dao.Object.ObjectData', so you cannot instantiate a data type into
    the 'ObjectData' class without instantiating the 'SimpleData' class.
    
    Also, the 'Simple' data type has been extended with the
    'Dao.Object.OStruct' constructor, which operates kind of like
    Haskell's "newtype" keyword. It provides a labeled wrapper for an
    existing 'Simple' type.
    
    Finally, I had to rename the 'Dao.Rule.tree' and 'Dao.Rule.struct'
    functions, because the name 'struct' is now taken by the "Dao.Object"
    module, and also I thought the name 'tree' was misleading.
    committed Apr 25, 2015
Commits on Apr 24, 2015
  1. I have implemented data types and tokenizing grammars for a few common

    programming language paradigms, particularly the C family of
    programming languages. These grammars evaluate to tokenizing parsers
    that will be useful to a very wide variety of programming languages.
    Even though this does increase the size of the Grammar module's memory
    footprint.  I may someday fork this code off into a separate package,
    but for now I think it would be better to have these function than to
    not have them.
    committed Apr 24, 2015
  2. Created the 'Dao.Rule.prunePaths' function. I finally figured out how

    to accomplish this, but it required the use of Rank-N types and making
    use of 'Data.Typeable.cast'. What is most unfortunate is that the only
    way to accomplish this is also to demand that the polymorphic types
    provided to the 'Dao.Rule.Rule' monad all instantiate the
    'Data.Typeable.Typeable'. This is something of a hassle, even with
    GHC's AutoDeriveTypeable feature (which I don't use because I want to
    explicit derive Typeable). I am not happy with this change, I think
    it is something of a hack, but it really is the only way to provide a
    useful 'Dao.Rule.prunePaths' function. I am compromising elegance for
    pragmatism.
    committed Apr 24, 2015
Commits on Apr 23, 2015
  1. I have decided to make the 'Dao.Rule.StatefulRule' data type a bit more

    polymorphic. I will redesign it so that it will not need to rely on
    'Dao.Object.Object' to do anything, it will be another general monad
    transformer like 'Dao.Logic.LogicT', and 'Dao.Predicate.PredicateT'.
    
    In this commit, I have finished transitioning the 'Dao.Rule.Rule' data type to
    a more general monad transformer. Of course, the data type has now become
    incredibly polymorphic and esoteric. I will need to write some simplifying
    type synonyms. I have already tested the modifications, and all of the test
    programs are still working as if there has been no change.
    
    The "Dao.Object" module now depends on the "Dao.Rule" module, rather than the
    other way around as it did before. The 'Similarity' data type and the
    'PatternClass' class has been moved from "Dao.Object" to "Dao.Rule". The
    'infer' function has moved from the "Dao.Rule" module to the "Dao.Object"
    module.
    committed Apr 23, 2015
  2. I have decided to make the 'Dao.Rule.StatefulRule' data type a bit more

    polymorphic. I will redesign it so that it will not need to rely on
    'Dao.Object.Object' to do anything, it will be another general monad
    transformer like 'Dao.Logic.LogicT', and 'Dao.Predicate.PredicateT'.
    
    In this commit, I have made 'Dao.Rule.StatefulRule' polymorphic over the
    throwable error type.
    committed Apr 23, 2015
Commits on Apr 22, 2015
  1. Bug fix: I had derived the equation for tab completion incorrectly. I…

    … had
    
    correctly derived the equation to partially evaluate token input, but I had not
    derived any equation for predicting what possible next token inputs could be
    accepted. I have now completed deriving this equation, and I have even tested
    it, now tab completion is working much more closely to the way I had
    envisioned.
    
    The 'Dao.Rule.PartialQueryResult' data type has been modified to contain a tree
    of possible future token inputs, and the 'Dao.Rule.partialQueryBranches' has
    been added to access what was the 'Dao.Rule.partialQueryNextSteps' function.
    The 'Dao.Rule.partialQueryNextSteps' function has been modified to access the
    predicted token input. No other changes to the API have been made, all other
    modifications were made only to equations that are not exported.
    committed Apr 22, 2015
  2. Did a rather substantial rewrite of the machinery of the 'Dao.Rule.Rule'

    class. On the surface, only two API functions have changed. (1) The
    'limitByScore' function has been removed, and it may be restored in the
    near future but for now there is no good way to implement it given the
    changes. (2) The 'guessPartial' function has been added, which makes it
    easier to implement predictive input (e.g. tab completion on command
    lines).
    
    The biggest change I have made is that the 'Dao.Rule.StaefulRule' monad
    no longer lifts the 'Dao.Logic.LogicT' monad, and as a result
    'StatefulRule' no longer instantiates 'Dao.Logic.MonadLogic'. Now,
    'StatefulRule' could be said to "compile" to a 'LogicT' monad by way of
    the 'evalRuleLogic' function, but 'StatefulRule' is otherwise a
    completely independent domain specific language now.
    
    The reason this was necessary was because I had discovered that partial
    queries performed by the 'Dao.Rule.partialQuery' function were
    impossible when an arbitrary 'Dao.Logic.LogicT' monad could be lifted.
    The reason this was impossible was because some functions, for example
    the 'Dao.Rule.bestMatch' function, were able to collapse a
    'Dao.Rule.StatefulRule' using the 'Dao.Rule.evalRuleLogic' arbitrarily.
    This meant that using the 'bestMatch' function would result in the
    'StatefulRule' being collapsed into a 'LogicT' monad, then lifted back
    into a 'StatefulRule' after some modifications to the state had been
    made. When this happened, all information about the rule tree was
    evaluated to a 'LogicT' monad and therefore made inaccessible to the
    'partialQuery' function.
    
    The 'Dao.Rule.StatefulRule' monad needs to be homogeneous monadic data
    structure, like a list monad. Functions must not have the ability to
    obscure the data structure by evaluating it to an opaque function data
    type and re-lifting the evaluated bit back into the monad. This was the
    change I made; it is now impossible to lift a 'LogicT' monad into a
    'Dao.Rule.StatefulRule', and the tree structure is therefore always
    available for analysis. The 'Dao.Logic.LogicT' monad is still useful as
    an intermediate step during evaluation of the rule to it's lifted monad.
    committed Apr 22, 2015
  3. I had to change the names of some of the API functions in the

    "Dao.Predicate" module to match the recently renamed constructors for the
    'Dao.Predicate.Predicate' data type, the following function renaming has
    been performed:
    
        okToList     ->   pTrueToList
        okToJust     ->   pTrueToJust
        maybeToPFail ->   maybeToPError
        fmapPFail    ->   fmapPError
    committed Apr 22, 2015
Commits on Apr 19, 2015
  1. I finally got around to fixing the predictive input functionality of the

    'Dao.Rule.StatefulRule' monad. The previous implementation simply did
    not work at all. Although this new implementation has not been tested
    yet, I have confidence that I have at least begun to solve the problem
    from the previous implementation. I have created the
    'Dao.Rule.partialQuery', 'Dao.Rule.resumePartialQuery', and
    'Dao.Rule.guesses' functions, and the 'Dao.Rule.PartialQueryResult' data
    type along with the necessary lenses for it. The
    'Dao.Rule.PartialQueryResult' holds the necessary information for
    constructing predictive input guesses, and for continuing a partial
    query when additional input appended.
    committed Apr 19, 2015
  2. Created the 'Dao.Tree.partitions' function, which lets you partition a

    path according to whether the path exists in the tree or not. Since a
    path can match many times, this function produces many possible results.
    This function is essential for implementing the 'Dao.Rule.partialQuery'
    function.
    committed Apr 19, 2015
  3. I flipped around the type variables for the error and state type in the

    'Dao.Predicate.PredicateState' data type to make it more consistent with
    other monad transformers. The reason I initially put the state type
    before the error type was to provide an indication that this was a
    'Control.Monad.State.StateT' monad transformer lifted into a
    'Dao.Predicate.PredicateT' monad transformer, and not the other way
    around. But for every other monad transformer I have ever used, the
    convention is that the error type always comes first, before the state
    type if there is one. So when it actually came time for me to use the
    'Dao.Predicate.PredicateState' monad transformer, I wrote my code
    according to this convention of error first state second, and of course
    I was very confused when it didn't type check. No more of this, I am
    going back to the "normal" convention of putting the error type before
    the state type.
    committed Apr 19, 2015
  4. Instantiated 'Data.Monoid.Sum', 'Data.Monoid.Product', 'Data.Monoid.D…

    …ual', 'Data.Monoid.Any',
    
    'Data.Monoid.All' into the 'Dao.TestNull.TestNull' class.
    committed Apr 19, 2015
Commits on Apr 8, 2015
  1. Added the 'Dao.Text.Location.HasCurrentLocation' class with the

    'Dao.Text.Location.currentLocation' method. I did this because I was
    creating a function called 'currentLocation' in several modules which
    all did the same thing.
    committed Apr 8, 2015
Commits on Apr 6, 2015
  1. I had pulled in some example programs to use as test files, and to

    make it easier to rebuild after changing code, I included these files
    in the Dao.cabal file, but I did not commit these files. So
    unfortunately anyone who wanted to build Dao from the source on GitHub
    would have had trouble building until they removed those example
    programs from the Dao.cabal file. I have fixed this for now.
    committed Apr 6, 2015
  2. Also I am no longer testing individual functions by hand with the GHCI

    ":trace" feature, so I updated the .ghci file to disable the
    -fbreak-on-exception flag.
    committed Apr 6, 2015
  3. The 'Dao.Lens.Contains' class turns out to be completely useless when

    the -XOverlappingInstances language feature is enabled (which it
    always in in the Dao library). So I removed this class.
    committed Apr 6, 2015
  4. Created the 'Dao.Text.Location.HasLocation' class. This class has

    similar functionality to the class of the same name in previous
    versions of the Dao library, however this class provides a
    'Dao.Lens.Lens' rather than ordinary functions.
    committed Apr 6, 2015