Joey Eremondi JoeyEremondi

After thinking about it, I think that Opt is probably the right place to do this.

(I suspect you thought of a lot of this, and that it just took me some time to wrap my head around what you were intending).

What we need to define is some sort of Accessor functions, which can be stored as Expression.Opt, or which are possibly stored in an Opt.Def. This would look something like this:

data Accessor =

AST.Expression.Canonical

We add the Facts type and field. freeVariables stores all variables which the given definitions right-hand-side references, which are not themselves defined somewhere in the RHS. Recursive values should note that they refer to themselves.

data Def
    = Definition Facts Pattern.CanonicalPattern Expr (Maybe (A.Located Type.Canonical))
    deriving (Show)

After looking at Canonicalize.Sort, here are my initial thoughts:

Canonicalize.Sort seems like the right place to make the reference-graph used by Dead-Code elimination
If we stored the reference-graph information in Canonical.Def, we could use that information in a lot of analyses later on (like variable assignment in TCO).
There's enough information in the current graph to do dead-code-elimination, but not enough to do unused-variable warnings that would also work for arguments and pattern matches.

I don't think the changes we would need to make would be that significant. Right now, we only look at what free variables a Definition references. If we also look at what bound variables it references (i.e. variables defined inside the reference by Lambdas or pattern matches), then we could issue the proper warnings.

This would, I think, just amount to storing a record with referenced free and bound variables,

elm-make

Pipeline.Compiler

We add the non-reversed dependencies to the environment. (We already have the dependencies. The original version stores only the reversed version, so our change stores both).

Original code

data Env = Env
 { maxActiveThreads :: Int

Proposal: revised Elm Native format

Right now, Native doesn't play well with dead-code elmination. Additionally, Native review is a big bottleneck for producing and publishing new librairies. Finally, there is no way to unclude JS code which calls ports using the Elm compiler.

Example file

/**
--The top of the file declares the structure of the Native module
--and must be a valid Elm syntax declaration

	#[cfg(test)]


	mod tests {
	use std::rc::Rc;
	// the `type` is not needed but it makes it easier if you will
	// be using it in other function declarations.
	type Adder = Fn(i32) -> i32;

	fn sum(x: Rc<i32>) -> Rc<Adder> {

	import Debug

	type Zero = Zero


	type OnePlus t = OneAnd


	type InternalFixedList a n = IFL (List a)

	{-
	Possible actions to take with conflicting names:

	1.
	Try to guess which one the user meant, by seeing if there's a name (or set of names) used
	only found in one.
	Give an error if this can't be determined.

	2.
	Add syntax for importing a package, something like

	--In general, we create a new type, Module.FullName, which pairs a Name with its user and project names
	--This means, in code that just passes through the module name, we just change the type signature to FullName
	--And it works, until we reach code that actually accesses the name

	--AST.Module:
	type Name = [String] -- must be non-empty

	type FullName = ((String, String), [String])

	--AST.Variable:

	--Canonicalize.hs

	declaration
	:: Env.Environment
	-> D.ValidDecl
	-> Result.ResultErr D.CanonicalDecl

	expression
	:: Env.Environment
	-> Valid.Expr