Some ideas for the shell.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Some ideas for the shell.

Richard A. O'Keefe-2
There are two things that would make life easier for me using the
Erlang shell, and I thought I'd ask for thoughts here before writing
them up as EEPs.

(1) import(Module, Functions)
     where Functions is a list of {Name,Arity} pairs.
     Effect: calls to that function from the shell don't need a
     Module prefix, just like -import directives in files.

     Reason: I often want to call a function or a small number of
     functions many times to explore it or test it.

(2) include(FileName)
     Effect: reads FileName as a sequence of Erlang expressions and
     interprets them as if typed into the same shell.

     Reason: set up constants and imports.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

bengt e
Greetings,

Is 2) similar enough to file:consult/1, to maybe warrant it to be called 'consult' instead?

bengt

On Mon, Dec 4, 2017 at 1:09 AM, Richard A. O'Keefe <[hidden email]> wrote:
There are two things that would make life easier for me using the
Erlang shell, and I thought I'd ask for thoughts here before writing
them up as EEPs.

(1) import(Module, Functions)
    where Functions is a list of {Name,Arity} pairs.
    Effect: calls to that function from the shell don't need a
    Module prefix, just like -import directives in files.

    Reason: I often want to call a function or a small number of
    functions many times to explore it or test it.

(2) include(FileName)
    Effect: reads FileName as a sequence of Erlang expressions and
    interprets them as if typed into the same shell.

    Reason: set up constants and imports.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Pierre Fenoll-2
On the REPL enhancements wishlist train, I have opened an issue on the bug tracker a while ago to add tab completion for variable names. 
One of the comments on it was asking for documentation access too, as the Python REPL has been offering for some time. 

Since some things may be undesirable on production REPLs, maybe a flag that can be set from a rebar3 profile can help toggle some features thus allowing more enhancements for dev REPLs. 

On Mon 4 Dec 2017 at 08:22, bengt e <[hidden email]> wrote:
Greetings,

Is 2) similar enough to file:consult/1, to maybe warrant it to be called 'consult' instead?

bengt

On Mon, Dec 4, 2017 at 1:09 AM, Richard A. O'Keefe <[hidden email]> wrote:
There are two things that would make life easier for me using the
Erlang shell, and I thought I'd ask for thoughts here before writing
them up as EEPs.

(1) import(Module, Functions)
    where Functions is a list of {Name,Arity} pairs.
    Effect: calls to that function from the shell don't need a
    Module prefix, just like -import directives in files.

    Reason: I often want to call a function or a small number of
    functions many times to explore it or test it.

(2) include(FileName)
    Effect: reads FileName as a sequence of Erlang expressions and
    interprets them as if typed into the same shell.

    Reason: set up constants and imports.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--

Cheers,
-- 
Pierre Fenoll


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Vance Shipley
On Mon, Dec 4, 2017 at 4:18 PM, Pierre Fenoll <[hidden email]> wrote:
> Since some things may be undesirable on production REPLs, maybe a flag that
> can be set from a rebar3 profile can help toggle some features thus allowing
> more enhancements for dev REPLs.

A little known feature is the Restricted Shell:
http://erlang.org/doc/man/shell#id262296
which allows you to tailor what can and cannot be run from the shell.

The shell_default is also handy as it allows you to create your own
short form commands (no module name):
http://erlang.org/doc/man/shell_default.html

Create an erl alias which add the '+Bi' argument and you can have a
quasi-safe REPL for non-programmer operators.


--
     -Vance
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Radosław Szymczyszyn
In reply to this post by Pierre Fenoll-2
> One of the comments on it was asking for documentation access too, as the Python REPL has been offering for some time.

"Some time" like, hmmm, almost 20 years? ;) There's a PEP on docstring
conventions from 2001 [1]. I assume that docstrings as a language
feature predate the conventions PEP, but I don't really know when they
had been introduced.

[1]: https://www.python.org/dev/peps/pep-0257/

Anyway, I've authored a shell documentation access tool for erl, which
currently is "good enough" for my daily use:

https://github.com/erszcz/docsh

It provides EDoc docs, function specs, and type definitions with
one-letter helper functions. It can be installed directly with an
install.sh or with kerl which now has an 'install-docsh' subcommand.
The cost is sacrificing one's own user_default.erl and $HOME/.erlang
customizations (or, if one really wants to, doing some work on merging
the stuff required by docsh with personal modifications - and there's
documentation telling exactly what needs to be done).
The caveat is that it doesn't (yet) work with Erlang 20 due to new
Abst chunk format. Alas, my time is finite, and I'm working on this
thing outside my job.

