From dsb at prairienet.org  Sun Jun  1 15:13:52 2008
From: dsb at prairienet.org (Dan Bensen)
Date: Sun, 01 Jun 2008 10:13:52 -0500
Subject: [erlang-in-lisp-devel] fare-match question
In-Reply-To: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
References: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
Message-ID: <4842BCB0.5080502@prairienet.org>

Matt Bone wrote:
> are our pattern matching requirements so minimal that 
> a) it does not matter and b) we could even roll our own
> ala some of the Norvig examples?

According to one of the tutorials[*], Erlang patterns support variable
repetition.  I think Fare mentioned using existing Erlang test code,
so that might be an issue.

--Dan

[*] http://www.erlang.org/course/sequential_programming.html#patterns

------------------------------------------------
Dan Bensen  http://www.prairienet.org/~dsb/

cl-match:  expressive pattern matching in Lisp
http://common-lisp.net/project/cl-match/



From rvirding at gmail.com  Sun Jun  1 15:36:21 2008
From: rvirding at gmail.com (Robert Virding)
Date: Sun, 1 Jun 2008 17:36:21 +0200
Subject: [erlang-in-lisp-devel] fare-match question
In-Reply-To: <4842BCB0.5080502@prairienet.org>
References: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
	<4842BCB0.5080502@prairienet.org>
Message-ID: <3dbc6d1c0806010836u7cd58ffcq2502c559bbf467d1@mail.gmail.com>

2008/6/1 Dan Bensen <dsb at prairienet.org>:

> Matt Bone wrote:
>
>> are our pattern matching requirements so minimal that a) it does not
>> matter and b) we could even roll our own
>> ala some of the Norvig examples?
>>
>
> According to one of the tutorials[*], Erlang patterns support variable
> repetition.  I think Fare mentioned using existing Erlang test code,
> so that might be an issue.
>

Excuse my ignorance here but what exactly are you planning to use the
pattern matching for? If it is for use in the code to which you compile
Erlang then I would seriously think through how you are compiling Erlang.

Yes, Erlang supports variable repetition (with implicit checking of values)
and also non-lexical scoping so using and already bound variable in a
pattern also means an implicit comparison of values.

I would not directly compile the Erlang code to lisp but would use the first
few passes of the Erlang compiler. This would ensure compatibility with
existing Erlang for many features (records, list/binary comprehensions) and
be much easier as the internal languages are much simpler.

I would suggest using Core Erlang or even kernel Erlang. Core is a very
simple functional language which has lexical scoping and simplified pattern
matching. Kernel erlang has been fully lambda lifted and is completely
"flat" and pattern matching has been compiled and optimised to basic tests.

In a follow up to this mail I will send a copy of a presentation of LFE
(Lisp Flavoured Erlang) I gave which I think would be interesting in 2
respects:

- the LFE core forms are *very* close to Core Erlang (almost 1-to-1)
- there is a *short* description of the compiler at the end, only 3 slides
but it at least presents the passes and some of the internal languages.

It's 87 kB Powerpoint document so I apologise for sending big message.
Unfortunately I can't convert it to PDF, if anyone can help with this I
would appreciate it.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/erlang-in-lisp-devel/attachments/20080601/089ed77d/attachment.html>

From rvirding at gmail.com  Mon Jun  2 21:37:54 2008
From: rvirding at gmail.com (Robert Virding)
Date: Mon, 2 Jun 2008 23:37:54 +0200
Subject: [erlang-in-lisp-devel] fare-match question
In-Reply-To: <3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com>
References: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
	<4842BCB0.5080502@prairienet.org>
	<3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com>
Message-ID: <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com>

Hello all,

The presentation is delayed as it is so big it needs approval by the list
master. Sorry about that.

Robert

2008/6/1 Robert Virding <rvirding at gmail.com>:

> The LFE presentation.
>
> Robert
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/erlang-in-lisp-devel/attachments/20080602/66c1e36e/attachment.html>

