Double imports for FuTIL backend

[cgyurgyik]

Because of this:

dahlia/src/main/scala/backends/futil/FutilBackend.scala

Lines 867 to 869 in e271249

	val imports =
	Import("primitives/std.lib") ::
	p.includes.flatMap(_.backends.get(C.Futil)).map(i => Import(i)).toList

We're seeing:

dahlia/file-tests/should-futil/invoke.fuse

Lines 1 to 10 in e271249

	import futil("primitives/std.lib") { def std_sqrt(in: ubit<32>): ubit<32>; }
	def foo(a: ubit<32>): ubit<32> = {
	let temp: ubit<32> = a;
	return temp;
	}
	let b: ubit<32> = (1 as ubit<32>);
	let c: ubit<32> = foo(b);
	let d: ubit<32> = std_sqrt(c);

which results in:

dahlia/file-tests/should-futil/invoke.expect

Lines 1 to 3 in e271249

	import "primitives/std.lib";
	import "primitives/std.lib";
	component foo(a: 32) -> (out: 32) {

[cgyurgyik]

I think the best way to fix this is to not have a default import. This will require tediously refactoring all current Dahlia files. I'll wait for second opinions before following through.

[rachitnigam]

Sqrt isn’t available in std.lib, I moved it to a different folder. Dahlia programs shouldn’t be importing that file.

[cgyurgyik]

Ok so that's wrong. But in general, will it ever be the case where this results in a double import, or is it always incorrect to do so?

[rachitnigam]

My guess would be no. std.lib should really only implement things that Dahlia always needs in order to work properly. For example, it exports all the primitives for fixed point numbers. OTOH, things like sqrt should really exist as only their own in a different Calyx library.

[cgyurgyik]

Makes sense. Fixed in #349.