#157 Compiled binaries for 1.3.0 don't allow loading dynamic-linked C libraries 21 days ago

Comment by ~technomancy on ~technomancy/fennel

Rebuilt this a while back and it looks good now.

REPORTED RESOLVED FIXED

#170 Variadic arguments fail on builtin math operators 22 days ago

Comment by ~technomancy on ~technomancy/fennel

1. Make + into a macro that sees how many arguments it's being called with, and only generate a loop if it's a variadic call

If this were possible we would have done it already. =)

(fn nums [] (values 1 2 3 4))

(fn calculate [f] (+ 3 (f)))

(calculate nums)

How do you detect a variadic call at compile time?

1. Make it an error to call variadic built-in operators, add new library functions fennel.sum, fennel.mul, etc. that are explicitly made in order to operate on multiple values

Sure, but the problem is there is no such thing as a library function in Fennel.

suggest to use those in these edge cases.

It's difficult to know how to suggest this in a way that would be effective.

The reference already describes this limitation, but people still run into problems with it.

Always open to suggestions about how to make it clearer of course!

#170 Variadic arguments fail on builtin math operators 22 days ago

needs-design added by ~technomancy on ~technomancy/fennel

#170 Variadic arguments fail on builtin math operators 22 days ago

enhancement added by ~technomancy on ~technomancy/fennel

#170 Variadic arguments fail on builtin math operators 22 days ago

Comment by ~technomancy on ~technomancy/fennel

Yeah, this is legitimately a long-standing problem inherent in Fennel's design.

At the bare minimum, it would be helpful if this was some kind of error.

Making it an error to call + directly on ... is fine, (I would take a patch for this) but it wouldn't really solve the root problem; the problem is that any function could return multiple values, and it's impossible to determine this at compile-time.

A more thorough fix would certainly be to compile out to an IIFE as you've described. However, there is a very significant performance overhead to this, especially when considering its impact on the tracing JIT; a call which used to be compiled down to a handful of native instructions might now get no JIT at all. Making every single addition call slower to paper over an edge case is not a good trade-off.

So a fix for this would be a new set of forms which do the job of the regular operators but are multival-friendly. I would certainly consider a proposal to introduce such a thing, since this comes up frequently. But I don't think that there can be any acceptable fix for the problem if you're not aware of it up-front, unfortunately. (Or maybe there is and we just haven't thought of it yet?) Perhaps just the existence of these alternate forms could be a kind of signal that raises awareness of the shortcomings of the regular operators.

#169 Linter false-positive? on setting named function to the table 26 days ago

Comment by ~technomancy on ~technomancy/fennel

I think in this case when the user wants to enable this linting but doesn't want to use the name, they should pick a name that starts with an underscore.

#168 Avoid repeated lookups in case/match 26 days ago

macros added by ~technomancy on ~technomancy/fennel

#168 Avoid repeated lookups in case/match 26 days ago

enhancement added by ~technomancy on ~technomancy/fennel

#167 comment special is broken if code has ]] in it 26 days ago

bug added by ~technomancy on ~technomancy/fennel

#167 comment special is broken if code has ]] in it 26 days ago

Comment by ~technomancy on ~technomancy/fennel

Fixed in 5c94c7f.

REPORTED RESOLVED FIXED