pchapin/scala

Scalaness: A stagged programming system for embedded systems based on Scala.

scala's Issues

How should nesT build dependencies be handled?

Typical Scala build tools do not know about nesT. Yet when one edits a nesT file, the Scala class/object that represents it should be recompiled. This allows the (possibly changed) module type of the nesT component to be checked against the annotations in the Scalaness program.

More generally when a header file that is included into a nesT file is changed the Scala class/object that represents that nesT component should be recompiled (for example a change in a structure type declared in the header might cause the module type of the nesT component to change). Tracking dependencies across languages in this way would be a challenge for some build environments. What's the best way of handling this problem for Scalaness/nesT?

Fix the samples

Some of the samples don't work (and maybe never worked). They should be fixed so they do work.

NesT should support enumerations

Enumerations are commonly used in nesC programs to introduced named constants. Currently nesT doesn't handle enumeration declarations 100% correctly. This is particular awkward when trying to share declarations between nesT and nesC, for example, in a header file that also introduces some shared structure types.

Objects and classes representing nesT modules must extend NesTComponent

Right now any class or module with a primary constructor ending with a string literal is treated as a wrapper around a nesT inclusion. However, the intention is for all such classes or modules to also extend the trait NesTComponent. This trait contains essential runtime support for manipulating nesT modules; its presence should be verified. In particularly only classes (or modules) that extend NesTComponent should be searched for nesT inclusions and, furthermore, it should be a compile time error if no inclusion is found in such a class or module.

NesT argument type mismatch errors are incorrectly indicated

If there is a mismatch between an argument type and a parameter type when a nesT function/command is called, the error report points at the first argument in the argument list regardless of which argument is in error. This is misleading.

This arises because the TypeException thrown to indicate the error is using the position of the current node in the AST as the location of the error. However, the current node in this case is the ARGUMENT_LIST node and so the error is reported for the list as a single unit (pointing at the first argument in the list).

Should nesT support nx types?

Currently nesT does not support nx types such as nx_int16_t, etc. It also does not support nx_struct. Full nesC uses these types extensively. The lack of support in nesT inhibits sharing of certain declarations between languages, which is awkward in some cases.

Undesirable build order dependences

Suppose a class/object representing a Mininess component is in a separate file from where it is used. The compiler needs to know the nesT module type of that component in order to check the usage. Currently it is necessary for the file containing the component and the file containing the usage to be compiled in the same session and in the right order (the component must be compiled first). This is more restrictive than normal Scala rules and requires unnatural renaming of files to work properly with certain build systems, such as ant.

The behavior may have something to do with the Scala compiler's two pass type checking algorithm. Current nesT module types are handled during the first pass but perhaps that is too early. It may be necessary to do nesT module type processing during the second pass when, perhaps, more complete information about the program is available.

Should external structures and external types be supported in nesT?

The nx_struct structures and related types are currently outside the nesT subset. It might be useful to include them. Doing so would involve changing the nesT type checker and maybe also the declaration and symbol table handling of nesT code. Allowing such types in imports and exports would also require adjustments to the ModuleType annotation syntax and associated processing. Thus this change has a significant ripple effect and shouldn't be undertaken too lightly.

NesT return statements should be type checked against the declared return type

Currently return statements are type checked as Some(Okay) provided the expression being returned is Okay. However, the type checker should verify that the type being returned actually agrees with the declared type of the enclosing function/command/event.

Relative paths in the configuration file should be relative to the file's location

Currently relative paths in the Scalaness configuration file are relative to the working directory of the compiler. This is fine if the compiler is run from the same location as the configuration file (as might be typically done when running it manually). However, in the context of an IDE, for example, the compiler may be run from a directory far away from the project files. This causes the relative paths in the configuration file to be quite useless.

However, using absolute paths in the configuration file is not very version control friendly and is thus not recommended. The compiler should be modified so that relative paths in the configuration file are always taken to be relative to the configuration file's location.

The type of the literal -128 is incorrect

The specification of Mininess in the Scalaness User Documentation says that the negative sign when applied to an integer literal is part of the literal. That is '-128' is a single token and not the '-' token followed by the '128' token. This is important because otherwise -128 will have type int16_t rather than int8_t as it should. In particular '128' must have type int16_t since 128 is too large to represent with int8_t. With the '-' sign as part of the literal token the compiler can see that '-128' is a legal int8_t value and assign it an appropriate type.

NesT typer does not understand const

Currently the nesT typer does not understand const so writing "const correct" code is not possible in nesT. This particularly causes problems for declarations that are being shared between nesT and nesC. For example, consider the nesC module

module FullNesC {
    uses command void process_buffer( const char *buffer );
}

Suppose it is wired to the following nesT module

module BufferHandlerC {
    provides command void process_buffer( const char *buffer );
}

Because the nesT typer ignores const it will allow values to be assigned to the buffer passed to process_buffer. The invoking nesC code won't expect this. Moreover when the specialized nesT module is compiled by the nesC compiler, type errors will be reported at that time.

Syntax errors in ModuleType annotations should have their location reported

Currently if there is a syntax error in a ModuleType annotation the location of that error is not reported. This makes fixing such errors harder than it should be. It would be better if the location was reported as for other kinds of syntax errors.

Dealing with this will be a bit tricky. ANTLR reports the error location relative to the string it is parsing. That location will need to be converted into an offset in the enclosing source file before the Scala compiler's error reporter will be able to handle it.

Should typedef be supported in nesT?

Currently typedef declarations are not supported in nesT. Although the parser understands them, they are not being handled by the type analysis at the moment. Should they be?

Doing without typedef declarations in a limited language like nesT isn't a problem, but in situations were declarations need to be shared between nesT and nesC it can be awkward. Typical nesC programs make heavy use of typedef so requiring them to not do so for declarations shared with nesT is a bit of an imposition on the nesC programmer.

One potential workaround is to conditionally skip the typedef declaration when compiling a header as nesT (with the help of a suitable predefined macro in the Scalaness compiler). This is, however, a bit strange looking and awkward.

NesT typer does not verify consistency of initializers

Consider code such as

int x = f( ) + 1;

The nesT typer does type checking of the expression f( ) + 1 but it does not verify that the overall type of the expression is appropriate for the declared entity. For example the following passes type checking

int array[10] = 0;

Unknown configuration items should not cause the compiler to crash

Currently if the compiler discovers an unrecognized configuration setting in the Scalaness configuration file, it throws and unhandled exception and crashes. This is clearly inelegant.

Store ASTs of nesT components in the executable jar?

Currently the nesT templates are stored in the executable jar as raw source files. This requires the runtime system to reparse them during the execution of the Scalaness program. The main issue with that is it requires ANTLR to be available to the runtime system. Since the nesT templates must be parsed during compilation (for type checking) it might be nice to instead store them as serialized ASTs in the executable jar file. This would avoid reparsing the source at runtime and ANTLR would not needed.

Create a method to pretty print nesT types?

The representation of nesT types is currently abstract (a collection of case objects and case classes). This is fine for internal use but it is ugly to display. It would be nice to have a method that converts the abstract representation of a nesT type into something that looks more like the way types are written in nesT programs. For example we want something like

Array(Pointer(UInt8), 10)

to be displayed as

uint8_t *[10]

Fully correct handling of this conversion might be tricky due to the somewhat odd syntax of types used by C like languages. It should be relatively easy, however, to get an approximately correct version of the method. I expect this method will be useful in error and debug messages produced by the Scalaness compiler.

SnowStorm is missing a jar from its class path

The parser combinator library is now separate from the main Scala library. The build control files and run scripts for SnowStorm need to be changed to reflect this.