#101 Mangling affects strict global checking in REPL 16 days ago

Comment by ~andreyorst on ~technomancy/fennel

However, the first one should not work at all; it looks like somehow strict globals checking stopped working in the repl.

I agree. This was fixed in a11d3658

REPORTED RESOLVED FIXED

#101 Mangling affects strict global checking in REPL 17 days ago

Ticket created by ~andreyorst on ~technomancy/fennel

I'm not sure how exactly this should work but the current behavior is probably inaccurate:

Welcome to Fennel 1.0.0-dev on Lua 5.4!
Use ,help to see available commands.
Try installing readline via luarocks for a better repl experience.
>> (tset _G :foo (fn [] (print :foo)))
nil
>> (foo)
foo
>> (tset _G :foo-bar (fn [] (print :foo-bar)))
nil
>> (foo-bar)
runtime error: global '__fnl_global__foo_2dbar' is not callable (a nil value)
stack traceback: ...

#99 compiler special to detect vararg in current scope 28 days ago

Comment by ~andreyorst on ~technomancy/fennel

That's even better

#99 compiler special to detect vararg in current scope 29 days ago

Comment by ~andreyorst on ~technomancy/fennel

thanks! Really glad that we have it before 1.0.0. as I'm planning on making 1.0.0 mandatory for most of the libs when in will be out.

#97 short circuiting bug with (do) a month ago

Comment by ~andreyorst on ~technomancy/fennel

the opts.nval value is equal to 1 in cases like (and (do 42) false), and the branching is done depending if nval is set https://git.sr.ht/~technomancy/fennel/tree/main/item/src/fennel/specials.fnl#L121-131

#97 short circuiting bug with (do) a month ago

Comment by ~andreyorst on ~technomancy/fennel

But then it loses the ability to access vararg in a situation like this:

Apparently, the compiler already does this. So perhaps it tries to optimize the function away in this case for some reason.

Here are some examples:

The last example means that perhaps we already need the thing requested in #99, and it is only needed to be exposed.

#99 compiler special to detect vararg in current scope a month ago

Ticket created by ~andreyorst on ~technomancy/fennel

Vararg currently makes writing macros unsound. A macro that wraps user code can break in an unexpected way if user code uses vararg ..., and the macro wraps code in a function.

For example, if we were to implement do as a macro, to prevent #97 from happening we would have to analyze the current scope at compile time to detect vararg:

(macro do+ [...]
  `((fn [] ,...)))

(fn foo [x ...]
   (and x (do+ (print ...) x)))

;; expanded to

(fn foo [x ...]
  (and x (fn [] (print ...) x)))

;; which results in 'unexpected vararg' error

Such macro can't analyze its body for ... vararg presence. However if we could analyze upper scope similar to the in-scope? special we could adjust macro generation to produce the following code:

(macro do+ [...]
  (if (vararg-in-scope?)
    `((fn [...] ,...) ...)
    `((fn [] ,...))))

Thus fixing the issue. If vararg is not used by the macro body, then there's no problem, and if it is then we are covered. Unfortunatelly (in-scope? '...) doesn't work on ... directly, so currently it is impossible to cover such scenario.

#97 short circuiting bug with (do) a month ago

Comment by ~andreyorst on ~technomancy/fennel

Looks like we're hitting the Lua's lack of proper expressions. I think the only way to make this work is to transform do into an anonymous function that is immediately called. Kinda like Scheme's let does.

return (x and (function () return x.y end)() and x)

But then it looses the ability to access vararg in a situation like this:

(fn foo [x ...]
  (if x
    (do (print (select "#" ...))
        [...])
    (print :welp)))

But if we could detect that the outer scope has the vararg and compile do to a vararg function instead and call it properly (function (...) (print "#" ...) return {...} end)(...), then it would probably work seamessly.

#98 fennel.dofile sandboxing question a month ago

Ticket created by ~andreyorst on ~technomancy/fennel

This is more like a question, as I'm unsure what the correct behavior should be here.

I'm assuming that if I pass {:env some-env-table-here} to fennel.dofile my original env should not be affected by a script ran via dofile. However, if the script uses require it still populates root package.loaded.

Here's an example:

; file: f1.fnl
(local fennel (require :fennel))
(print (fennel.view (. package.loaded :f3)))
(fennel.dofile "f2.fnl" {:env {: require}} :f2)
(print (fennel.view (. package.loaded :f3)))

;; file f2.fnl
(local f3 (require :f3))

;; file f3.fnl
(fn foo [] 42)
{: foo}

Running the f1 file prints nil then the table:

fennel f1.fnl 
nil
{:foo #<function: 0x556f6e14c4a0>}

I've thought that maybe this is due to the fact that the default searcher populates root package.loaded, but creating a new searcher and replacing it in the fake env doesn't help here.

So my question: is is possible to properly sandbox fennel.dofile so everything that happens doesn't leak out?

#69 & rest destructuring does not work for proxy tables on Lua 5.2 and Luajit a month ago

Comment by ~andreyorst on ~technomancy/fennel

I've sent a patch for supporting __fennelrest metamethod that can be used in such proxy tables to do the destructuring correctly.