praveenvvstgy / crack-language Goto Github PK

What steps will reproduce the problem?

class Foo {
    Foo open() {
        return Foo(false);
    }
    oper init(bool openit) {
        if (openit) open();
    }
}


What is the expected output? What do you see instead?

No method exists matching Foo with these argument types.

---
This happens because oper init has not yet been defined. However, if we switch 
the order, init will fail for a similar reason.

This is a real bug from Directory class, where init took an argument that 
determined whether the directory should be opened and read on creation or not.

Add C-style binary operators.

What steps will reproduce the problem?
1. run "class A : int {}"

What is the expected output?
  nothing

What do you see instead?
  lt-crack: /home/mmuller/pkg/llvm-2.7/include/llvm/Support/Casting.h:200: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X = llvm::PointerType, Y = const llvm::Type*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.


Please use labels and text to provide additional information.

(feature request)
E.g. running the hello.crk example, the compiler reports:
ParseError: hello.crk:4: No method exists matching puts with these argument 
types.

It would be great if the error message mentioned what the argument types were.
Secondly, the compiler should report the available interfaces, e.g.:
Found:
crack.lang.puts(String)
crack.lang.puts(bytearray)

It would also be useful to know the line number of the file where the function 
definition was found if possible.

As it stands, field (or instance variable) access gets special treatment from 
the compiler: when we see a field access or assignment of the form "x.a" or 
"x.a = b" a model object expression gets generate for the reference or the 
assignment.

These should instead be represented as a FuncCall object derived from the 
function "oper get <fieldname>" and "oper set <fieldname>".  Switching to this 
form will allow us to overload field accesses and also allow us to better 
accommodate extensions (see Issue 49) by generating offsetting code to access 
fields in native structures.

There should be no runtime cost associated with this for normal fields: in the 
case of instance variables, these functions can be defined to do the same field 
access code generation that they do now.

Get an initial version of the new template-based test suite (written in crack) 
running. This will require:

 * simple process management
 * regex
 * more string operations
 * porting current tests to the template system

Add the C-style ternary operator.  As in C++, this should verify that both 
operands can be converted to a common type.

We should support a Java-like for statement:

  for (int i = 0; i < 100; ++i) ;
  for (i :in range(1, 100)) ;
  Iterator j;
  Collection c = getCollection();
  for (j in c) ;

What steps will reproduce the problem?
  import crack.io cout;
  x := 12345678902134;
  cout `$x\n`;


What is the expected output? 12345678902134 
What do you see instead? 1942893430


Please use labels and text to provide additional information.

At present, if you have a module "a" that imports a symbol "b", another module 
can import "b" from module "a".  This is dangerous.  We should disallow these 
kinds of second-order imports unless the imported symbol is explicitly exported 
by the intermediate module.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

The extension library now allows you to compose crack classes and map them to 
an underlying structure in C or C++.  Unfortunately, this doesn't work very 
well because the alignments used by the crack compiler and the C/C++ compiler 
can vary.

We need a way to be able to fix alignment from both sides: on the crack side, 
the extension library's addInstVar() method should be modified to provide an 
offset and field accessors need to be able to accomodate operators so we can 
generate field accesss instructions as references to these offsets.

On the C/C++ side, we need to be able to generate headers with the appropriate 
padding that are platform/compiler/options specific - so an extension structure 
can inherit from crack::ext::Object with the intended consequences. 

What steps will reproduce the problem?
1. Compile crack and spug with GCC 4.4.2

What is the expected output? What do you see instead?
Successful compilation

What version of the product are you using? On what operating system?
Trunk on ArchLinux x86_64

I've written patches to make it compile correctly.

focusing on the root builder maintaining a list of modules and keeping llvm 
specific functionality there.

Hex and octal notation should be supported for constants:

i := 0xffffffff;
o := 0777;

What steps will reproduce the problem?
1. Run the script below.  You'll get a seg-fault when you run out of stack.

