thanks!

to git@git.sr.ht:~ecs/madeline
  2df3752..ef22493  renderv2 -> renderv2

On Thu Jan 23, 2025 at 9:12 AM UTC, Drew DeVault wrote:
> On Sun Jan 19, 2025 at 9:45 PM CET, Ember Sawady wrote:
>> On Tue Jan 7, 2025 at 8:42 AM UTC, Drew DeVault wrote:
>>> I decided not to use Seb's suggested grammar for defining the annotation
>>> syntax entirely in the formal grammar. I think it's a bit better to
>>> define "balanced tokens" in prose. The previous patch (and Seb's
>>
>> yeah, i agree with seb and bgs that it'd be better to specify this in 
>> the grammar
>
> I would really prefer not to do that. I think that it's pretty
> reasonable to describe this informally and the explosion of nonterminals
> to describe what is ultimately pretty simple is not desirable.

On Thu Jan 23, 2025 at 9:13 AM UTC, Drew DeVault wrote:
> On Wed Jan 22, 2025 at 5:29 PM CET, Ember Sawady wrote:
>> similar to the harec patch, i'd prefer to lex `#[` as a single token. 
>> this also should be let, rather than const, since it's mutated later in 
>> the code
>
> Same NACK

(i presume that nack doesn't cover the s/const/let/?)

On Thu Jan 23, 2025 at 9:13 AM UTC, Drew DeVault wrote:
> On Sun Jan 19, 2025 at 9:54 PM CET, Ember Sawady wrote:
>> hm, i'd kinda prefer to make `#[` one token - as bgs said, it'd be nice 
>> to keep `#` open, and i can't really see a reason anyone would want to 
>> stick whitespace in between the two
>
> NACK, I don't see any reason to prefer one over the other *now*. If we
> use # in the future we can just merge #[ at that time.

i don't see any reason *not* to merge them now, and while it's perfectly 
acceptable to do things in such a way that will likely require breaking 
changes in the future (see eg. if (let)), all else being equal i'd 
prefer to do things right from the start if possible

On Wed Jan 22, 2025 at 6:45 PM UTC, Lorenz (xha) wrote:
> but i don't know, maby we should generalize the evaluation order
> across the spec with something like:
>
> 	The evaluation order shall be as follows: first the object
> 	selector, and then bla bla bla
>
> with that it should also be pretty clear when the indexing aborts or
> the value. and we could prevent two or three paragraphs that talk about
> the evaluation order and just have it in one, which makes it clearer?

we should specify evaluation order individually for each expression 
type; seb as a pending patch which (iiuc, i haven't yet gotten around to 
reviewing it) does this

thanks!

to git@git.sr.ht:~sircmpwn/hare-specification
  f07ed81..fd73e45  master -> master

needed some fiddling to apply, not sure why but one of the lines got 
split in two for me

lgtm but needs rebase

lgtm but needs rebase

thanks!

to git@git.sr.ht:~sircmpwn/harec
  d1f1151..0b339b3  master -> master

thanks!

to git@git.sr.ht:~sircmpwn/harec
  d1f1151..0b339b3  master -> master