Recent activity

[RFC v1] Default struct field initializers a month ago

From spxtr to ~sircmpwn/hare-rfc

			RFC SUMMARY

Struct literals can be initialized using the ... notation, which assigns
a default value to any fields which are not explicitly assigned. This is
convenient, but for some fields there is either no default value (tagged
unions, non-null pointers), or the default value is not semantically
correct.

There are currently several proposals floating around regarding how to
make default struct initializers more ergonomic. This RFC introduces
another: struct field initializer expressions. Rather than place a
default value on arbitrary types, it is placed on the struct fields
using the same syntax as optional function parameters.

[PATCH hare] Remove most unused imports. a month ago

From Joe Finney to ~sircmpwn/hare-dev

From: spxtr <me@spxtr.net>

Signed-off-by: Joe Finney <me@spxtr.net>
---
 bufio/stream.ha                     |  2 --
 cmd/hare/build/queue.ha             |  1 -
 cmd/hare/version.ha                 |  1 -
 cmd/harec/gen.ha                    |  3 ---
 cmd/haredoc/doc/color.ha            |  2 --
 cmd/haredoc/doc/resolve.ha          |  1 -
 cmd/haredoc/doc/tty.ha              |  1 -
 cmd/haredoc/doc/util.ha             |  2 --
 crypto/aes/+x86_64/ni.ha            |  1 -
 crypto/aes/aes_ct64.ha              |  1 -
[message trimmed]

Re: strconv crashes when converting a lowercase hex decimal to an u64 a month ago

From spxtr to ~sircmpwn/hare-dev

Thanks. I've sent a patch to fix this. You can just use base::HEX for
string->number conversions and it will handle both upper and lower case
correctly. HEX_LOWER and HEX_UPPER only matter for number->string.

Eventually I want to get rid of HEX_LOWER and HEX_UPPER entirely in
favor of a flag to the number->string functions. But for now this should
help.

[PATCH hare] Handle base::HEX_LOWER in stof and stou. a month ago

From Joe Finney to ~sircmpwn/hare-dev

Signed-off-by: Joe Finney <me@spxtr.net>
---
 strconv/stof.ha | 14 +++++++++++---
 strconv/stou.ha |  3 +++
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/strconv/stof.ha b/strconv/stof.ha
index 563a1470..f873c007 100644
--- a/strconv/stof.ha
+++ b/strconv/stof.ha
@@ -628,7 +628,11 @@ fn special(s: str) (f32 | void) = {
// nearest to zero with respective sign. Recognizes "Infinity", "+Infinity",
// "-Infinity", and "NaN", case insensitive.
export fn stof64(s: str, b: base = base::DEC) (f64 | invalid | overflow) = {
[message trimmed]

Re: Hare doesn't allow this a month ago

From spxtr to ~sircmpwn/hare-users

size_t is not actually a keyword in c. Note that you can't name a struct
field named "int" in c, because int is a keyword. In Hare, size is a
keyword and it can't be used as a name.

I usually use one of "length", "count", "num", or "sz" for such things.
If you *must* name it size for semantic reasons (you can see some of
this in hare::ast, for example), you can use "_size".

Re: [PATCH hare] format::ini: use bufio::scanner a month ago

From spxtr to ~sircmpwn/hare-dev

LGTM, and significantly speeds up ini scanning.


-export fn scan(in: io::handle) scanner = scanner {
-	in = in,
-	lineno = 1,
-	...
+export fn scan(in: io::handle) scanner = {
+	return scanner {
+		scan = bufio::newscanner(in),
+		lineno = 1,
+		...
+	};
 };

Re: [RFC PATCH hare-specification] Relicense specification with the GNU FDL a month ago

From spxtr to ~sircmpwn/hare-dev

I am ok with it. CC-BY-ND is not good.

[PATCH harec v2] Allow optional parameters in variadic functions. a month ago

From Joe Finney to ~sircmpwn/hare-dev

Signed-off-by: Joe Finney <me@spxtr.net>
---
 src/check.c       | 14 ++++++--------
 src/type_store.c  | 27 ++++++++++-----------------
 tests/09-funcs.ha | 18 +++++++++++++++---
 3 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/src/check.c b/src/check.c
index e21c094..d522369 100644
--- a/src/check.c
+++ b/src/check.c
@@ -1455,6 +1455,12 @@ check_expr_call(struct context *ctx,
		next = &arg->next;
		param = param->next;
[message trimmed]

[PATCH hare-specification] Allow optional parameters in variadic functions. a month ago

From Joe Finney to ~sircmpwn/hare-dev

From: spxtr <me@spxtr.net>

Signed-off-by: Joe Finney <me@spxtr.net>
---
 language/types.tex | 50 ++++++++++++++++++++++------------------------
 1 file changed, 24 insertions(+), 26 deletions(-)

diff --git a/language/types.tex b/language/types.tex
index 69246b4..a2d8992 100644
--- a/language/types.tex
+++ b/language/types.tex
@@ -748,28 +748,21 @@ the data field set to null.
	\terminal{(} \optional{\nonterminal{parameter-list}} \terminal{)} \nonterminal{type} \\

[message trimmed]

Re: Pre-RFC: default values for struct members a month ago

From spxtr to ~sircmpwn/hare-dev

 > we have default values for certain types (i.e. tagged unions) already

I thought these had no default? If you put a tagged union in a struct 
then you can't initialize the struct with { ... }.

 > also, where do we stop? what about adding default values to unions 
and tuples too?

That's basically what I'm asking in this question: would struct members 
be sufficient, or are there practical use cases for other sorts of defaults?

As it stands, the ... operator only fills in defaults in structs. 
There's a proposal to allow it elsewhere, as in "let x: int = ...;". I'm 
struggling to think of any cases where the general behavior would