Calvin Rose <calsrose@gmail.com> writes:

> I think its a good idea, and probably not too much wrong in the way of
> backwards incompatibility. It's definitely a useful feature for macros
> and I can't really think of any big problems with it. The patch looks
> good!

Thanks! Pushed this on out along with an expanded explanation in the
macro section of reference.md.

-Phil

Interested in folks' thoughts on this.

It's basically borrowing the Clojure solution to macro hygiene, which is
not nearly as strict as Scheme's solution, but I believe is much easier
to understand. If folks feel strongly about exploring a stricter-hygiene
approach we can talk about that, but I was surprised with how low-effort
this particular approach was while still avoiding 99% of unintentional
symbol captures.

Basically now all local names that are inside a backtick must be
gensym'd now in order to avoid symbol capture, but you can do this
automatically by appending # to the symbol:

    `(let [x# 1] ,body)

When using backtick, in order to avoid symbol capture, bare symbols
are not allowed to be used as identifiers. Instead, gensyms must be
used. In order to make this more palatable, we support "auto-gensym"
by appending # to the end of your locals; within a single scope this
will create a gensym beginning with your local name.

This is similar to the method Clojure uses to prevent accidental
symbol capture; however Clojure does this by auto-qualifying all
symbols inside a backtick with the current namespace. Since we don't
have namespaces, we simply set a "quoted" flag on the symbol.

This also reverts the change which prevented # from being a valid
symbol constituent character.
---
[message trimmed]

Benjamín Buccianti <bebuccianti@gmail.com> writes:

> Maybe we can improve the way in which the Lua code is showed. Don't know
> your idea of how to present the pane. But I think that this is a start.

Nice work! I deployed the newer version of this change that you sent,
which has a pane that shows the compiled Lua output. It's a really great
touch for people who are curious about how the compiler works.

-Phil

Ag Ibragimov <agzam.ibragimov@gmail.com> writes:

> Hi, I just rewrote my entire Hammerspoon configuration using Fennel
> and I can't be happier. Fennel is awesome. Now I want even more out of
> it. I'm thinking if it would be possible to have a Fennel REPL that
> compiles and evals by sending forms to Hammerspoon's IPC. I doubt that
> anyone has ever tried that before, any hints how I can build something
> like this would be appreciated. Thanks!

Sure; you can start a repl that has the read/write functions overridden
to use another function other than io.read and io.write; for instance,
something that communicates over IPC. Here is an example of how the repl
on fennel-lang.org does it; in that case the repl runs in a coroutine
which gets resumed when the enter button is pressed in the input

Ag Ibragimov <agzam.ibragimov@gmail.com> writes:

> So I'm wondering if there is a way to refer to third party Lua
> functions using kebab/lisp syntax and somehow force Fennel to correct
> them into using camelCase.
>
> Is something like that possible?

Sure--there's two ways you could do this. First, you could have a
code-rewriting macro which checks for any references to a specified
global such as `hs` and performs a rewrite on any direct field
references to make them camelCased. This would have no runtime
overhead, but it would miss non-direct references such as `(. hs
:console :clearConsole)` or any iterator use.

Hey everybody!

I'm heading home from a successful FennelConf 2019. Thanks to all the
speakers who put a lot of work into the excellent talks, to Justin Smith
for hosting us at our venue, and to Ken Restivo for helping set up an
A/V streaming and recording arrangement. We were able to stream the
talks as the conference happened, and three of the four talks were
recorded.

You can watch the videos at https://conf.fennel-lang.org.

Looking forward to seeing you all next year!

-Phil

Phil Hagelberg <phil@hagelb.org> writes:

> I loaded the new version into EXO_encounter-667, which is my largest
> Fennel codebase. It removed all but 3 unnecessary IIFEs (at least, those
> 3 seemed unnecessary to me; maybe they in fact are needed.)

Here are the IIFEs I saw; turns out there's 3:

    (let [layer (: map :addCustomLayer "player" 8)]
      (set layer.sprites [(unpack state.rovers)])
      (tset layer.sprites 0 state.probe)
      (set layer.draw (partial draw.player world state)))

    ;; local function _0_(...)

Calvin Rose <calsrose@gmail.com> writes:

> This is a heads up on some changes I have been working on for Fennel
> having to do with code generation. Some discussion on IRC has been about
> how the Fennel compiler (0.2.1) was generating anonymous functions that
> are immediately called (IIFE, or Imediately Invoked Function Expression)
> in many cases, even when not strictly necessary.

Nice work! I only find the need to look at the compiled output
increasingly rarely, but "too many IIFEs" was basically my only
complaint about the readability when I did need to.

I loaded the new version into EXO_encounter-667, which is my largest
Fennel codebase. It removed all but 3 unnecessary IIFEs (at least, those

Hey folks.

Yesterday Calvin just pushed out version 0.2.1 of Fennel, which fixed a
few bugs we found right after the 0.2.0 release:

* Add not= as an alias for ~=
* Fix a bug with in-scope? which caused pattern matching outer unification to fail
* Fix a bug with variadic ~= comparisons
* Improve error reporting for mismatched delimiters

Happy hacking!

-Phil