Open Issues with LFE
	====================

There are a number of known open issues with LFE that should be
resolved in the next release:

Function bindings
-----------------

Core Erlang (and Erlang and the BEAM) separate variable and function
bindings. A function binding has a name and an arity, this is a result
of allowing different functions to have the same name but different
number of arguments. Also there is no concept of a function reference
built into the Core and BEAM. It is therefore impossible to get a
reference to a function and pass it around, creating a fun which calls
this function is not the same thing. So code like:

In CL: (funcall #'cons a b)
In Scheme: (let ((my-cons cons)) (my-cons a b))

CANNOT work in Erlang.

So in LFE there are two types of bindings, variables bindings through
let and function bindings through letrec and top-level defines. To try
and mimic the use of bindings in Scheme when a function call is made
the compiler tries to find the lexically closest binding which could
be a valid function, either a variable of the same name or a function
of the same name/arity as the call. When a vaule is needed only the
variables bindings are used as there is no way to return a function
binding as a value.

The question is whether to keep this attempted merging of variable and
function bindings as is done in Scheme or to go more in the CL way and
have separate bindings? Doing this would mean adding a funcall
primitive to use a variable binding as a function. So we would get:

(let ((f (lambda (x y) ... )))
  (funcall f a b))

where today we could just do:

(let ((f (lambda (x y) ... )))
  (f a b))

The benefit would be more consistency and "Erlangy" feel, but it would
result in more verbose code. I don't think it is either practical or
really necessary to add function objects to the language.

Macros
------

A result of the function binding problem is that it is impossible to
add truly hygenic macros as in Scheme. The current implementation
makes no attepmt to do this, and is very basic. The syntax-rule form
mimics its Scheme counterpart, but without ... , and the macro form
provides a match-lambda type interface where you can match on the
macro argument.

In the macro form the body is evaluated by the interpreter and the
resultant return value inserted into the code, like normal
macros. There is no real gensym function though one could be easily
faked for the macroexpander.

The question is which way to go with macros? I personally think that
the syntax-case form from Scheme is so pure and beautiful as to be
practically unusable and I would like usable macros. Even if it is no
problem to generate your own code with LFE.

N.B. Macro expansion is only done at compile time and the evaluator
does not support macros. The Erlang engine has no concept of macros or
functions with different number of arguments.

Macro-expansion in patterns
---------------------------

This is not done today, but definitely will be done in the next
version.

Patterns
--------

In the current version patterns are normal data expressions where you
quote symbols which are literal, otherewise they are interpreted as
variables. An alternative would be use a more backquote like style
where everything is by default quoted and you unquote symbols which
are variables. This is just a matter of preference.

('allan x y)  or  (allan ,x ,y)

In patterns tuples are written with tuple constants while binaries/-
bitstrings are written with the constructor syntax (as a list). This
means that you cannot have a list pattern where the first element is
the symbol variable binary. I don't see this as a problem.

Another question is then whether to use this form for tuples as well?
We don't have the problem with constant tuples that lisp does.

Namimg
------

This version uses similar name conventions as Scheme, but sometimes
they are so *long*. Perhaps use more CL inspired names? Especially if
we go over to a more CL like handling of function bindings. Perhaps do
an AFE (Arc Flavoured Erlang)?

Core LFE Forms
--------------

It is possible to define functions and macros, or import functions
with the same names as the Core forms (see the guide) but these will
always silently be ignored. These are the language and I don't think
they should be allowed to be redefined.

There is however no problem with redefining Erlang BIFs, they are just
treated as pre-imported functions from the module Erlang.