zachgk / catln Goto Github PK

In the type intersection method in Syntax.Types, it matches together different PartialTypes which intersect. They currently compare the names for equality, but it should handle as long as one of them has a suffix matching the other. If they are both absolute paths, then it would still be equality.

Right now, the llvm macro has the signature llvm(c) -> CatlnResult where c is the code to build. However, this is not quite right because executing the llvm compiler requires the usage of Haskell IO.

Instead, modify the signature to llvm{IO io}(c) -> CatlnResult{IO io}. Then, pass IO into the evaluation in evalBuild similarly to how it is passed in evalRun. From there, the llvm macro in Eval.Runtime can be responsible for using IO. The LLVMVal should no longer be needed and can be deleted.

It may be required for additional handling for Context values after a build (instead of the expected CatlnResult). In this case, evalBuild should extract the CatlnResult from inside of the context and run the io operation.

If a type like List is a module, it gives a place to look at the functions that are inside the module and likely to be relevant for it. Consider also using them as modules.

This may also involve updating the parsing or desugaring. If a type or a class is a module, then statements inside the type or class declaration can be treated similarly to types or classes inside a module statement. Maybe multitypedef could create the subsidiary types inside of the class created.

This issue is to add a code formatter for Catln similar to go fmt. Having a single consistent style for code built into the compiler can help unify the community and stop many style wars before they start.

The formatter should format the RawPrgm type defined in Syntax.Prgm. It can be implemented using Haskell prettyprinter. It should be implemented in src/Formatter.hs.

Once the formatter is implemented, add a new option to the CLI in app/Main.hs. It should accept a filename, read the file with IO, parse the file with parseFile, run the prettyprinter on the file contents, and then write the formatted contents to the filename.

Implement the macro functionality for context as described in https://catln.dev/philosophy/context/

This issue is to add support for print line debugging to the webdocs debugger. While a debugger is very useful at letting you explore what is happening, it is limited to showing a single point in time. With print line debugging, you can see the events you are interested in across time and more easily find lines indicating something which has gone wrong.

The first step is to add a debug annotation to be used. It should include what data to print out, and optionally a conditional "debugIf" argument.

Then, update the Eval to look for the debug annotation. Add a new value into the Eval Env to store a log of "debug lines". When they are encountered in evaluate annotations, add to this env. Add this value to the EvalResult so it is sent to webdocs.

Finally, update the webdocs debug display in incorporate the debug lines as part of the display.

Optional features to include or leave for a later issue:

• add a conditional "debug when" boolean argument to the debug annotation
• Add a link in the webdocs from the debug line to the location in the debug tree where the debug occurred

In a function defined with context, it should still curry arguments to functions called within it. It can be tested by running test/disabled/curryCtx.ct.

When objects are created, they are able to have statements and comments inside of them. If the first statement inside it is a comment, then it should be treated as the main documentation for the object. Then, it can be added as part of the display when trying to understand a type. This issue is to add this documentation.

The steps required are:

• Add (objDoc :: Maybe String) to the object type
• When desugaring the object, check if it has substatements and if the first is a comment. If it is, add it to the object
• In the webdocs ListProgram.js, it should display the object doc comments if they are available

Making updates to the context will usually be done with a special syntax similar to the Haskell do notation. Unlike Haskell, a "do" shouldn't be necessary as a multi-line = is sufficient. It may be necessary to identify lines using this syntax with a special identifier like <-.

There is a link to a number of publicly licensed single-file C libraries at https://github.com/nothings/stb. It may be worthwhile to use some of these to help add functionality to the stack for various domains.

Fix the commented out implementations of fmap in stack/core/data.ct.

