Lisp Flavoured Erlang Google Group

Re: In the pipeline

2010-03-03T04:42:14Z

Should read: "Therefore, I would prefer to see ":" used as the module prefix
and the function name separator of choice"
On Tue, Mar 2, 2010 at 11:40 PM, Jonathan Smith

Re: In the pipeline

2010-03-03T04:40:20Z

The generalized prefix would be fairly easy to add to it.
The only issue I really would have with it was that I can't think of a use
case where it is really advantageous.
(Perhaps if you have a particularly long module name, but generally Erlang
module names seem to be fairly concise).
Even so, being able to change between "//" and ":" and whatever might get a

Re: In the pipeline

2010-03-02T22:09:22Z

I should have commented this earlier.
This is a nice idea, it sort of works backwards to how I had
envisioned (prefix ...) to work. It is definitely easier to implement
and much more efficient for the interpreter as it generates macros.
Very good for libraries. I would extend it be used like:
(import-module foo foo:)

REPL search tool for functions

2010-02-18T07:31:32Z

Hi. I have a small _experiment_ going on here [1] that I wish to share.
It's a search tool for functions. Also, a faster way of looking up Erlang
functions.
As you may imagine, it's not for every module out there.
The syntax is: (query <module> (where <arguments> '-> <output>))
(#(fail (== (: lists concat '(3 1 3)) '(1 3)) '"313")

Re: LFE is wonderful! Question about inconsistent behavior when matching

2010-02-17T18:31:20Z

i'm sure you have plenty of stuff in the TODO pipeline... i wonder if
there is anybody using LFE who could donate time and brains to getting
LFE + Dialyzer more production-ready? (not me!)
sincerely.

Re: LFE is wonderful! Question about inconsistent behavior when matching

2010-02-17T14:48:54Z

Be warned that dialyzer contains no LFE support at present. All I did was a
quick feasibility test to show that it would be possible to use it with LFE.
Robert

Re: LFE is wonderful! Question about inconsistent behavior when matching

2010-02-17T14:34:30Z

Thank you for your generous reply. I'll take another look at dialyzer.
--- Sarino
To: "Lisp Flavoured Erlang" <lisp-flavoured-erlang@googleg roups.com>
Using many source-levels tools will, of course, be difficult but with
the dialyzer it will be possible with LFE. This is because the
dialyzer does not work on source erlang but an internal format in the

Re: In the pipeline

2010-02-17T05:33:28Z

Hi,
I have come up with a little macro for doing module imports.
Posted here:
[link]
I'll let you look at the code, but pretty much you use it like:
(import-module foo)
And then it finds all of the exported functions in that module, and
creates a macro foo:fn-name for each, which expands into the form

Re: LFE is wonderful! Question about inconsistent behavior when matching

2010-02-16T22:51:59Z

Using many source-levels tools will, of course, be difficult but with
the dialyzer it will be possible with LFE. This is because the
dialyzer does not work on source erlang but an internal format in the
compiler, Core erlang, which LFE also uses. I have done some quick
hacks to the dialyzer and got it to work, but it is nothing you would

LFE is wonderful! Question about inconsistent behavior when matching

2010-02-16T00:32:54Z

Hello, Mr. Virding:
I want to tell you first of all how much I like your lisp front-end
to erlang. It makes using erlang -- as good a system as it is -- that
much more pleasurable to use. It has made me so productive that, from
now on, I will be implementing most of my high-level modules in LFE. I
will continue to design the lower-level ones in erlang, however,

Re: In the pipline

2010-02-03T11:51:44Z

- When OTP documentation tools are properly available convert all
documentation to use them.
I am not a fan of edoc!
Getting old,
Robert

In the pipeline

2010-02-03T11:36:22Z

Here are some things which are in my immediate pipeline for LFE:
- The interpreter, lfe_eval, does not handle macro expansion properly,
fix this.
- Guards are a mess now if you want more complex guards, it's not at
all clear, fix this.
- Improve the user_guide.txt documentation adding a new section on

Git and github

2010-01-29T22:32:50Z

Using github to work on LFE is a Good Thing. Forking LFE and telling
me when there is something to pull makes it easy for me to incorporate
changes. But it is even better if you create your own branches to do
it in and don't use either master or develop; pretty much like with
otp. This make is it easier for me to keep my branches clean and

LFE examples

2010-01-29T22:23:14Z

Getting back in the groove now after Christmas/New Year.
A few days ago Mats (cadar) asked me what requirements I have for LFE
examples. Very few actually and not that difficult:
- A simple copyright which allows people to load, run and modify the
code.
- An interesting, fun, different, etc piece of code. If it is

shell automation using screen

2010-01-11T09:33:25Z

A bit off topic but I found it useful.
To automate repetitive tasks I use "screen -X stuff $'<command>'" to start,
load and test my code. The stuff command send characters to a started screen
session. It works great.
This is the script:
---------------------
function run {
screen -X stuff "$1"
sleep 0.1