running reia shell in emacs?
Roman.Shestakov
did anybody try to run reia shell from emacs?
I am getting this error while executing ire in emacs shell process:
bash-3.2$ ire
Reia Interactive Shell (prerelease)
Running on
=ERROR REPORT==== 11-Feb-2009::23:46:08 ===
Error in process <0.27.0> with exit value: {badarg,[{erlang,register,
[user,<0.28.0>]},{user,start_port,1}]}
as running ire:start(). from erlang shell works fine, I presume it
might be a problem with executing this:
user_drv:start('tty_sl -c -e', {ire, start, []}).
did some digging and looks like lfe shell has the same problem:
( according to this thread: http://erlang.org/pipermail/erlang-questions/2008-December/040571.html)
running ire from outside emacs in bash works fine as well.
any ideas how to fix this? I'd really like to get my emacs working
with reia
Regards, Roman
Tony Arcieri
I am getting this error while executing ire in emacs shell process:
bash-3.2$ ire
Reia Interactive Shell (prerelease)
Running on
=ERROR REPORT==== 11-Feb-2009::23:46:08 ===
Error in process <0.27.0> with exit value: {badarg,[{erlang,register,
[user,<0.28.0>]},{user,start_port,1}]}
as running ire:start(). from erlang shell works fine, I presume it
might be a problem with executing this:
user_drv:start('tty_sl -c -e', {ire, start, []}).
I'm not sure how to bootstrap the shell with Emacs itself as a line editor. The edlin module is meant to be a poor man's Emacs.
Perhaps the Erlang emacs bindings or distel provide a clue as to how to use Emacs in as or in conjunction with an Erlang io server.
--
Tony Arcieri
Tony Arcieri
Hi, Tony!
Want to know your opinion concerning blocks.
Are they meant to be just a syntactic sugar to passing a lambda as an argument? i.e. is
o.f(2) {|x| x*3} the same as
o.f(2, fun(x) {x*3})
Blocks are intended to be syntactic sugar, however I'd like to preserve the Ruby's disintermediating of blocks from other arguments.
In your first example, it's an arity 1 function with a block. In the second, it's an arity 2 function (no block)
The syntax for making the second example identical to the first (i.e. pass a lambda as a block) would be:
o.f(2, &fun(x) {x*3})
Will f/arity be the same in both cases:
def f(a, &b)
def f(a, b)
?
Nope, the first is an arity 1 function passing b (presumably a lambda) as a block, and the second is arity 2.
Since lamdas work perfectly fine, i can hurl my effort to tune the syntax to allow blocks
Blocks are definitely the feature I'd like to work on next, although presently I'm working on string interpolation, i.e. "foo: #{foo}, bar: #{bar}, baz: #{baz}"
They're going to be a bit tricky as this will be the start of Reia moving away from Erlang's call path towards its own. I was thinking the new call path would look a little something like this in Erlang:
func({Arg1, Arg2, Arg3}, Block) -> ...
This opens the door to other nifty features with arguments like "splats", which let you capture one or more arguments in a list, e.g.
def foo(*bar)
becomes: (in pseudo-Erlang)
foo(Args, _Block) ->
Bar = tuple_to_list(Args),
...
I did a poll of Rubyists to see what their favorite features of the language are, and blocks were unsurprisingly #1:
http://www.twiigs.com/poll/Technology/Computers/25588
Let's talk some more and maybe we can figure out a plan for working on them together.
--
Tony Arcieri
medioh.com
Phil Pirozhkov
I've hacked Reia to allow blocks, added some tests, but Block is just a last Argument in my implementation (arity
gets +1):
module BlockTest
def function_taking_block(a, &b)
a + b(a)
BlockTest.function_taking_block(2, fun(x){x*2}) # 6
Lists funcall dispatch have been fixed to pass a block as a lambda argument:
[1, 2, 3].map {|x| x*2} # [2,4,6]
And this snowball touched reia_class.erl and reia.erl a bit, too.
Pull from github.com/pirj/reia if there's any interest.
It's really messy in reia_parser.yrl, but i suggest this can be simplified a bit.
The're one more major thing i'm concerned, lambda context, i.e. will lambda ever see the caller's bindings?
It may confuse and wonder why this is required at all, but i felt this will be vital required to write readable RSpec-
like tests:
Behave.context('A User instance') do
user = User.find(~first)
should('return its full name') do
assert('John Doe' == user.full_name)
should('return its email address') do
assert('Joh...@gmail.com' == user.email)
Here, a user is fetched only once, and used multiple times.
'user' is used inside 'should's passed lambda
Syntax looks not bad when there's only one var:
should('return its full name', user) do |user|
assert('John Doe' == user.full_name)
but when there's more it's getting really messy:
should('return its full name', user1, user2) do |user1, user2|
assert(user1.surname == user2.surname)
Phil
Cheers, Phil
Phil Pirozhkov
Phil
>
Cheers, Phil
Tony Arcieri
It's a pity!
I've hacked Reia to allow blocks, added some tests, but Block is just a last Argument in my implementation (arity
gets +1):
This could sort of work with the present Erlangy approach to arity handling (i.e. functions of different arities are considered distinct)
And by work, I mean: you can have the same function take a block, or not. If it takes a block it'd just have a higher arity (by 1)
For example, I'd like to add something ala Ruby where if methods like map are invoked without a block they return an enumerator. If you give them a block, they'd perform their present behavior.
As soon as you try to add splats, default values, or keyword arguments though, this whole approach is going to cease to work.
And this snowball touched reia_class.erl and reia.erl a bit, too.
Pull from github.com/pirj/reia if there's any interest.
It's really messy in reia_parser.yrl, but i suggest this can be simplified a bit.
What did you change in the parser?
In the future you might want to push a remote branch for this sort of thing (i.e. experimental changes you'd like other people to check out) so you can keep your master clean for me to pull from if you have changes ready to be merged into my repo. And if I like your experiment, I can pull from your experimental branch.
The're one more major thing i'm concerned, lambda context, i.e. will lambda ever see the caller's bindings?
Lambdas close over the environment they're declared in, not the caller's environment.
Syntax looks not bad when there's only one var:
should('return its full name', user) do |user|
assert('John Doe' == user.full_name)
but when there's more it's getting really messy:
should('return its full name', user1, user2) do |user1, user2|
assert(user1.surname == user2.surname)
This isn't necessary. These variables will be available in the scope of the block. Passing them as argument to the block merely shadows the existing declarations.
Here you aren't the caller... instead you're declaring the block which will close over the outer scope where user/user1/user2 are defined.
The block will be called elsewhere (by the spec runner)
--
Tony Arcieri
medioh.com
Phil Pirozhkov
> > I've hacked Reia to allow blocks, added some tests, but Block is just a
> > last Argument in my implementation (arity
> > gets +1):
> As soon as you try to add splats, default values, or keyword arguments
> though, this whole approach is going to cease to work.
No doubt
> What did you change in the parser?
http://github.com/pirj/reia/commit/8978db10ace33189ba0604568a5a74ebc79042ce#diff-0
initial support for "&" terminal
http://github.com/pirj/reia/commit/60f7512cd342e93ef9773be7c0197eab87c29027#diff-0
Top half takes care of
def f(a, &b) declaration, supporting "&" symbol
Code is messy here, i haven't found a way to get rid of fexprs
Bottom part adds block as lambda to Argument list (thing i shouldn't do)
> In the future you might want to push a remote branch for this sort of thing
> (i.e. experimental changes you'd like other people to check out) so you can
> keep your master clean for me to pull from if you have changes ready to be
> merged into my repo. And if I like your experiment, I can pull from your
> experimental branch.
Sounds good.
> Tony Arcieri
Phil Pirozhkov
> > What did you change in the parser?
http://github.com/pirj/reia/commit/458f428a98858b5e4cf75b004fd01fd0caa41d15
Branch is here:
http://github.com/pirj/reia/tree/bad_block
> http://github.com/pirj/reia/commit/8978db10ace33189ba0604568a5a74ebc79042ce#diff-0
> initial support for "&" terminal
>
> http://github.com/pirj/reia/commit/60f7512cd342e93ef9773be7c0197eab87c29027#diff-0
> Top half takes care of
> def f(a, &b) declaration, supporting "&" symbol
> Code is messy here, i haven't found a way to get rid of fexprs
>
>
> Bottom part adds block as lambda to Argument list (thing i shouldn't do)
>
> > In the future you might want to push a remote branch for this sort of thing
> > (i.e. experimental changes you'd like other people to check out) so you can
> > keep your master clean for me to pull from if you have changes ready to be
> > merged into my repo. And if I like your experiment, I can pull from your
> > experimental branch.
> Sounds good.
>
> > Tony Arcieri
>
>
> >