sparrow-lang / sparrow Goto Github PK

Docker builds started working for a while. Fix any compilation issues after removing Conan from build system.

Make sure we can define ctors outside classes.

Very minimal library: one header + one C source file

min.h:
int min(int a, int b);

min.c:
int min(int a, int b) {
return a<b ? a : b;
}

Add a makefile that creates a static library (libmin.a) our of the given files.

This will be used as a working library of C code to import.

The linux version of Travis-CI must also execute performance tests after running the functional tests. It should test both run-time performance and compilation time.

Make sure it publishes the data to another git repository from which we build a static site with Jekyll to display the data.

Optional features:

• performance analysis is done on Travis, rather than on the site
• automatic email are sent with performance summary

You cannot compile a file with the name "test.spr" because the compiler first searches into SparrowImplicitLib and then into the local folder.

see original split of files in "par".
One import will lead to compilation of the body, and to other imports.

Sparrow source files should be treated as modules. Modules could be compiled independently. Rework the "import" model.

Some of the features of Sparrow modules:

• modules are independent of each-other
• using & non-using imports -- imports always generate using decls
• named imports
• public & private using declarations
• public & private imports
• selective imports
• separate compilation

• import a basic void function
• import basic types

Test case:

fun mySprFunctionDecl0(p1: #Concept1, p2: @@#Concept1, p3: #Concept1)
args: [TypeNode(@Bartype), TypeNode(@@FooType mut), TypeNode(FooType)]
fun mySprFunctionDecl0(p1: BarType, p2: @FooType, p3: FooType)

$testFile$.spr(12:1-2) : ERROR : Invalid function call; parameter p2 expected type @FooType, given @@FooType

$testFile$.spr(15:1-2) : INTERNAL ERROR : Cannot create code that calls generic function

Hello,

when I try to compile sparrow, the LLVM_6 branch, on linux x86_64 system with llvm version 6.0.0 I get compilation error:

/bin/ld: /src/sparrow-0.11.35-20180425/build/bin/libSparrowFrontend.a(parserIf.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [src/SparrowCompiler/CMakeFiles/SparrowCompiler.dir/build.make:231: /src/sparrow-0.11.35~20180425/build/bin/SparrowCompiler] Error 1
make[1]: *** [CMakeFiles/Makefile2:341: src/SparrowCompiler/CMakeFiles/SparrowCompiler.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

I've noticed that 'Grammar/parserIf.ll' is being used to link libSparrowFrontend.a, which I presume is prebuilt. I wonder if it is possible to build parserIf.ll with '-fPIC' option so that I can build sparrow. I've tried adding '-fPIC' to CXXFLAGS and CMAKE_CXX_FLAGS build environments but it doesn't work at all.

Example:
using null(t: Type) = reinterpretCast(@t, untypedPtrNull)

They can be expanded as:

package _null(t: Type)
    using value = reinterpretCast(@t, untypedPtrNull)

// null(t) is expanded into by _null(t).value

Make sure that the current conan recipe works on Win64. AppVeyor integration should work.

We need to implement some kind of "interfaces" to be able to decouple different part of the application.

An interface, similar to a Java interface, is a collection of function pointers. We can have an unknown implementor of these functions; the callers will just use the interface directly, without knowing who implements them

This needs to work nicely with concept. Each time we declare an interface, we should also generate an implicit concept for the interface. This way, we may use the interface in static contexts, where the implementor is known at compile-time, thus contributing to faster code.

Overload selection doesn't work properly. If there are several overloads that can be selected, all with the same priority, then the compiler should generate an error.

Currently the algorithm "guesses" the most specialised overload by applying a wrong algorithm. Instead of checking if an overload is more specialized than the rest of the overloads, the algorithm currently checks only if the overloads after the current overload are less specialized.

More specifically, in Overload.cpp -> selectMostSpecialized(), the j variable should iterate over all the possible values (except i). Making this simple change yields a lot of errors in multiple tests.

TravisCI builds don't work anymore as conan is dead. Find other ways to accelerate linux builds on TravisCI

Mac builds take a long time. Evaluate whether it makes sense to have TravisCI builds for Mac. If it doesn't, remove them.

We want to track run-time and compile-time performance of Sparrow. How fast certain programs written in Sparrow run, and how fast the compilation of Sparrow program is.

Make sure we can pass an option to compiler to dump the most relevant compilation-time indicators.

Our LLVM version 3.5.2 is too old. Compatibility issues between the two

This is one of the long standing missing features of Sparrow. Make sure its implemented.

Update LLVM to version 3.6
Update Boost to 1.66
Update CMake to 3.6.0

This is needed as brew dropped support for older LLVMs. If we upgrade LLVM, then we can upgrade the others as well.

Not needed anymore if the constructors are external

Hello, Lucian!
I've tried to build sparrow on both linux (Windows linux subsytem, ubuntu) and Windows 10. On linux the build had completed successfully, but when I ran the compiler with simple program from the tests folder, I had got a segmentation fault.
Since I lack skills of using gdb, I decided to try to build sparrow compiler on windows. I've encountered some difficulties while generating Visual Studio project using cmake (llvm location, and boost libs - cmake wasn't able to find correct boost static libraries) and compiling solution in Visual Studio (needed to tweak settings regarding precompiled header StdInc.pch and to change compilation mode from "C" to "C++" in all the files that have ".c" extension). After that tweaks I finally got the binary for Sparrow compiler (there were installation error because of incorrect INSTALL_PREFIX somewhere in cmake configs).
I copied SparrowImplicitLib folder into the directory with SparrowCompiler.exe and tried to compile Power.spr from the tests/Examples folder. And in that case I had crash too. I rebuilt the compiler again with "Release with debug symbols" configuration and tried to debug. It appears that error hides somewhere in spr_parserIf_createParser function. I've attached two screenshots from my debug session in hope that You would suggest me, where to dig further.
Your project looks really interesting to me and I hope You would help me to resolve that crash so I could work through the example programs supplied in repository.

Good luck and best wishes,
Alex

Example: MyRange/ct -> #Range, where MyRange is ct-only
This conversion doesn't work (MyRange cannot be used at RT). Check why do we try to convert to RT concept, check what can we do about this

Make sure that Conan can build Flex & Bison for Win64 platforms.

The build should be able to find the install flex and bison. This is Debian Sid.

|> cmake -DCMAKE_INSTALL_PREFIX=$HOME/Built -DLLVM_DIR=/usr/lib/llvm-3.9 ..
-- Boost version: 1.61.0
-- Found the following Boost libraries:
-- filesystem
-- system
-- program_options
-- timer
-- Boost include: /usr/include
-- LLVM include: /usr/lib/llvm-3.9/include
-- LLVM libs: /usr/lib/llvm-3.9/lib
-- LLVM binaries: /usr/lib/llvm-3.9/bin
-- Could NOT find FLEX (missing: FLEX_EXECUTABLE)
-- Could NOT find BISON (missing: BISON_EXECUTABLE)
CMake Error at src/SparrowFrontend/CMakeLists.txt:5 (BISON_TARGET):
Unknown CMake command "BISON_TARGET".

-- Configuring incomplete, errors occurred!
See also "/home/Checkouts/Git/Sparrow/Build_Debian/CMakeFiles/CMakeOutput.log".

|> which flex
/usr/bin/flex

|> which bison
/usr/bin/bison

Make sure that Sparrow is able to be compiled on Win64 platforms. Also make sure that AppVeyor can do Win64 builds of Sparrow.

Conan doesn't work anymore. Remove it from the build chain. Make sure the build works locally without Conan. Don't bother with TravisCI yet.

Define a way in which we can make automatic releases for Sparrow.

Rough idea:

• each merge to master should trigger a new release build for Sparrow
• builds should be done on all the platforms supported by TravisCI and AppVeyor
• resulting builds should be pushed to GitHub Releases.
• release numbers should be computed from the major/minor versions defined in CMakeLists.txt plus an autogenerated patch-level number
  -- if autogenerating patch-level number is not possible, this action needs to be done manually.

Parsing a Sparrow file without an empty line at the end of the file will the following error:
bug.spr(10:13-13) : ERROR : Syntax error, unexpected end-of-file, expecting ';' (or newline)

Make sure assert works properly.

• make sure that implicit lib contains basic meta abstractions:
  • AstNode (or a simplified version of it)
  • astEval
  • lift
• fix the existing assert -- make sure it can be used in the tests
• fix precedenceUtils -- similar problem to the asserts
• make it possible to have a direct mapping from Sparrow functions directly to Sparrow Ast nodes
  • e.g., ife can be directly mapped with ConditionalExp
• compiler defines as usings
  • add standard defines into the compilation (e.g., compiler, OS, etc.)
  • allow user to provide his own defines; e.g.:
    • -DDEBUG produces using DEBUG=1;
    • -DVERSION=2 produces using VERSION=2;
    • -D'MYMACRO=compute(2)' produces using MYMACRO=compute(2);
  • needed to properly turn on asserts
• add more assert-like functionality
  • enable assert to take an optional message as argument
  • add assertEq, assertNe, ...
• add optional message to assert

For larger projects, we may have multiple sparrow source files that we would like to compile individually.

Main ideas:

• non-generic functions are only compiled (e.g., code generation) for the translation unit in which they appear
• each function (and class) should have an unique name, so that we can properly find the symbols at link time
• the same generic can be generated into multiple files, but at link time, they should all collapse to only one

Make sure this works at least with the Sparrow parser code.

fun sprMain
var a: Bool
a = true
while a
break

INTERNAL ERROR : LLVM Verification failed for generated program: Branch condition is not 'i1' type!
br i1* %a, label %while_body, label %while_end
%a = alloca i1

Currently we properly support call-stacks and function locations. We also need to support variables, so that we can debug Sparrow programs

Make sure that Sparrow compiles on TravisCI, for Linux and MacOS.

We want to rewrite the parser & lexer used in the Sparrow compiler, writing it in Sparrow itself. This would be the first part of the compiler that is written in Sparrow.

By doing this, we want to get rid of the flex & bison dependencies, making easier the transition to Windows.

The general idea is the following:

• lexer & parser is written in Sparrow
• the node creation functionality is declared as externals in Sparrow
• the code is compiled as an external library
• we compile the code as .llvm assembly -- this gets committed to GIT (at least from time to time)
• the compiler makefile (CMake) will be adapted to compile this and link it to our executable

Tasks to be done:

• write the lexer in Sparrow
• add the flow to use the lexer inside the Sparrow compiler (changing the compilation flow)
• write the parser in Sparrow
• complete the flow
• remove flex & bison from the dependencies

To speed up compilation, and to ensure TravisCI won't time-out while building LLVM as part of Sparrow compilation, we need to make LLVM packages available on the conan.io, at least for the common platforms used by TravisCI

See following cases:
- Benchmark game - nbody / n bodies run KNOWN-PROBLEM
- Benchmark game - nbody / n bodies run KNOWN-PROBLEM
- Benchmark game - nbody / n bodies run KNOWN-PROBLEM

Every time we have a type mismatch, we attempt to check for custom conversions. That can be very expensive. We should optimize this flow.

One way is to add a property to the nodes that support conversion ctors. This can easily be checked, and it's much faster than starting the overload procedure for conversion ctors.

This property can be set automatically (whenever we find a conversion ctor) or manually (i.e., [convert] modifier.

Make sure that builds do not break existing tests. If the complete suite of tests don't run, mark the build as erroneous.

• use min.h to parse
• print the result as a Sparrow decl
• make sure the generated code (by above print) is compilable

Currently the Sparrow syntax has some C++ syntax elements (curly brackets, parenthesis, semicolons, etc.) while it choses a new syntax for declarations (fun, class, var) and for expressions. In the current syntax, a lot of characters are redundant: semicolon at the end of line, curly brackets, parenthesis for statements, etc. We would like to simplify the Sparrow syntax; this will move Sparrow more closer to Python syntax.

Some rules:

• don't require semicolon at the end of line
• don't require parenthesis for statements (if, while, for)
• don't require curly brackets for scopes
• a newline terminates a statement
• if a backslash ends a line, the statement is continued on the next line
• for ifs and whiles, support colon at the end of expression, but that's optional

Make sure we can define things like 'RetType' for ranges as external entities.

Something like:
fun RetType(t: Vector) = Int // yes, the arg is RT, but we don't care

Create a static site (with Jekyll) that is able to display performance data read from a set of .yaml files. After running the functional tests, the Linux version of TravisCI will also run performance data, and publish results to this static site.

Of course, this site will be hosted on GitHub.

Please see the following tests:
- Logic: parents example, with recursive calls / All males KNOWN-PROBLEM
- Logic: parents example, with recursive calls / All females KNOWN-PROBLEM
- Logic: parents example, with recursive calls / All fathers KNOWN-PROBLEM
- Logic: parents example, with recursive calls / All mothers KNOWN-PROBLEM
- Logic: solar system example / All planets KNOWN-PROBLEM
- Logic: solar system example / All satellites KNOWN-PROBLEM
- Logic: parsing Prolog code / Injecting Prolog - solar system KNOWN-PROBLEM
- Logic: parsing Prolog code / Injecting Prolog - parents KNOWN-PROBLEM

Make sure that builds do not break existing tests. If the complete suite of tests don't run, mark the build as erroneous.