berkus / virgil Goto Github PK

Language or Compiler Enhancement?
===========================

Language

Justification (summary of perceived benefit)
===============================

The current design requires subclasses to re-declare constructor parameters 
that are simply passed along to super constructors. This tends to be redundant 
and increases the amount of work necessary to write subclasses.

E.g.

class A {
  new(i: int) { }
}

class B extends A {
  new(i: int, j: int) super(i) { }
}


B be written more easily:

class B extends A {
  new(j: int) super(_) { }
}

or even:

class A(i: int) { }
class B(j: int) extends A(_) { }
class C extends B(3, _) { }

Impact estimate (select one)
----------------------
2 - small
================

Priority (select one)
----------------------
2 - medium
================

Syntactically, ";" for an empty constructor body is allowed, it just results in 
a !UnimplementedException in at runtime when invoking the constructor--not very 
useful. Allow ";" for an empty constructor body, or make it a compile-time 
error.

What steps will reproduce the problem?
1. Write a program that throws an exception.
2. Run the program.

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

Expected output should be an exception stacktrace. Instead, program gets stuck, 
probably in the signal handler.

Language or Compiler Enhancement?
===========================

Language

Justification (summary of perceived benefit)
===============================

Virgil currently only supports foreach loops over arrays. Devise a mechanism to 
allow cons Lists, Sequences, Maps, and other user types to be foreach-iterable. 
This must be done as efficiently as possible, without implicitly allocating 
objects on the heap.


Impact estimate (select one)
----------------------
2 - small
================

Priority (select one)
----------------------
3 - high
================

Since these safety violations result in a termination of the program, it's not 
really accurate to call them exceptions. Violation = Termination!

What steps will reproduce the problem?
1. Try to parse Aeneas.jar with IKVM (http://ikvm.net/)
2. Look at the warnings
3. See the conversation at https://sourceforge.net/p/ikvm/bugs/281/

What is the expected output? What do you see instead?
IKVM is pretty good at converting pretty much every JAR i've stumbled upon. So, 
while I personally didnt check the JAR for correctness as per JRE spec, my bet 
is that the generated bytecode is wrong.

What version of the product are you using? On what operating system?
Virgil binary from latest commit, IKVM 7.2 binary, Windows 8.1 x64, .NET 4

Please provide any additional information below.

Language or Compiler Enhancement?
===========================

Language and Compiler

Justification (summary of perceived benefit)
===============================

Large (64-bit) integers are necessary to represent large quantities, like 
offsets in large files, etc.

Impact estimate (select one)
----------------------
2 - small
================

Priority (select one)
----------------------
2 - medium
================

System.error should generate a stacktrace on native platforms.

Currently it does not because it requires a compiler intrinsic to get the 
caller IP and SP to begin stack walking.

Add an option to allow renaming the binaries output from the compiler.

% v3c -program-name=Blah.exe Foo.v3

Will output into a binary Blah.exe instead of Foo

Impact estimate (select one)
----------------------
1 - trivial
================

Priority (select one)
----------------------
3 - high
================

What steps will reproduce the problem?
1. Download virgil
2. Try to invoke aeneas.jar
3. There is no output or something

What is the expected output? What do you see instead?
Since virgil is bootstrapped and able to target JVM I expected it to work on 
windows out-of-the-box.
But it depends on the shell script which is Unix-specific.

What version of the product are you using? On what operating system?
Tried virgil-starter and latest source checkout (fe2ba7c2d39d), on Windows 8.1 
x64.

Please provide any additional information below.
Using Cygwin is not an option, it's very bloated and slow. I'll try to hack an 
equivalent to virgil shell though.

Language or Compiler Enhancement?
===========================

Language and Compiler

Justification (summary of perceived benefit)
===============================

Support for 32 and 64 bit floating point numbers is necessary to perform all 
manner of scientific and graphics calculations.

Impact estimate (select one)
----------------------
3 - large
================

Priority (select one)
----------------------
2 - medium
================

When running on the JVM, a stack overflow manifests itself with a 
java.lang.StackOverflowError, which terminates the Virgil program. On native 
platforms, a stack overflow manifests itself by the program running past the 
end of the stack's mapped pages, causing a SIGSEGV (or SIGBUS), which cannot be 
handled by the runtime's signal handler (since there is no stack), resulting in 
termination of the program by the operating system.

Native platforms should check for stack overflow via one of the known 
mechanisms:

1. Use sigaltstack for signals
2. Stack banging
3. Explicit stack checks

Call graph analysis can likely eliminate most of #2 and #3 statically.