Fix define-pyfun macro in compiled mode

[sjamaan]

The macro would expand to a direct reference to the hash-table-ref/default and hash-table-set! procedures rather than the identifiers for those procedures. This works in the interpreter because it is a bit lax when intermixing expansion code with evaluated code, but when compiling code that uses the macro, it breaks with this error:

Syntax error: illegal atomic form

#<procedure>

Fixes issue #12

[sjamaan]

I think it might be wise to rewrite these as implicit renaming macros - there's a lot of renames that can be easily forgotten.

I started by rewriting these as syntax-rules macros which expanded into a call to a single define-maybe-from-string kind of macro which would just check if the argument would be a string or an identifier but that didn't work for define-pymethod, as that macro has keyword arguments where one can override the scheme-name with a custom one. Picking keyword arguments in a syntax-rules macro is very tricky. In this case it can be done statically because there are only two optional arguments, but that already results in four possible cases... Also, it would break in older CHICKENs where keywords are bogusly allowed as identifiers.

[iraikov]

Thanks Peter, I will definitely consider the implicit renaming route. These macros are quite complicated and I was never quite happy with them.

I think it might be wise to rewrite these as implicit renaming macros - there's a lot of renames that can be easily forgotten.

I started by rewriting these as syntax-rules macros which expanded into a call to a single define-maybe-from-string kind of macro which would just check if the argument would be a string or an identifier but that didn't work for define-pymethod, as that macro has keyword arguments where one can override the scheme-name with a custom one. Picking keyword arguments in a syntax-rules macro is very tricky. In this case it can be done statically because there are only two optional arguments, but that already results in four possible cases... Also, it would break in older CHICKENs where keywords are bogusly allowed as identifiers.

[iraikov]

Closed in favor of #14