Hy and Boolean algebra

Recently I started wondering how Boolean algebra actually worked in Hy. I knew that we followed usual Python conventions and was sort of aware of them, but decided to dig into deeper and see how things actually are.

Granted, Boolean algebra maybe doesn’t sound the most exciting subject, but I found the results interesting. This post looks into things if Python 3.4 and 0.12.1 development version of Hy are used.

Continue reading

Hy and creating new dictionaries from old ones

I was recently asked on irc if Hy has something equivalent to following snippet of Python code:

>>> x = {"a": 123}
>>> dict(foo=1, **x)
{'a': 123, 'foo': 1}

The closes I could come up with is following:

=> (setv x {"a" 123})
=> (apply dict [(, (, "foo" 1))] x)
{"foo" 1, "a" 123}

The end result is the same, although it isn’t exactly the same snippet of code, as it’s closer to one below:

>>> dict((("foo", 1),), **x)
{'a': 123, 'foo': 1}

Lots of dicts with various syntaxes here, but what does all that mean and where would that be useful?

The net effect in all cases is that:

  • Original dictionary x isn’t modified
  • A new dictionary is created with content of x and new key-value pair of “foo”: 1.

This is useful when you want to pretend to be working with immutable data-structures and keep the dictionary passed in to a function unchanged, while returning something that is equal to the original + some more.

apply by the way is used to apply optional list of arguments and optional dictionary of key-value pairs to a function. Thus, it’s akin to foo(*args, **kwargs) call in Python.

Hy and anaphoric macros

There’s a nice contrib module in Hy called anaphoric, that (surprise, surprise) contains bunch of anaphoric macros. Wikipedia has nice definition for these in general:

An anaphoric macro is a type of programming macro that deliberately captures some form supplied to the macro which may be referred to by an anaphor (an expression referring to another). Anaphoric macros first appeared in Paul Graham‘s On Lisp and their name is a reference to linguistic anaphora—the use of words as a substitute for preceding words.

Hy documentation lists several of them: ap-if, ap-each, ap-each-while, ap-map, ap-map-when, ap-filter, ap-reject, ap-dotimes, ap-first, ap-last and ap-reduce. I’m not going through all of them in detail, but instead picking couple of them to highlight what the concept is about (I use them all the time while coding).

Continue reading

Destructuring in Hy

Hy has lots of little features that I often forget to use. This post is about destructuring and I hope that after writing about it a bit, I’ll remember it in the future. Incidentally, this came up while I was working with new AI routines for rats.

But lets start with the canonical example how to swap values of two variables:

=> (setv a 5)
=> (setv b 10)
=> (setv (, a b) (, b a))
=> a
10
=> b
5

And now into AI routines and destructuring. I’m using A* routines by Pauli Rikula without any modifications. It’s easy to use and works well for my purposes. The interface is simple:

(a-star start goal a-map) -> (, path connections updated)

Client code calls a-star and supplies three parameters: start of the path, destination and map where traversing is done. Routine calculates the path and returns a tuple of three elements: path consisting of each square traversed, starting from start location and ending to the destination, and two lists of debug information.

I’m not interested on connections or updated, as they’re mainly useful for debugging purposes. I could call it like this:

(setv res (a-star (. character location)
                   destination
                   (. character level))
      path (first res) ...)

but since Hy supports destructuring just like Python, I can break result into parts and store them in individual variables like this:

(setv (, path connections updated) (a-star (. character location)
                                            destination
                                            (. character level) ...)

After this I can refer to path, connections or updated within the let form.

Same structure works in many places, as shown by this list comprehension example:

=> (setv data [[1 2] [3 4] [5 6] [7 8]])
[[1, 2], [3, 4], [5, 6], [7, 8]]
=> (list-comp (* a b) [(, a b) data])
[2, 12, 30, 56]

Function parameters can contain lists of parameters. Every list is a parameter that get destructured when called. Lets pretend that we have decided to model complex numbers with tuples, for example 2+1i would be (, 2 1). We would like to add two complex numbers together and write following code:

=> (defn add [a b]
...  (, (+ (first a) (first b)) (+ (second a) (second b))))
=> (add (, 1 2) (, 3 4))
(4, 6)

However, this can be simplied:

=> (defn add [[a b] [c d]]
...  (, (+ a c) (+ b d)))
=> (add (, 1 2) (, 3 4))
(4, 6)

results are identical.

Testing Hy macros

I like my code tested and working. I like it even better when it’s done automatically. But recently I was faced with a new kind of code that proved to be rather different beast to tackle: macros. Problem with testing them is that macros usually capture some common, general pattern and give it a name. If one were to use the same approach as with testing function, they would feed specific parameters to macro and assert that the generated code looks like what it should look like. This could soon lead into brittle, hard to maintain tests, since tests would specify very precisely what the generated code should look like. Even minor changes to implementation would break most of the tests, even if the functionality of the generated code wouldn’t change.

Better option (depending on the case again) would be to write code that uses that macro and assert that the code has correct functionality. Depending on the complexity of the macro this might require more than single test in order to cover all possibilities. This is the way I usually test my macros, when I bother testing them at all. Most of the time I just assume that if there are any problems with the macro implementation, tests covering code where it is used will catch problems.

Continue reading

Writing macros with Hy

I have recently been working with some macros with Hy and wanted to write down some of things I have noticed or learned.

In lisp, code is essentially just a large tree (or bunch of lists inside of other lists). These lists are called s-expressions or sexprs for short. Following simple example demonstrates this:

=> (- (+ 2 (* 3 4)) (+ 1 1))
12

Functions work the same way, first element is the function being called and rest of the elements are parameters for that function:

=> (cut [0 1 2 3 4 5] 2 5)
[2 3 4]

One of the advantages of this system is that lists are generally pretty easy to manipulate. One can insert, remove and modify elements easily. If we consider a regular hy program, it’s just a collection of lists that define the code of the program. And this is where macros start to come into play.

A list macro is small snippet of code that can produce code or data (they’re essentially a same thing anyway). This lets programmer to automate writing some parts of the code. Instead of typing similar snippet of code over and over again, programmer writes a macro that does this for them. Since macro is an actual executable piece of code, it can inspect the parameters given to it and use them in its internal logic. They’re really great tool if you want to add new features to the language and extend it in ways that help you to write your programs more elegantly with less effort.

Continue reading

Macros are nifty

I have been trying to wrap my head around Hy macros and have made just a little bit progress. The concept is really powerful, but since it is so new to me, it is hard to find out where to actually use them. It seems that they are well suited on extending the language by building constructs that would be tedious to type or which would reflect on the problem domain better. In any case, I tinkered with them again and came up with not-so-useful infix macro. It allows the user to write code using infix notation, where the operator is in the middle, instead of in the beginning:

(defmacro infix [code]
  (quasiquote (
    (unquote (get code 1))
    (unquote (get code 0))
    (unquote (get code 2)))))

With this macro, one can write code like:

=> (infix (1 + 1))
2

Not very useful, but still nice little exercise in macro writing.