2017-12-04 11:48 GMT+01:00 Pierre Fenoll <[hidden email]>:

> On the REPL enhancements wishlist train, I have opened an issue on the bug
> tracker a while ago to add tab completion for variable names.
> One of the comments on it was asking for documentation access too, as the
> Python REPL has been offering for some time.
>
> Since some things may be undesirable on production REPLs, maybe a flag that
> can be set from a rebar3 profile can help toggle some features thus allowing
> more enhancements for dev REPLs.
>
> On Mon 4 Dec 2017 at 08:22, bengt e <[hidden email]> wrote:
>>
>> Greetings,
>>
>> Is 2) similar enough to file:consult/1, to maybe warrant it to be called
>> 'consult' instead?
>>
>> bengt
>>
>> On Mon, Dec 4, 2017 at 1:09 AM, Richard A. O'Keefe <[hidden email]>
>> wrote:
>>>
>>> There are two things that would make life easier for me using the
>>> Erlang shell, and I thought I'd ask for thoughts here before writing
>>> them up as EEPs.
>>>
>>> (1) import(Module, Functions)
>>>     where Functions is a list of {Name,Arity} pairs.
>>>     Effect: calls to that function from the shell don't need a
>>>     Module prefix, just like -import directives in files.
>>>
>>>     Reason: I often want to call a function or a small number of
>>>     functions many times to explore it or test it.
>>>
>>> (2) include(FileName)
>>>     Effect: reads FileName as a sequence of Erlang expressions and
>>>     interprets them as if typed into the same shell.
>>>
>>>     Reason: set up constants and imports.
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> --
>
> Cheers,
> --
> Pierre Fenoll
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Fred Hebert-2
I've toyed with the shell a whole lot over the years -- implemented history storage (twice) and the ctrl+r search in there, along with the stuff related to rebar3's shell. The useful information I could give to people willing to spend the time to develop these things is in a blog post I've written a few years ago: https://ferd.ca/repl-a-bit-more-and-less-than-that.html

The structure is not necessarily quite obvious for the tricky requirements of say, capturing input on one node, but evaluating it in the context of another one (except for some signals like ctrl+g, which are evaluated locally). If anyone feels like hacking on the shell, this could be decent preliminary reading.

On Mon, Dec 4, 2017 at 7:58 AM, Radosław Szymczyszyn <[hidden email]> wrote:
> One of the comments on it was asking for documentation access too, as the Python REPL has been offering for some time.

"Some time" like, hmmm, almost 20 years? ;) There's a PEP on docstring
conventions from 2001 [1]. I assume that docstrings as a language
feature predate the conventions PEP, but I don't really know when they
had been introduced.

[1]: https://www.python.org/dev/peps/pep-0257/

Anyway, I've authored a shell documentation access tool for erl, which
currently is "good enough" for my daily use:

https://github.com/erszcz/docsh

It provides EDoc docs, function specs, and type definitions with
one-letter helper functions. It can be installed directly with an
install.sh or with kerl which now has an 'install-docsh' subcommand.
The cost is sacrificing one's own user_default.erl and $HOME/.erlang
customizations (or, if one really wants to, doing some work on merging
the stuff required by docsh with personal modifications - and there's
documentation telling exactly what needs to be done).
The caveat is that it doesn't (yet) work with Erlang 20 due to new
Abst chunk format. Alas, my time is finite, and I'm working on this
thing outside my job.