int64 sum(int64 a, int64 b, int64 c, int64 d, int64 e, int64 f, int64 g, 
         int64 h, int64 i, int64 j, int64 k) {
    return a + b + c + d + e + f + g + h + i + j + k;
}

void func() {
    while (1 == 1) {
        int64 a = 1, b = 2, c = 3, d = 4, e = 5, f = 6, g = 7, h = 8, i = 9, 
            j = 10, k = 11;
        a = sum(a, b, c, d, e, f, g, h, i, j, k);
        printint(int(a));
    }
}

func();

It should be possible to write crack modules in C or C++.  Such modules should 
be of the form of shared libraries in the module trees.  For example, on a 
linux system, the file foo/bar/baz.so would be loaded as a result of "import 
foo.bar.baz;".

The interface should be similar to that used for python: there should be a 
module init function (preferably the mangled form of foo.bar.baz:init to match 
the general module init routine). This function should accept some wrapper 
around a Context object as input and should be able to register low-level C/C++ 
functions as crack functions and methods.  It should also be able to create 
classes and global variables.

What steps will reproduce the problem?
1. run "void foo(int a) { a = 100; }"

What is the expected output? What do you see instead?

Expect no output, we get an assertion error.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. run this:
  void outer() { int a; int inner() { return a; } }


What is the expected output?

  Should get a parser error: referencing outer function scopes is not allowed yet. 

What do you see instead?

  LLVM errors during optimization.



Please use labels and text to provide additional information.

a ticket to track proposed enum support. 

syntax:

enum myEnum { a = 0, b, c, d };

class MyClass {

  enum myClassEnum { foo, bar, baz };

  ...

}

<mmuller> [13:48:50] yeah, I prefer having it stored as a plain old integer.  
The thing is, the "convert to a string" case is compelling.
<mmuller> [13:49:22] maybe conversion is the way to go, here.
<mmuller> [13:49:55] if not from an object to an integer (which will make the 
enums too heavyweight), maybe from an integer to an object.
<mmuller> [13:50:51] so for example, have "formatted(EnumString)" and specific 
"oper to EnumString" operators created for each of the enum types
<mmuller> [13:50:59] sorry, "format(EnumString)"
<mmuller> [13:54:47] you know, I think this is actually a sort of "auto-boxing" 
(like what new versions of java do)
<mmuller> [13:55:48] an eventual goal is for crack to do autoboxing through the 
conversion mechanism, I think this is just a new case of it.
<mmuller> [13:56:52] and maybe "EnumWrapper" instead of "EnumString" so we can 
potentially extend into other domains.
<mmuller> [14:06:22] so one snag in this is that for every primitive enum type, 
there should be a corresponding high level type
<mmuller> [14:07:02] adding methods and instance variables within the enum 
definition should extend that high level type
<mmuller> [14:09:04] but if you want to use the standard "writeTo()" method to 
format them, you'll need to define new high level types as well as the 
low-level ones

Annotations needs a design doc.  The basic idea is to allow extending the 
compiler in the language.  This is a small example:

# module myann

import crack.ann Context;

class PrimWrapper {
    void process(Context ctx) {
        wrapper := ctx.toker.getToken().getValue();
        wrapped := ctx.toker.getToken().getValue();
        ctx.toker `class $wrapper {
                        $wrapped val;
                        oper init($wrapped val0) : val = val0 {}
                        $wrapper oper +($wrapper other) {
                            return $wrapper(val + other.val);
                        }
                    }`;
    }
}

primWrapper := PrimWrapper();

# main script

import myann primWrapper;

# create an integer wrapper class
@primWrapper Int int

This issue is currently obscured by issue 20.

What steps will reproduce the problem?
  import crack.io cout;
  int64 i = -1234567890123;
  cout `$i\n`;

What is the expected output? -1234567890123
What do you see instead? -1912276171

Crack originally took the C++ approach on default initializers:

  A a;