From fahree at gmail.com  Mon Jun  2 22:23:07 2008
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Mon, 2 Jun 2008 18:23:07 -0400
Subject: [erlang-in-lisp-devel] fare-match question
In-Reply-To: <3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com>
References: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
	<4842BCB0.5080502@prairienet.org>
	<3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com>
	<3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com>
Message-ID: <653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com>

Is there a permanent link to it? That might be easier and better than
trying to fit it into the list.

[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
There is no such thing as philosophy-free science; there is only science
whose philosophical baggage is taken on board without examination.
        -- Daniel Dennett, Darwin's Dangerous Idea


2008/6/2 Robert Virding <rvirding at gmail.com>:
> Hello all,
>
> The presentation is delayed as it is so big it needs approval by the list
> master. Sorry about that.
>
> Robert
>
> 2008/6/1 Robert Virding <rvirding at gmail.com>:
>>
>> The LFE presentation.
>>
>> Robert
>>
>
>
> _______________________________________________
> erlang-in-lisp-devel mailing list
> erlang-in-lisp-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel


From rvirding at gmail.com  Mon Jun  2 22:46:20 2008
From: rvirding at gmail.com (Robert Virding)
Date: Tue, 3 Jun 2008 00:46:20 +0200
Subject: [erlang-in-lisp-devel] fare-match question
In-Reply-To: <653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com>
References: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
	<4842BCB0.5080502@prairienet.org>
	<3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com>
	<3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com>
	<653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com>
Message-ID: <3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com>

OK, there is one now:

http://forum.trapexit.org/viewtopic.php?p=43941#43941

2008/6/3 Far? <fahree at gmail.com>:

> Is there a permanent link to it? That might be easier and better than
> trying to fit it into the list.
>
> [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics |
> http://fare.tunes.org ]
> There is no such thing as philosophy-free science; there is only science
> whose philosophical baggage is taken on board without examination.
>        -- Daniel Dennett, Darwin's Dangerous Idea
>
>
> 2008/6/2 Robert Virding <rvirding at gmail.com>:
> > Hello all,
> >
> > The presentation is delayed as it is so big it needs approval by the list
> > master. Sorry about that.
> >
> > Robert
> >
> > 2008/6/1 Robert Virding <rvirding at gmail.com>:
> >>
> >> The LFE presentation.
> >>
> >> Robert
> >>
> >
> >
> > _______________________________________________
> > erlang-in-lisp-devel mailing list
> > erlang-in-lisp-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/erlang-in-lisp-devel/attachments/20080603/a45a582c/attachment.html>

From rvirding at gmail.com  Mon Jun  2 22:58:17 2008
From: rvirding at gmail.com (Robert Virding)
Date: Tue, 3 Jun 2008 00:58:17 +0200
Subject: [erlang-in-lisp-devel] A good name for an operator
Message-ID: <3dbc6d1c0806021558x27316a8fgfe51973a9305b283@mail.gmail.com>

This list is probably a good place to ask for help with this:

In LFE (Lisp Flavoured Erlang) I have extended cond with a matching test.
Today you can do

(cond ((match <pat> <expr>) ...)
       ...)

You evaluate the expression and if the result matches the pattern then the
test succeeds and all the variables in the pattern are bound and can be used
in that body. This is easy to implement and suits a pattern matching style
of programming.

The question is what to call the operator? I think using 'match', while
descriptive, is way too general and can easily be expanded by a macro. I had
thought of '=?' which builds on Erlang assignment '=' and a test '?', but
maybe it is too Erlangy. Any suggestions welcome.

Just an small observation: now that I am directly working with lisp and
erlang at the same time is that have pattern matching really affects your
style or programming. I know it is obvious but it still hits you when you
see it.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/erlang-in-lisp-devel/attachments/20080603/67981df7/attachment.html>

From fahree at gmail.com  Wed Jun  4 02:09:57 2008
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Tue, 3 Jun 2008 22:09:57 -0400
Subject: [erlang-in-lisp-devel] fare-match question
In-Reply-To: <3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com>
References: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
	<4842BCB0.5080502@prairienet.org>
	<3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com>
	<3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com>
	<653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com>
	<3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com>
Message-ID: <653bea160806031909p6482fbf1j7059a67f0fd1fc04@mail.gmail.com>

Nice presentation. Thanks a lot!

Silly remarks:
* in CL, bitvectors\ are like that: #*01110111
   http://arti.vub.ac.be/docs/HyperSpec/Body/02_dhd.htm
 I don't know whether they correspond to Erlang binary constants, but
if they do, you may keep the same syntax (or not since CL ones are
actually writeable).
* instead of fletrec you might or not want to use labels. Now your
lisp dialect will by definition be incompatible with any other
dialect, so it probably doesn't matter too much.
* for gensyms that work across upgrade of distributed code, if you're
afraid of collisions, you might consider prepending the gensym'ed
symbol name with the crypto hash of the module code being compiled.

[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Dost thou love life? Then do not squander time, for that's the stuff
life is made of. -- Benjamin Franklin


2008/6/2 Robert Virding <rvirding at gmail.com>:
> OK, there is one now:
>
> http://forum.trapexit.org/viewtopic.php?p=43941#43941
>
> 2008/6/3 Far? <fahree at gmail.com>:
>>
>> Is there a permanent link to it? That might be easier and better than
>> trying to fit it into the list.
>>
>> [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics |
>> http://fare.tunes.org ]
>> There is no such thing as philosophy-free science; there is only science
>> whose philosophical baggage is taken on board without examination.
>>        -- Daniel Dennett, Darwin's Dangerous Idea
>>
>>
>> 2008/6/2 Robert Virding <rvirding at gmail.com>:
>> > Hello all,
>> >
>> > The presentation is delayed as it is so big it needs approval by the
>> > list
>> > master. Sorry about that.
>> >
>> > Robert
>> >
>> > 2008/6/1 Robert Virding <rvirding at gmail.com>:
>> >>
>> >> The LFE presentation.
>> >>
>> >> Robert
>> >>
>> >
>> >
>> > _______________________________________________
>> > erlang-in-lisp-devel mailing list
>> > erlang-in-lisp-devel at common-lisp.net
>> > http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel


From rvirding at gmail.com  Sat Jun  7 22:18:46 2008
From: rvirding at gmail.com (Robert Virding)
Date: Sun, 8 Jun 2008 00:18:46 +0200
Subject: [erlang-in-lisp-devel] fare-match question
In-Reply-To: <653bea160806031909p6482fbf1j7059a67f0fd1fc04@mail.gmail.com>
References: <dfbf29b00805300705r27fa5f29xfa0011e5ef1d8694@mail.gmail.com>
	<4842BCB0.5080502@prairienet.org>
	<3dbc6d1c0806010837k6e2782deje46f3d9b863fa6b0@mail.gmail.com>
	<3dbc6d1c0806021437o718e2d33qa9f67868b0ecf7bb@mail.gmail.com>
	<653bea160806021523o4090358fi7797dd5786782e@mail.gmail.com>
	<3dbc6d1c0806021546n5865f3a7y521e48c2723b7f08@mail.gmail.com>
	<653bea160806031909p6482fbf1j7059a67f0fd1fc04@mail.gmail.com>
Message-ID: <3dbc6d1c0806071518p2ea8165egacbbf34d04738bf5@mail.gmail.com>

2008/6/4 Far? <fahree at gmail.com>:

> Nice presentation. Thanks a lot!


Thank you, thank you.


> Silly remarks:
> * in CL, bitvectors\ are like that: #*01110111
>   http://arti.vub.ac.be/docs/HyperSpec/Body/02_dhd.htm
>  I don't know whether they correspond to Erlang binary constants, but
> if they do, you may keep the same syntax (or not since CL ones are
> actually writeable).


In a sense I think they are the same. The main problem with using the CL
bitvector syntax is that binaries are usually much bigger, sometimes
mega-bytes.


> * instead of fletrec you might or not want to use labels. Now your
> lisp dialect will by definition be incompatible with any other
> dialect, so it probably doesn't matter too much.


I don't like the labels name and I am free to do as I want. :-) At least
until we are more people working on LFE, if that ever occurs.


> * for gensyms that work across upgrade of distributed code, if you're
> afraid of collisions, you might consider prepending the gensym'ed
> symbol name with the crypto hash of the module code being compiled.


That would work, but I don't really know how worried I am about the problem.
It was more a comment on that neither Scheme's hygiene and gensym are really
safe unless you use them as intended. We'll see what the users need.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/erlang-in-lisp-devel/attachments/20080608/0dbf658f/attachment.html>

From wjbitomski at yahoo.com  Tue Jun 10 00:33:49 2008
From: wjbitomski at yahoo.com (Wesley Bitomski)
Date: Mon, 9 Jun 2008 17:33:49 -0700 (PDT)
Subject: [erlang-in-lisp-devel] Hi, I'm here to help
Message-ID: <54401.42069.qm@web30903.mail.mud.yahoo.com>

I'm Wesley and I have experience writing code.  Although my style may not be refined, I'm tenacious. I've read what's going on, so on a macro-level I understand what you're aiming to accomplish.  Since I'm new to your project, I'm hesitant to start acting on my own.  

Is there anything specific that you want me to start working on?  Test cases?  Documentation?  Beating up on a frustrating problem?

Also:
What implementation are each of you running?  I have a machine that runs emacs slime with clisp.  Does this matter, or should I be using something else?

Thanks for having me, I found out about the project through Facebook, and was asked to join this group by Mr. Rideau to start participating.

~Wesley



      


From thatmattbone at gmail.com  Wed Jun 11 00:27:34 2008
From: thatmattbone at gmail.com (Matt Bone)
Date: Tue, 10 Jun 2008 19:27:34 -0500
Subject: [erlang-in-lisp-devel] Hi, I'm here to help
In-Reply-To: <54401.42069.qm@web30903.mail.mud.yahoo.com>
References: <54401.42069.qm@web30903.mail.mud.yahoo.com>
Message-ID: <dfbf29b00806101727w105eb3fhc467b477300c6b2b@mail.gmail.com>

Oops, I forgot to copy the list...

Welcome Wesley!  If you know how things work at a macro-level, you
should be good to go in common lisp (that was a pun).  It'd probably
be too tedious to just work on testing and documentation (but if you
want to, by all means).  I think some larger examples exercising what
we already have could be useful.  Maybe even a hand-coded port of a
simple but cool erlang app?  Or a portion of one?  I'm working on
getting distribution to work at the moment and hoping to write some
test cases myself.  Other than that, I'm open to whatever you'd like
to do.  Fortunately we can paint with a pretty wide brush with git;
if you want to do something drastic, just branch and we can worry
about merging later.  Otherwise just push to the master branch and we
can always fix or roll back if things go awry.

I just put together an attempt at a manual that could be useful in
checking out the code, etc:
http://common-lisp.net/project/erlang-in-lisp/manual/manual.html

As far as implementation, I've been using using sbcl, but I pushed
some changes last night for clisp and everything seems to work.  One
thing I've noticed is that when you fork a new lisp process from
inside of emacs (whether that be sbcl or clisp or whatever else you're
using) things behave differently: in clisp stdout from forked
processes is sent to the REPL as you might expect, but in SBCL this
output is not sent to the REPL (I haven't cared enough to look, but I
assume this is due to how swank/slime is implemented differently for
each).

--matt

On Mon, Jun 9, 2008 at 7:33 PM, Wesley Bitomski <wjbitomski at yahoo.com> wrote:
> I'm Wesley and I have experience writing code.  Although my style may not be refined, I'm tenacious. I've read what's going on, so on a macro-level I understand what you're aiming to accomplish.  Since I'm new to your project, I'm hesitant to start acting on my own.
>
> Is there anything specific that you want me to start working on?  Test cases?  Documentation?  Beating up on a frustrating problem?
>
> Also:
> What implementation are each of you running?  I have a machine that runs emacs slime with clisp.  Does this matter, or should I be using something else?
>
> Thanks for having me, I found out about the project through Facebook, and was asked to join this group by Mr. Rideau to start participating.
>
> ~Wesley
>
>
>
>
> _______________________________________________
> erlang-in-lisp-devel mailing list
> erlang-in-lisp-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
>


From fahree at gmail.com  Wed Jun 11 12:15:40 2008
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Wed, 11 Jun 2008 08:15:40 -0400
Subject: [erlang-in-lisp-devel] Hi, I'm here to help
In-Reply-To: <dfbf29b00806101727w105eb3fhc467b477300c6b2b@mail.gmail.com>
References: <54401.42069.qm@web30903.mail.mud.yahoo.com>
	<dfbf29b00806101727w105eb3fhc467b477300c6b2b@mail.gmail.com>
Message-ID: <653bea160806110515y47a338by39971525b81fea01@mail.gmail.com>

Hi, Matt, Wesley.

Matt: congratulations for your work so far. I think that we should
really have a weekly or bi-weekly discussion by phone/instant
messenger followed by a progress report.

Matt: what do you think is the next step?

As for me, next steps to do would include:
* (hard, important) integration with the iolib event loop -- this
involves teaching the event loop about the many (one to start with)
input (and output) ports that may be open, but also signals and
process-termination events (if available) so that these things may be
monitored in the event loop.
* (hard, important) add some mechanism to handle process links
* (not too hard, not urgent) a portable run-program implementation
that shares E-i-L's process management facility, and could be used to
spawn remote processes, etc.
* (easy, not urgent) better data-structures for pid's (say, a
hash-table to begin with) -- Wesley, maybe you can do that as a
starter?

Matt: as for the spawning, I'm thinking of a syntax more like
(spawn-process function &key name arguments link initial-bindings ...)
allowing for keyword arguments make it easier to add new features in a
compatible way. Here for instance, link would specify whether we use
the equivalent of Erlang's spawn or spawn_link, and initial-bindings
would be used in a progv in the child process.
Be sure to signal an error if an unimplemented feature is used!

[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]
                -- Far?


2008/6/10 Matt Bone <thatmattbone at gmail.com>:
> Oops, I forgot to copy the list...
>
> Welcome Wesley!  If you know how things work at a macro-level, you
> should be good to go in common lisp (that was a pun).  It'd probably
> be too tedious to just work on testing and documentation (but if you
> want to, by all means).  I think some larger examples exercising what
> we already have could be useful.  Maybe even a hand-coded port of a
> simple but cool erlang app?  Or a portion of one?  I'm working on
> getting distribution to work at the moment and hoping to write some
> test cases myself.  Other than that, I'm open to whatever you'd like
> to do.  Fortunately we can paint with a pretty wide brush with git;
> if you want to do something drastic, just branch and we can worry
> about merging later.  Otherwise just push to the master branch and we
> can always fix or roll back if things go awry.
>
> I just put together an attempt at a manual that could be useful in
> checking out the code, etc:
> http://common-lisp.net/project/erlang-in-lisp/manual/manual.html
>
> As far as implementation, I've been using using sbcl, but I pushed
> some changes last night for clisp and everything seems to work.  One
> thing I've noticed is that when you fork a new lisp process from
> inside of emacs (whether that be sbcl or clisp or whatever else you're
> using) things behave differently: in clisp stdout from forked
> processes is sent to the REPL as you might expect, but in SBCL this
> output is not sent to the REPL (I haven't cared enough to look, but I
> assume this is due to how swank/slime is implemented differently for
> each).
>
> --matt
>
> On Mon, Jun 9, 2008 at 7:33 PM, Wesley Bitomski <wjbitomski at yahoo.com> wrote:
>> I'm Wesley and I have experience writing code.  Although my style may not be refined, I'm tenacious. I've read what's going on, so on a macro-level I understand what you're aiming to accomplish.  Since I'm new to your project, I'm hesitant to start acting on my own.
>>
>> Is there anything specific that you want me to start working on?  Test cases?  Documentation?  Beating up on a frustrating problem?
>>
>> Also:
>> What implementation are each of you running?  I have a machine that runs emacs slime with clisp.  Does this matter, or should I be using something else?
>>
>> Thanks for having me, I found out about the project through Facebook, and was asked to join this group by Mr. Rideau to start participating.
>>
>> ~Wesley
>>
>>
>>
>>
>> _______________________________________________
>> erlang-in-lisp-devel mailing list
>> erlang-in-lisp-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
>>
> _______________________________________________
> erlang-in-lisp-devel mailing list
> erlang-in-lisp-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel


From thatmattbone at gmail.com  Wed Jun 11 17:10:48 2008
From: thatmattbone at gmail.com (Matt Bone)
Date: Wed, 11 Jun 2008 12:10:48 -0500
Subject: [erlang-in-lisp-devel] Hi, I'm here to help
In-Reply-To: <653bea160806110515y47a338by39971525b81fea01@mail.gmail.com>
References: <54401.42069.qm@web30903.mail.mud.yahoo.com>
	<dfbf29b00806101727w105eb3fhc467b477300c6b2b@mail.gmail.com>
	<653bea160806110515y47a338by39971525b81fea01@mail.gmail.com>
Message-ID: <dfbf29b00806111010p13102c5by60cceae34a65fe51@mail.gmail.com>

I think working on links would be a good next step.  It's probably one
of the more important parts of having others take the project
seriously.

As far as the event loop, I'm having some trouble understanding where
it fits in.  At the moment, when a process is forked it just creates a
passive port and on a receive does a blocking accept() until a message
shows up.  I don't really see the need for the event loop here since
there is only one thread of execution through each process.  Am I
missing something?  Or is the event loop less about receiving messages
and more about handling other events like the death of linked
processes?

I can see the importance of the event loop when we write our
equivalent of the epmd to get distributed processes working.

--matt



On Wed, Jun 11, 2008 at 7:15 AM, Far? <fahree at gmail.com> wrote:
> Hi, Matt, Wesley.
>
> Matt: congratulations for your work so far. I think that we should
> really have a weekly or bi-weekly discussion by phone/instant
> messenger followed by a progress report.
>
> Matt: what do you think is the next step?
>
> As for me, next steps to do would include:
> * (hard, important) integration with the iolib event loop -- this
> involves teaching the event loop about the many (one to start with)
> input (and output) ports that may be open, but also signals and
> process-termination events (if available) so that these things may be
> monitored in the event loop.
> * (hard, important) add some mechanism to handle process links
> * (not too hard, not urgent) a portable run-program implementation
> that shares E-i-L's process management facility, and could be used to
> spawn remote processes, etc.
> * (easy, not urgent) better data-structures for pid's (say, a
> hash-table to begin with) -- Wesley, maybe you can do that as a
> starter?
>
> Matt: as for the spawning, I'm thinking of a syntax more like
> (spawn-process function &key name arguments link initial-bindings ...)
> allowing for keyword arguments make it easier to add new features in a
> compatible way. Here for instance, link would specify whether we use
> the equivalent of Erlang's spawn or spawn_link, and initial-bindings
> would be used in a progv in the child process.
> Be sure to signal an error if an unimplemented feature is used!
>
> [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]
>                -- Far?
>
>
> 2008/6/10 Matt Bone <thatmattbone at gmail.com>:
>> Oops, I forgot to copy the list...
>>
>> Welcome Wesley!  If you know how things work at a macro-level, you
>> should be good to go in common lisp (that was a pun).  It'd probably
>> be too tedious to just work on testing and documentation (but if you
>> want to, by all means).  I think some larger examples exercising what
>> we already have could be useful.  Maybe even a hand-coded port of a
>> simple but cool erlang app?  Or a portion of one?  I'm working on
>> getting distribution to work at the moment and hoping to write some
>> test cases myself.  Other than that, I'm open to whatever you'd like
>> to do.  Fortunately we can paint with a pretty wide brush with git;
>> if you want to do something drastic, just branch and we can worry
>> about merging later.  Otherwise just push to the master branch and we
>> can always fix or roll back if things go awry.
>>
>> I just put together an attempt at a manual that could be useful in
>> checking out the code, etc:
>> http://common-lisp.net/project/erlang-in-lisp/manual/manual.html
>>
>> As far as implementation, I've been using using sbcl, but I pushed
>> some changes last night for clisp and everything seems to work.  One
>> thing I've noticed is that when you fork a new lisp process from
>> inside of emacs (whether that be sbcl or clisp or whatever else you're
>> using) things behave differently: in clisp stdout from forked
>> processes is sent to the REPL as you might expect, but in SBCL this
>> output is not sent to the REPL (I haven't cared enough to look, but I
>> assume this is due to how swank/slime is implemented differently for
>> each).
>>
>> --matt
>>
>> On Mon, Jun 9, 2008 at 7:33 PM, Wesley Bitomski <wjbitomski at yahoo.com> wrote:
>>> I'm Wesley and I have experience writing code.  Although my style may not be refined, I'm tenacious. I've read what's going on, so on a macro-level I understand what you're aiming to accomplish.  Since I'm new to your project, I'm hesitant to start acting on my own.
>>>
>>> Is there anything specific that you want me to start working on?  Test cases?  Documentation?  Beating up on a frustrating problem?
>>>
>>> Also:
>>> What implementation are each of you running?  I have a machine that runs emacs slime with clisp.  Does this matter, or should I be using something else?
>>>
>>> Thanks for having me, I found out about the project through Facebook, and was asked to join this group by Mr. Rideau to start participating.
>>>
>>> ~Wesley
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-in-lisp-devel mailing list
>>> erlang-in-lisp-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
>>>
>> _______________________________________________
>> erlang-in-lisp-devel mailing list
>> erlang-in-lisp-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
> _______________________________________________
> erlang-in-lisp-devel mailing list
> erlang-in-lisp-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/erlang-in-lisp-devel
>


From fahree at gmail.com  Wed Jun 11 23:07:26 2008
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Wed, 11 Jun 2008 19:07:26 -0400
Subject: [erlang-in-lisp-devel] Hi, I'm here to help
In-Reply-To: <dfbf29b00806111010p13102c5by60cceae34a65fe51@mail.gmail.com>
References: <54401.42069.qm@web30903.mail.mud.yahoo.com>
	<dfbf29b00806101727w105eb3fhc467b477300c6b2b@mail.gmail.com>
	<653bea160806110515y47a338by39971525b81fea01@mail.gmail.com>
	<dfbf29b00806111010p13102c5by60cceae34a65fe51@mail.gmail.com>
Message-ID: <653bea160806111607s10289db4s5ab42fc38dc2a068@mail.gmail.com>

Dear Matt,

yes, the event loop is important whenever you need to do I/O with more
than one source of data. Any time you have a process that needs to
listen to both local Erlang messages and anything else (be it remote
Erlang messages via TCP/IP, HTTP clients, an audio stream, a
compression/decompression process, signals of processes going up or
down, etc.) Spawning one subprocess per data source that converts
everything into Erlang messages is certainly possible, but quite
expensive. Sooner or later, we'll need some generic mechanism to
generate language-level events (messages being queued/processed) from
many sources - if only indeed so as to manage trees of linked
processes. The event loop will also become essential when we implement
a green thread model of execution. It needs not be the next step. But
certainly something to do before the end of the summer.

Wesley: are you a taker for putting processes in a hash-table? For
hacking on run-program?

[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The competitor to be feared is one who never bothers about you at all,
but goes on making his own business better all the time. -- Henry Ford


2008/6/11 Matt Bone <thatmattbone at gmail.com>:
> I think working on links would be a good next step.  It's probably one
> of the more important parts of having others take the project
> seriously.
>
> As far as the event loop, I'm having some trouble understanding where
> it fits in.  At the moment, when a process is forked it just creates a
> passive port and on a receive does a blocking accept() until a message
> shows up.  I don't really see the need for the event loop here since
> there is only one thread of execution through each process.  Am I
> missing something?  Or is the event loop less about receiving messages
> and more about handling other events like the death of linked
> processes?
>
> I can see the importance of the event loop when we write our
> equivalent of the epmd to get distributed processes working.
>
> --matt
>
>
>
> On Wed, Jun 11, 2008 at 7:15 AM, Far? <fahree at gmail.com> wrote:
>> Hi, Matt, Wesley.
>>
>> Matt: congratulations for your work so far. I think that we should
>> really have a weekly or bi-weekly discussion by phone/instant
>> messenger followed by a progress report.
>>
>> Matt: what do you think is the next step?
>>
>> As for me, next steps to do would include:
>> * (hard, important) integration with the iolib event loop -- this
>> involves teaching the event loop about the many (one to start with)
>> input (and output) ports that may be open, but also signals and
>> process-termination events (if available) so that these things may be
>> monitored in the event loop.
>> * (hard, important) add some mechanism to handle process links
>> * (not too hard, not urgent) a portable run-program implementation
>> that shares E-i-L's process management facility, and could be used to
>> spawn remote processes, etc.
>> * (easy, not urgent) better data-structures for pid's (say, a
>> hash-table to begin with) -- Wesley, maybe you can do that as a
>> starter?
>>
>> Matt: as for the spawning, I'm thinking of a syntax more like
>> (spawn-process function &key name arguments link initial-bindings ...)
>> allowing for keyword arguments make it easier to add new features in a
>> compatible way. Here for instance, link would specify whether we use
>> the equivalent of Erlang's spawn or spawn_link, and initial-bindings
>> would be used in a progv in the child process.
>> Be sure to signal an error if an unimplemented feature is used!
>>
>> [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
>> Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]
>>                -- Far?
>>
>>
>> 2008/6/10 Matt Bone <thatmattbone at gmail.com>:
>>> Oops, I forgot to copy the list...
>>>
>>> Welcome Wesley!  If you know how things work at a macro-level, you
>>> should be good to go in common lisp (that was a pun).  It'd probably
>>> be too tedious to just work on testing and documentation (but if you
>>> want to, by all means).  I think some larger examples exercising what
>>> we already have could be useful.  Maybe even a hand-coded port of a
>>> simple but cool erlang app?  Or a portion of one?  I'm working on
>>> getting distribution to work at the moment and hoping to write some
>>> test cases myself.  Other than that, I'm open to whatever you'd like
>>> to do.  Fortunately we can paint with a pretty wide brush with git;
>>> if you want to do something drastic, just branch and we can worry
>>> about merging later.  Otherwise just push to the master branch and we
>>> can always fix or roll back if things go awry.
>>>
>>> I just put together an attempt at a manual that could be useful in
>>> checking out the code, etc:
>>> http://common-lisp.net/project/erlang-in-lisp/manual/manual.html
>>>
>>> As far as implementation, I've been using using sbcl, but I pushed
>>> some changes last night for clisp and everything seems to work.  One
>>> thing I've noticed is that when you fork a new lisp process from
>>> inside of emacs (whether that be sbcl or clisp or whatever else you're
>>> using) things behave differently: in clisp stdout from forked
>>> processes is sent to the REPL as you might expect, but in SBCL this
>>> output is not sent to the REPL (I haven't cared enough to look, but I
>>> assume this is due to how swank/slime is implemented differently for
>>> each).
>>>
>>> --matt
>>>
>>> On Mon, Jun 9, 2008 at 7:33 PM, Wesley Bitomski <wjbitomski at yahoo.com> wrote:
>>>> I'm Wesley and I have experience writing code.  Although my style may not be refined, I'm tenacious. I've read what's going on, so on a macro-level I understand what you're aiming to accomplish.  Since I'm new to your project, I'm hesitant to start acting on my own.
>>>>
>>>> Is there anything specific that you want me to start working on?  Test cases?  Documentation?  Beating up on a frustrating problem?
>>>>
>>>> Also:
>>>> What implementation are each of you running?  I have a machine that runs emacs slime with clisp.  Does this matter, or should I be using something else?
>>>>
>>>> Thanks for having me, I found out about the project through Facebook, and was asked to join this group by Mr. Rideau to start participating.
>>>>
>>>> ~Wesley