When running type inference, it is possible for some functions to be mutually recursive where they are each calling the other. This issue is to fix the mutual recursion test in testdisabled/mutRec.ct`.

This issue is to add the types and their standard operations to core data.ct. Haskell prelude can be used as a reference.

Similarly to the object documentation (see #12), we should be able to add a documentation String to a class declaration statement. The steps are:

• Modify the parser to parse subStatements under class declarations, multiTypeDeclarations (bounded class), data declarations, and annot declarations
• Add the Maybe String for documentation to the classToType in the classMap
• In the webdocs ListProgram.js, it should display the class doc comments if they are available

Right now, the function defined as toString is used to convert values of various types into strings. The function should be renamed so that users might instead call 5.to<String>. As an intermediate step, 5.to<$T=String> can be used and the final update piece handled in a separate issue.

This rename helps better demonstrate the relationship between the function and the String type. It can be expanded to make better usage of the to function with other overloads for various conversions later as well. This should also be a new test for calling functions with types.

In order to implement this, the parser will also need to be updated. The pCall operation will need to handle type arguments as well as value arguments.

Module paths can be relative or absolute. If it's relative, it refers to just the suffix of the path while an absolute contains the entire path. This should be added into the Object name, type names, module names, and class names.

It also will need to be added to the parser. I imagine that "/Data/Algebra" would refer to an absolute and "Data/Algebra" or "Algebra" would be a relative path. When desugaring, recognize the module prefixes and add those as prefixes to the names in statements. Absolute names in the module don't get the prefix.

So, here are some examples:

class A
  # absolute name of /A

module B
  class C
    # absolute name of /B/C because it is in module B

  class /D
    # absolute name of /D because the name is given as absolute so it doesn't inherit from B

  d = 5
    # absolute name of /B/d

e = /B/d
  # absolute name of /e
   it refers to d using the absolute name

f = d
  # absolute name of /f
    it refers to d by a relative name of "d", which should later be inferred to the absolute name of "/B/d"
    as part of this issue, it may make more sense to only typecheck when all references are absolute so this line can be excluded

The goal of this issue is to first update the syntax to handle both relative and absolute names. The names of objects, function, and class declarations can only be absolute because we can always determine it based on what type it is located in. The names of values in an expression can be either relative or absolute. Partial types can also use either relative or absolute names.

If necessary, updates to the parsing of identifiers may be required to support the usage of relative and absolute names.

Then, handle the module scoping in the desugaring. So, the class declaration for C should be updated to "/B/C".

In the Typecheck.Decode, check if a value was given a relative path and what absolute paths the typechecker guessed for it. If it guessed one, then it is successful. It multiple different absolute paths are matched, it should throw a CErr telling the user they need to specify more details in the relative path along with what objects were matched (so say that it matched List.empty and Graph.empty so must specify which one).

When using relative names, it is not always possible to identify whether it refers to a type or a class. Sometimes, the same relative name can refer to both types and classes. So, there needs to be a third option in the Syntax.Types PartialName tuple. The three options would be:

• TypeName String (Always an absolute name)
• ClassName String (Always an absolute name)
• RelativeName String (Can be type or class)

With this third format, it may also be reasonable to update how the parser and desugaring treats new inputs. Rather than calling everything a type and then renaming some to a class, it may be worth calling everything a relative name, then replacing all relative names which are actually absolute with the corresponding absolute form.

This issue expands the definition of what functions can be run or built in Catln. It should be expanded in Eval with support in both the CLI and webdocs.

After this issue, any function requiring no arguments and with any return value can be run. The function can require a context and that context can contain IO. It can also return a context around the value. In order to support IO operations, it would accept the initial IO through the context and return the one after operating. The return value can be displayed.

There are two kinds of buildable functions. A defined buildable function should be a function with no arguments whose return type is a CatlnResult. These can be built directly. A run buildable function should be a runnable, and it builds llvm(c=runnableFunction).

In the CLI, it should add an optional string after the filename on the run and build command to accept the name to run/build with a default of main.

In webdocs, add a play arrow to any runnable and buildable function.

As part of this, it may also make sense to rename mainx to main. Because the running and building are two separate commands, there shouldn't be confusion for which one they are if both are defined.

Depends on #15.

This issue improves the webdocs by adding links to the objects defined in the ListProgram back to their source location. The source should be in the webdocs/docs. As part of this, IDs to link to must be created in the docs as the linking destination.

The source links can use the positions found as part of objM.

In various sections of webdocs, it could help to show only the components in a module. For example, it could help divide the ListProgram section into ones that are more scalable for large codebases. It may also be useful to have displays of what modules are directly or recursively in the module. Maybe show something in the Type/Class file. This is just some options. Consider breaking this issue into multiple.

Is there any guide to get started with the language? How to install it?

An anonymous tuple is one that has no type, but includes data. It could be something like (x=5, y=3) or (). The anonymous tuple can be implemented as a standard object with a type name of "", but there may need to be an object created for the anonymous tuple either in core or in the compiler accepting any arguments.

This issue is progress towards adding context. It should add the type of Context and convert all of the mainx test and definitions from the signature mainx(IO io) -> IO to mainx{IO io} -> Any{IO io}. This can be used to expand the definition of runnable and buildable functions.

The usage of mappend can be made much simpler by creating a new operator++ and using that to define the operation. This should rename the function and update all of it's usages.