I agree with this.

Is it planned to be a requirement for modules to have a hare.ini file present? I like the current simplicity of implicit modules from directory structure.

Is anyone working on this? I will take a stab at it if not.

type delimiter = struct {
	text: []u8,
	next: *delimiter,
};

let OPENQUOTE_D = delimiter {
	text = ['`', '`'],
	next = &CLOSEQUOTE_D,
};

let CLOSEQUOTE_D = delimiter {
	text = ['\'', '\''],
	next = &OPENQUOTE_D,
};

export fn main() void = void;

// <...>/broken.ha:6:4: error: Circular dependency for 'OPENQUOTE_D'
// 
// 
// 6 |     let OPENQUOTE_D = delimiter {
//   |        ^
// 
// Error: harec: exited with status 1
// hare build: build failed

This can be avoided by a workaround but it requires using nullable pointers and @init:

type delimiter = struct {
	text: []u8,
	next: nullable *delimiter,
};

let OPENQUOTE_D = delimiter {
	text = ['`', '`'],
	next = null,
};

let CLOSEQUOTE_D = delimiter {
	text = ['\'', '\''],
	next = &OPENQUOTE_D,
};

@init fn init() void = {
	OPENQUOTE_D.next = &CLOSEQUOTE_D;
};

export fn main() void = void;

// This compiles.

Preceding IRC discussion:

 1:33pm <smlavine> I'm having trouble declaring a compile time circular linked list because of a "Circular dependency" error. I have a workaround but it requires using @init and nullable
                   pointers. Any suggestions? https://paste.sr.ht/~smlavine/c765fe0d683ae04e0549ac34db896c21748a94fb
 1:35pm <ecs> yeah i don't think there's really a good way for us to do something better
 1:35pm <ecs> i guess technically we could try to separate finding the result type of an expression from typechecking it?
 2:33pm <sebonirc> fwiw my "proposal" thing about generalizing `init` for global initializers would allow your workaround to work without nullable pointers, that being said it's still a hack
                   which it might be good to fix?
 2:33pm <sebonirc> probably worth filing a ticket either way
 2:34pm <sebonirc> smlavine: ^
 2:34pm <ecs> we'd need to do something similar to the type store dimensions vs representation distinction
 2:34pm <ecs> and i'm not really sure it's worth it
 2:34pm <sebonirc> yeah i'm not sure either tbh, but i still think there should be a ticket for it so then we at least have to make a decision on it
 2:35pm <ecs> fair
 2:39pm <smlavine> Will file a ticket

(acknowledging this is a very old issue)

I think that : void to ignore errors makes for readable code, since it usually replaces !, ?, or as, all syntactically found at the end of the function call, same as : void. Given these I think it makes sense to keep it.

For example, the summary page of one of my repos:

and the tree page:

The templates for tree, log, refs, and settings should be updated.

...but for now, we'll just use the ascii module to convert to/from upper/lowercase.

I don't think there is any proper external Unicode library that can do this in Hare yet, so the way we will probably want to do this is produce a hash map from these tables:

https://www.ibm.com/docs/en/i/7.2?topic=tables-unicode-lowercase-uppercase-conversion-mapping-table

https://www.ibm.com/docs/en/i/7.1?topic=tables-unicode-uppercase-lowercase-conversion-mapping-table

Since we know all of the values in advance, we could do the hashing and "putting" in advance, and hard-code an array.

As shown by

$ hare version -v
Hare dev+f86f8229-arch

Build tags      +x86_64+linux
HAREPATH        /usr/src/hare/stdlib
                /usr/src/hare/third-party
                /usr/src/hare/stdlib
                /usr/src/hare/third-party

On Arch Linux, built from version r2658.f86f8229-1 of the AUR package.

brocc in #hare said today that this code works on commit fcb4b5f. I tested this and it is true. One git-bisect later, I've identifed the bad commit as 8fcadc2. This helps to narrow down the scope of the problem a bit.

I believe I've narrowed done the problem to this case in emit_type(): https://git.sr.ht/~sircmpwn/harec/tree/master/item/src/typedef.c#L301

With some print debugging I have determined that type->alias.exported is not set for foo. Therefore emit_type() returns false when called below, here: https://git.sr.ht/~sircmpwn/harec/tree/master/item/src/typedef.c#L329

Furthermore, if in my test program above, I comment out error and get(), then my debugging print statements show that type->alias.exported is set for foo. Weird!

Hopefully someone with a bit more familiarity with the codebase might be able to solve this faster than I can.