In the definition above, "a" is initialized with the default constructor, 
making it equivalent to:

  A a = {};

As it turns out, in most of the cases in the current code where we do default 
initialization of objects, we want to initialize to null.  We should accomodate 
the most common case and use null as an initializer.

Something like this:

class BTreeMap[Key, Val] : Map[Key, Val] {

  Val get(Key key) { ... }

  Val oper []=(Key key, Val val){ ... }

};

m := BTreeMap[String, Int]();
m['test'] = 100; # assuming we get auto-boxing

We need a form of virtual inheritence:

class Writer : *Object, VTableBase {
  uint write(String data) { die('not implemented'); }
}

Use of the "*Object" notation indidates that Writer has Object as a virtual 
base class.  This effectively renders Writer abstract - it can not be directly 
instantiated, you have to derive from it by a class that is also 
(non-virtually) derived from Object.

Given a Writer object, we can:
- upcast to object (a special function will be added to the vtable to be 
implemented by the derived class which will do the upcast given its concrete 
inheritence on Object)
- call any Object methods and access any Object attributes (by implicitly 
upcasting)

If you try do do something like this:

class A {
  oper init() {}
  A clone() { return A(); }
}

it won't work because A::oper new doesn't get generated until the end of the 
class body.

We need to generate 'oper new' immediately after 'oper init' is parsed (as long 
as the user hasn't already defined their own 'oper new')

":=" currently only functions in a definition context.  Make it usable in 
expression context so we can do things like this:

  foo(x := bar());
  while (l := src.readLine()) ;

What steps will reproduce the problem?
1. Run "class A { void f() { StaticString(this.class.name); } }"

What is the expected output?
  nothing

What do you see instead?
  lt-crack: builder/LLVMBuilder.cc:549: void<unnamed>::BBuilderContextData::addPlaceholder(<unnamed>::PlaceholderInstruction*): Assertion `!complete && "Adding placeholder to a completed class"' failed.


Please use labels and text to provide additional information.

At this time, if you want to typecast an object to a derived class when the 
object may legitimately not be an instance of the derived class, you have to do 
this:

  if (obj.class.isSubclass(DerivedClass))
      derObj = DerivedClass.unsafeCast(obj);

The unsafeCast() avoids doing the check a second time in the cast() function.

In the interests of simplicity and of allowing users to avoid unsafe calls, we 
need to introduce a flavor of cast() that does not abort (or throw an 
exception, in the long term).

Current possibilities for this include:

  Derived cast(Object object, Derived defaultValue);
  # code above becomes
  newObj = DerivedClass.cast(obj, null);

and:

  Derived tryCast(Object object);
  # code above becomes
  newObj = DerivedClass.tryCast(obj);

Currently leaning towards the first form because it reduces the number of names 
in the interface and allows us to use default values other than null (although 
I currently can't think of a use-case for that).

Alternately, we could break compatibility and require a second boolean argument 
indicating whether to abort/throw or return null.

What steps will reproduce the problem?
  import crack.io cout;
  float f = 1.0;
  cout `float is $f\n`;


What is the expected output? 1.0
What do you see instead? true


Please use labels and text to provide additional information.

What steps will reproduce the problem?
   import crack.io cout;
   void a(uint64 v) {
       while (v) {
           cout `$v `;
           v >>= 1;
       }
   }

   a(4);

What is the expected output? 4 2 1 What do you see instead? 4 4 4 4 ...


Promotion of arguments from registers to allocas is happening in the context 
where the argument is assigned: if that context is a loop we'll continually 
alloca.  The promotion needs to happen in the function's first block.

Please use labels and text to provide additional information.

import crack.io cout;

class A {
    A other = null;
    String name;
    oper init(A other0, String name0) : other = other0, name = name0 {} 
    oper del() { cout `deleting $name\n`; }
}

A a = A(null, 'first');
a = A(a, 'second');
cout `done\n`;

Should print "done", "first" and "second".  Instead, "first" gets cleaned up 
during the assignment.

Cleanups for assignments need to happen after the value is bound. 

(feature request)
It would be nice to have a shorthand for some default implementations of 
commonly used types, String, Array and Map.

This can be implemented in a separate module so as to not weigh the runtime 
down if not needed.

Maybe this can be done with operators, like
oper ""(ConstantString)
oper [](ConstantArray)
oper {}(ConstantRBMap)

Implement C-like forward declarations:

int a();
int b() { return a(); }
int a() { return 1; }

if imported items aren't used in a script, we should throw a warning

The COPYING file contains the GPL, but the web site mentions the LGPL as the 
project language.

This should probably be clarified.

What steps will reproduce the problem?

import crack.io cout;

class BaseOne {

  void baseOne() { cout `BaseOne.baseOne\n`; }

}

class BaseTwo {

  void baseTwo() { }

}

class Multer : BaseOne, BaseTwo {


}

b := BaseOne();
b.baseOne();BaseOne.baseOne
BaseOne.baseOne


m := Multer();
m.baseOne();

What is the expected output? What do you see instead?
expect:
BaseOne.baseOne
BaseOne.baseOne
instead:
BaseOne.baseOne
Segmentation fault

If the second base class for Multer is commented out, so that it only inherits 
from BaseOne, it runs as expected.

Currently only uints are allowed.

What steps will reproduce the problem?

int i=0; i=i+1;

gives:
token 1 was not expected at this time, expected semicolon or a block terminator

needs to parse as + operator, but is (probably) parsing as a literal. a space 
makes it work:

int i=0; i=i+ 1;

class A {
  oper init(int val) {}
}

class B : A {}  # should get its own oper init(int val)

We can only do this if all of the rest of the instance variables and base 
classes have default constructors.

What steps will reproduce the problem?

class A { }
class B {
    A a;
    oper init(): a=5 { }
}

Output:
Bad IR is generated which fails LLVM moduleverification.

Notes:
There seems to be no type checking in the initializer lists.

Introduce support for versioned libraries and crack binary in CMake.

http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION

class BadError : Exception {}

try {
  throw BadError();
} catch (BadError ex) {
  cerr `got a bad error: $ex\n`;
}

interpolates strings currently translate like this:
   cout `a$(b)c`; --> if (cout) { cout.format('a'); cout.format(b); cout.format('c') }

Make them more like this:

cout ? (cout.enter(); cout.format('a'); cout.format(b); cout.format('c');
        cout.leave()) : 0;

So in other words, provide enter() and leave() hooks, if the leave() hook 
returns non-void let it be used as the value of the expression.

What steps will reproduce the problem?

import cout;
cout `test\
text`;

Should produce "testtext", not "test\ntext"

Right now, crack depends on spug++ by virtue of its use of 4 spug++ header 
files.  Remove this dependency by moving the files into the crack source tree.

What steps will reproduce the problem?
echo "float32 f; if (f);" | crack -                                             


What is the expected output? nothing
What do you see instead?
crack: /home/mmuller/pkg/llvm-2.7/include/llvm/Instructions.h:635: 
llvm::ICmpInst::ICmpInst(llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, 
const llvm::Twine&): Assertion `(getOperand(0)->getType()->isIntOrIntVectorTy() 
|| getOperand(0)->getType()->isPointerTy()) && "Invalid operand types for ICmp 
instruction"' failed.

int and uint are currently aliases for either their 32 bit or 64 bit 
counterparts.  This causes problems because, for example, the code:

  int i = int64(n);

... will compile successfully on a 64 bit platform but fail on a 32 bit 
platform.  int and uint should therefore be separate types where:

1) both are at least 32 bits.
2) both will allow implicit conversion to their 64 bit counterparts but not to 
32 bit.
3) both will allow implicit conversion from their 32 bit counterparts but not 
from 64 bit

Make the CMake and autoconf builds driven from common file lists.

Adding this to try out the new group.