2017-12-04 11:48 GMT+01:00 Pierre Fenoll <[hidden email]>:
> On the REPL enhancements wishlist train, I have opened an issue on the bug
> tracker a while ago to add tab completion for variable names.
> One of the comments on it was asking for documentation access too, as the
> Python REPL has been offering for some time.
>
> Since some things may be undesirable on production REPLs, maybe a flag that
> can be set from a rebar3 profile can help toggle some features thus allowing
> more enhancements for dev REPLs.
>
> On Mon 4 Dec 2017 at 08:22, bengt e <[hidden email]> wrote:
>>
>> Greetings,
>>
>> Is 2) similar enough to file:consult/1, to maybe warrant it to be called
>> 'consult' instead?
>>
>> bengt
>>
>> On Mon, Dec 4, 2017 at 1:09 AM, Richard A. O'Keefe <[hidden email]>
>> wrote:
>>>
>>> There are two things that would make life easier for me using the
>>> Erlang shell, and I thought I'd ask for thoughts here before writing
>>> them up as EEPs.
>>>
>>> (1) import(Module, Functions)
>>>     where Functions is a list of {Name,Arity} pairs.
>>>     Effect: calls to that function from the shell don't need a
>>>     Module prefix, just like -import directives in files.
>>>
>>>     Reason: I often want to call a function or a small number of
>>>     functions many times to explore it or test it.
>>>
>>> (2) include(FileName)
>>>     Effect: reads FileName as a sequence of Erlang expressions and
>>>     interprets them as if typed into the same shell.
>>>
>>>     Reason: set up constants and imports.
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> --
>
> Cheers,
> --
> Pierre Fenoll
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Richard A. O'Keefe-2
In reply to this post by bengt e


On 4/12/17 8:21 PM, bengt e wrote:
> Greetings,
>
> Is 2) similar enough to file:consult/1, to maybe warrant it to be called
> 'consult' instead?

file:consult/1 reads a file and (all going well) *returns a list of the
terms* but does not process them.  This isn't all _that_ much like what
(shell):include/1 is supposed to do.  import(...) was designed to mimic
the -import directive and include(...) was designed to mimic the
-include directive.

I was actually thinking of it as analogous to the
'source <filename>' command in dbx, but using a name
already familiar to Erlang programmers.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Richard Carlsson-3
You also have file:eval/1 and file:script/1. (And "path_..." versions of the same.)


        /Richard

2017-12-05 4:51 GMT+01:00 Richard A. O'Keefe <[hidden email]>:


On 4/12/17 8:21 PM, bengt e wrote:
Greetings,

Is 2) similar enough to file:consult/1, to maybe warrant it to be called
'consult' instead?

file:consult/1 reads a file and (all going well) *returns a list of the
terms* but does not process them.  This isn't all _that_ much like what
(shell):include/1 is supposed to do.  import(...) was designed to mimic
the -import directive and include(...) was designed to mimic the
-include directive.

I was actually thinking of it as analogous to the
'source <filename>' command in dbx, but using a name
already familiar to Erlang programmers.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Richard A. O'Keefe-2


On 6/12/17 1:59 AM, Richard Carlsson wrote:
> You also have file:eval/1 and file:script/1. (And "path_..." versions of
> the same.)

Yes, but file:eval/1 does something *DIFFERENT* from what
the shell command include/1 would.  And so does file:/script/1.
There is much overlap, but they are not the same.
If the argument is to use one of those functions, that won't fly.
If the argument is to use the *name* eval/1 or script/1 in the
shell for what I want include/1 to do, yeah, sure, why not?

You see, the thing is that include/1 is supposed to read a sequence
of full-stop-terminated forms from the named file, and process them
*as shell commands*, some of which are normal Erlang expressions,
and some of which are *not*.  I mean, I did know about file:eval/1
(but admittedly not file:script/1) and there's a reason I wanted
something else...

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Some ideas for the shell.

Richard Carlsson-3
Apparently, path_eval/1 is also what Erlang ends up using to execute your ~/.erlang file if you have one (via the undocumented c:erlangrc/0). There doesn't seem to be a way to run a script in the context of the shell.


        /Richard

2017-12-07 2:23 GMT+01:00 Richard A. O'Keefe <[hidden email]>:


On 6/12/17 1:59 AM, Richard Carlsson wrote:
You also have file:eval/1 and file:script/1. (And "path_..." versions of
the same.)

Yes, but file:eval/1 does something *DIFFERENT* from what
the shell command include/1 would.  And so does file:/script/1.
There is much overlap, but they are not the same.
If the argument is to use one of those functions, that won't fly.
If the argument is to use the *name* eval/1 or script/1 in the
shell for what I want include/1 to do, yeah, sure, why not?

You see, the thing is that include/1 is supposed to read a sequence
of full-stop-terminated forms from the named file, and process them
*as shell commands*, some of which are normal Erlang expressions,
and some of which are *not*.  I mean, I did know about file:eval/1
(but admittedly not file:script/1) and there's a reason I wanted
something else...



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions