Idris2/idris2api.ipkg

278 lines
6.1 KiB
Plaintext
Raw Normal View History

package idris2
version = 0.5.1
modules =
Algebra,
Algebra.Preorder,
Algebra.Semiring,
Algebra.ZeroOneOmega,
Compiler.ANF,
Compiler.CaseOpts,
Compiler.Common,
Compiler.CompileExpr,
Compiler.Generated,
Compiler.Inline,
Compiler.LambdaLift,
Compiler.NoMangle,
Compiler.Opts.CSE,
Compiler.Separate,
2020-07-10 12:03:21 +03:00
Compiler.VMCode,
Compiler.Opts.ConstantFold,
Compiler.Opts.Identity,
Compiler.Opts.InlineHeuristics,
Compiler.ES.Ast,
Compiler.ES.Codegen,
Compiler.ES.Doc,
2020-07-10 12:03:21 +03:00
Compiler.ES.Javascript,
Compiler.ES.Node,
Compiler.ES.State,
2020-07-10 12:03:21 +03:00
Compiler.ES.TailRec,
Compiler.ES.ToAst,
2020-07-10 12:03:21 +03:00
2021-07-07 19:06:59 +03:00
Compiler.Interpreter.VMCode,
Compiler.RefC,
Compiler.RefC.CC,
Compiler.RefC.RefC,
Compiler.Scheme.Chez,
Compiler.Scheme.ChezSep,
Compiler.Scheme.Racket,
Compiler.Scheme.Gambit,
Compiler.Scheme.Common,
Core.AutoSearch,
Core.Binary,
Core.Binary.Prims,
2021-10-02 14:55:21 +03:00
Core.Case.CaseBuilder,
Core.Case.CaseTree,
Core.Case.Util,
Core.CompileExpr,
2020-07-10 12:03:21 +03:00
Core.Context,
Core.Context.Context,
Core.Context.Data,
Core.Context.Log,
Core.Core,
Core.Coverage,
Core.Directory,
Core.Env,
Core.FC,
Core.GetType,
Core.Hash,
Core.InitPrimitives,
Core.LinearCheck,
Core.Metadata,
Core.Name,
Core.Name.Namespace,
Core.Normalise,
Core.Normalise.Convert,
Core.Normalise.Eval,
Core.Normalise.Quote,
Core.Options,
Core.Options.Log,
Core.Ord,
Core.Primitives,
Core.Reflect,
Experimental Scheme based evaluator (#1956) This is for compiled evaluation at compile-time, for full normalisation. You can try it by setting the evaluation mode to scheme (that is, :set eval scheme at the REPL). It's certainly an order of magnitude faster than the standard evaluator, based on my playing around with it, although still quite a bit slower than compilation for various reasons, including: * It has to evaluate under binders, and therefore deal with blocked symbols * It has to maintain enough information to be able to read back a Term from the evaluated scheme object, which means retaining things like types and other metadata * We can't do a lot of the optimisations we'd do for runtime evaluation particularly setting things up so we don't need to do arity checking Also added a new option evaltiming (set with :set evaltiming) to display how long evaluation itself takes, which is handy for checking performance. I also don't think we should aim to replace the standard evaluator, in general, at least not for a while, because that will involve rewriting a lot of things and working out how to make it work as Call By Name (which is clearly possible, but fiddly). Still, it's going to be interesting to experiment with it! I think it will be a good idea to use it for elaborator reflection and type providers when we eventually get around to implementing them. Original commit details: * Add ability to evaluate open terms via Scheme Still lots of polish and more formal testing to do here before we can use it in practice, but you can still use ':scheme <term>' at the REPL to evaluate an expression by compiling to scheme then reading back the result. Also added 'evaltiming' option at the REPL, which, when set, displays how long normalisaton takes (doesn't count resugaring, just the normalisation step). * Add scheme evaluation mode Different when evaluating everything, vs only evaluating visible things. We want the latter when type checking, the former at the REPL. * Bring support.rkt up to date A couple of missing things required for interfacing with scheme objects * More Scheme readback machinery We need these things in the next version so that the next-but-one version can have a scheme evaluator! * Add top level interface to scheme based normaliser Also check it's available - currently chez only - and revert to the default slow normaliser if it's not. * Bring Context up to date with changes in main * Now need Idris 0.5.0 to build * Add SNF type for scheme values This will allow us to incrementally evaluate under lambdas, which will be useful for elaborator reflection and type providers. * Add Quote for scheme evaluator So, we can now get a weak head normal form, and evaluate the scope of a binder when we have an argument to plug in, or just quote back the whole thing. * Add new 'scheme' evaluator mode at the REPL Replacing the temporary 'TmpScheme', this is a better way to try out the scheme based evaluator * Fix name generation for new UN format * Add scheme evaluator support to Racket * Add another scheme eval test With metavariables this time * evaltiming now times execution too This was handy for finding out the difference between the scheme based evaluator and compilation. Compilation was something like 20 times faster in my little test, so that'd be about 4-500 times faster than the standard evaluator. Ouch! * Fix whitespace errors * Error handling when trying to evaluate Scheme
2021-09-24 22:38:55 +03:00
Core.SchemeEval,
Core.Termination,
Core.Transform,
Core.TT,
2021-10-13 13:12:05 +03:00
Core.TT.Traversals,
Core.TTC,
Core.Unify,
Core.UnifyState,
Core.Value,
Experimental Scheme based evaluator (#1956) This is for compiled evaluation at compile-time, for full normalisation. You can try it by setting the evaluation mode to scheme (that is, :set eval scheme at the REPL). It's certainly an order of magnitude faster than the standard evaluator, based on my playing around with it, although still quite a bit slower than compilation for various reasons, including: * It has to evaluate under binders, and therefore deal with blocked symbols * It has to maintain enough information to be able to read back a Term from the evaluated scheme object, which means retaining things like types and other metadata * We can't do a lot of the optimisations we'd do for runtime evaluation particularly setting things up so we don't need to do arity checking Also added a new option evaltiming (set with :set evaltiming) to display how long evaluation itself takes, which is handy for checking performance. I also don't think we should aim to replace the standard evaluator, in general, at least not for a while, because that will involve rewriting a lot of things and working out how to make it work as Call By Name (which is clearly possible, but fiddly). Still, it's going to be interesting to experiment with it! I think it will be a good idea to use it for elaborator reflection and type providers when we eventually get around to implementing them. Original commit details: * Add ability to evaluate open terms via Scheme Still lots of polish and more formal testing to do here before we can use it in practice, but you can still use ':scheme <term>' at the REPL to evaluate an expression by compiling to scheme then reading back the result. Also added 'evaltiming' option at the REPL, which, when set, displays how long normalisaton takes (doesn't count resugaring, just the normalisation step). * Add scheme evaluation mode Different when evaluating everything, vs only evaluating visible things. We want the latter when type checking, the former at the REPL. * Bring support.rkt up to date A couple of missing things required for interfacing with scheme objects * More Scheme readback machinery We need these things in the next version so that the next-but-one version can have a scheme evaluator! * Add top level interface to scheme based normaliser Also check it's available - currently chez only - and revert to the default slow normaliser if it's not. * Bring Context up to date with changes in main * Now need Idris 0.5.0 to build * Add SNF type for scheme values This will allow us to incrementally evaluate under lambdas, which will be useful for elaborator reflection and type providers. * Add Quote for scheme evaluator So, we can now get a weak head normal form, and evaluate the scope of a binder when we have an argument to plug in, or just quote back the whole thing. * Add new 'scheme' evaluator mode at the REPL Replacing the temporary 'TmpScheme', this is a better way to try out the scheme based evaluator * Fix name generation for new UN format * Add scheme evaluator support to Racket * Add another scheme eval test With metavariables this time * evaltiming now times execution too This was handy for finding out the difference between the scheme based evaluator and compilation. Compilation was something like 20 times faster in my little test, so that'd be about 4-500 times faster than the standard evaluator. Ouch! * Fix whitespace errors * Error handling when trying to evaluate Scheme
2021-09-24 22:38:55 +03:00
Core.SchemeEval.Builtins,
Core.SchemeEval.Compile,
Core.SchemeEval.Evaluate,
Core.SchemeEval.Quote,
Core.SchemeEval.ToScheme,
IdrisPaths,
Idris.CommandLine,
Idris.Desugar,
Idris.Desugar.Mutual,
Idris.Env,
Idris.Doc.Annotations,
Idris.Doc.Keywords,
Idris.Doc.HTML,
Idris.Doc.String,
Idris.Driver,
Idris.Error,
Idris.ModTree,
2021-04-15 16:08:50 +03:00
Idris.Package,
2021-04-15 16:08:50 +03:00
Idris.Package.Init,
Idris.Package.Types,
Idris.Parser,
Idris.Parser.Let,
2020-07-22 22:16:43 +03:00
Idris.Pretty,
Idris.Pretty.Render,
Idris.ProcessIdr,
Idris.REPL,
Idris.Resugar,
Idris.SetOptions,
Idris.Syntax,
Idris.Version,
2020-07-10 12:03:21 +03:00
Idris.Elab.Implementation,
Idris.Elab.Interface,
Idris.IDEMode.CaseSplit,
Idris.IDEMode.Commands,
Idris.IDEMode.Holes,
Idris.IDEMode.MakeClause,
Idris.IDEMode.Parser,
Idris.IDEMode.Pretty,
2020-07-10 12:03:21 +03:00
Idris.IDEMode.REPL,
Idris.IDEMode.SyntaxHighlight,
Idris.IDEMode.TokenLine,
Idris.REPL.Common,
Idris.REPL.Opts,
Idris.REPL.FuzzySearch,
Libraries.Control.ANSI,
Libraries.Control.ANSI.CSI,
Libraries.Control.ANSI.SGR,
Libraries.Control.Delayed,
Libraries.Data.ANameMap,
Libraries.Data.DList,
Libraries.Data.Fin,
Libraries.Data.Graph,
Libraries.Data.IMaybe,
Libraries.Data.IntMap,
Libraries.Data.IOArray,
Libraries.Data.IOMatrix,
Libraries.Data.LengthMatch,
Libraries.Data.List.Extra,
Libraries.Data.List.Quantifiers.Extra,
Libraries.Data.List.Lazy,
Libraries.Data.List1,
Libraries.Data.NameMap,
Libraries.Data.NameMap.Traversable,
Libraries.Data.PosMap,
Libraries.Data.Primitives,
Libraries.Data.Span,
Libraries.Data.SortedMap,
Libraries.Data.SortedSet,
Libraries.Data.String.Extra,
Libraries.Data.String.Iterator,
Libraries.Data.StringMap,
Libraries.Data.StringTrie,
Libraries.Data.UserNameMap,
Libraries.Data.Version,
2021-04-15 16:08:50 +03:00
Libraries.System.Directory.Tree,
Libraries.Text.Bounded,
Libraries.Text.Distance.Levenshtein,
Libraries.Text.Lexer,
Libraries.Text.Lexer.Core,
Libraries.Text.Lexer.Tokenizer,
Libraries.Text.Literate,
Libraries.Text.Parser,
Libraries.Text.Parser.Core,
Libraries.Text.PrettyPrint.Prettyprinter,
Libraries.Text.PrettyPrint.Prettyprinter.Doc,
Libraries.Text.PrettyPrint.Prettyprinter.Render.HTML,
Libraries.Text.PrettyPrint.Prettyprinter.Render.String,
Libraries.Text.PrettyPrint.Prettyprinter.Render.Terminal,
Libraries.Text.PrettyPrint.Prettyprinter.SimpleDocTree,
Libraries.Text.PrettyPrint.Prettyprinter.Symbols,
Libraries.Text.PrettyPrint.Prettyprinter.Util,
Libraries.Text.Quantity,
Libraries.Text.Token,
Libraries.Utils.Binary,
Libraries.Utils.Octal,
Libraries.Utils.Path,
Experimental Scheme based evaluator (#1956) This is for compiled evaluation at compile-time, for full normalisation. You can try it by setting the evaluation mode to scheme (that is, :set eval scheme at the REPL). It's certainly an order of magnitude faster than the standard evaluator, based on my playing around with it, although still quite a bit slower than compilation for various reasons, including: * It has to evaluate under binders, and therefore deal with blocked symbols * It has to maintain enough information to be able to read back a Term from the evaluated scheme object, which means retaining things like types and other metadata * We can't do a lot of the optimisations we'd do for runtime evaluation particularly setting things up so we don't need to do arity checking Also added a new option evaltiming (set with :set evaltiming) to display how long evaluation itself takes, which is handy for checking performance. I also don't think we should aim to replace the standard evaluator, in general, at least not for a while, because that will involve rewriting a lot of things and working out how to make it work as Call By Name (which is clearly possible, but fiddly). Still, it's going to be interesting to experiment with it! I think it will be a good idea to use it for elaborator reflection and type providers when we eventually get around to implementing them. Original commit details: * Add ability to evaluate open terms via Scheme Still lots of polish and more formal testing to do here before we can use it in practice, but you can still use ':scheme <term>' at the REPL to evaluate an expression by compiling to scheme then reading back the result. Also added 'evaltiming' option at the REPL, which, when set, displays how long normalisaton takes (doesn't count resugaring, just the normalisation step). * Add scheme evaluation mode Different when evaluating everything, vs only evaluating visible things. We want the latter when type checking, the former at the REPL. * Bring support.rkt up to date A couple of missing things required for interfacing with scheme objects * More Scheme readback machinery We need these things in the next version so that the next-but-one version can have a scheme evaluator! * Add top level interface to scheme based normaliser Also check it's available - currently chez only - and revert to the default slow normaliser if it's not. * Bring Context up to date with changes in main * Now need Idris 0.5.0 to build * Add SNF type for scheme values This will allow us to incrementally evaluate under lambdas, which will be useful for elaborator reflection and type providers. * Add Quote for scheme evaluator So, we can now get a weak head normal form, and evaluate the scope of a binder when we have an argument to plug in, or just quote back the whole thing. * Add new 'scheme' evaluator mode at the REPL Replacing the temporary 'TmpScheme', this is a better way to try out the scheme based evaluator * Fix name generation for new UN format * Add scheme evaluator support to Racket * Add another scheme eval test With metavariables this time * evaltiming now times execution too This was handy for finding out the difference between the scheme based evaluator and compilation. Compilation was something like 20 times faster in my little test, so that'd be about 4-500 times faster than the standard evaluator. Ouch! * Fix whitespace errors * Error handling when trying to evaluate Scheme
2021-09-24 22:38:55 +03:00
Libraries.Utils.Scheme,
Libraries.Utils.Shunting,
Libraries.Utils.String,
Libraries.Utils.Term,
2020-07-10 12:03:21 +03:00
Parser.Package,
Parser.Source,
Parser.Support,
Parser.Unlit,
2020-05-20 23:27:50 +03:00
Parser.Lexer.Common,
Parser.Lexer.Package,
Parser.Lexer.Source,
2020-07-10 12:03:21 +03:00
Parser.Rule.Package,
Parser.Rule.Source,
2020-07-10 12:03:21 +03:00
Protocol.IDE,
Protocol.IDE.Command,
Protocol.IDE.Decoration,
Protocol.IDE.FileContext,
Protocol.IDE.Formatting,
Protocol.IDE.Holes,
Protocol.IDE.Result,
Protocol.IDE.Highlight,
Protocol.Hex,
Protocol.SExp,
2022-01-06 13:09:29 +03:00
Protocol.SExp.Parser,
TTImp.BindImplicits,
TTImp.Elab,
2020-07-10 12:03:21 +03:00
TTImp.Impossible,
TTImp.Parser,
TTImp.PartialEval,
TTImp.ProcessBuiltin,
2020-07-10 12:03:21 +03:00
TTImp.ProcessData,
TTImp.ProcessDecls,
TTImp.ProcessDef,
TTImp.ProcessParams,
TTImp.ProcessRecord,
TTImp.ProcessRunElab,
TTImp.ProcessTransform,
TTImp.ProcessType,
TTImp.Reflect,
TTImp.TTImp,
TTImp.TTImp.Functor,
2020-07-10 12:03:21 +03:00
TTImp.Unelab,
TTImp.Utils,
TTImp.WithClause,
TTImp.Elab.Ambiguity,
TTImp.Elab.App,
TTImp.Elab.As,
TTImp.Elab.Binders,
TTImp.Elab.Case,
TTImp.Elab.Check,
TTImp.Elab.Delayed,
TTImp.Elab.Dot,
TTImp.Elab.Hole,
TTImp.Elab.ImplicitBind,
TTImp.Elab.Lazy,
TTImp.Elab.Local,
TTImp.Elab.Prim,
TTImp.Elab.Quote,
TTImp.Elab.Record,
TTImp.Elab.Rewrite,
TTImp.Elab.RunElab,
TTImp.Elab.Term,
TTImp.Elab.Utils,
2020-07-10 12:03:21 +03:00
TTImp.Interactive.CaseSplit,
TTImp.Interactive.ExprSearch,
TTImp.Interactive.GenerateDef,
TTImp.Interactive.MakeLemma,
Yaffle.Main,
Yaffle.REPL
depends = network
sourcedir = "src"