[erlang-questions] idea: ml9 (sort of) in the erlang shell

[Jan Henry Nystrom]

Ulf Wiger wrote:
> No one commented on my output filters for the shell.
> Oh well, perhaps it wasn't weird enough... (:
Now I loved the output filter idea, but did not really
have the time to say so. But here I am not so sure.
The syntax is, at least to me far from obvious, and
I have not felt the shell especially constricting.
When I have had to do something more exotic that really
got too complicated for the shell, it has always paid
of to write a module. That is since I generally  have
had use of the very same technique again. But since
it do not break any existing stuff, fine. But whatever
you do, do not get into the general syntax or I will
have to learn to read your code :-)

/Cheers Henry


> Personally, I love them. Working with dicts in the shell has
> become much more pleasant.
> 
> Here's a more outlandish idea:
> 
> Allow for arbitrary syntax to be inserted in the shell, by
> catching lines starting with '@' (only because this is what
> Joe used in his ML9).
> 
> Here's an example:
> 
> Eshell V5.5.4  (abort with ^G)
> 1> @ syntax(erlang),import(X,Y).
> -module(a).
> -define(X,x).
> 
> f() -> ?X.
> 
> @
> Env = [{call,1,{atom,1,syntax},[{atom,1,erlang}]},
>        {call,1,{atom,1,import},[{var,1,'X'},{var,1,'Y'}]}]
> String = "-module(a).\n-define(X,x).\n\nf() -> ?X.\n\n"
> 
> (This was as far as I have come. The shell only prints out
> what it collected.)
> 
> If a '@' is entered (with an optional sequence of erlang
> expressions describing what will follow, terminated by
> a period), the shell will just collect whatever text follows,
> and return this, instead of calling erl_parse:parse_erl_exprs().
> 
> My initial thought was that the default behaviour would be
> to preprocess String, accepting macro definitions etc, and
> then expanding macros in the source. This would be configurable
> in the environment:
> 
> 2> @ pp(false).
> L = [a,b,c].
> lists:reverse(L).
> @
> [c,b,a]
> 3>
> 
> Eventually, this might evolve into accepting a module declaration,
> but that would require first deciding what to do with the module,
> once parsed. Compile to binary and then load it?
> 
> A few ideas about what could be done with this:
> 
> - by default, no variables would be imported, but selective
>   import might be possible:
> 
> 4> L = [1,2,3].
> 5> @ import(L).
> lists:reverse(L)
> @
> [3,2,1]
> 
> - It would be easy to also declare which variables to remember,
>   export(X,Y,Z).
> 
> - An obvious use of this would be to make it easier to deal with multi-
>   line expressions in the shell. Ever had to copy a multi-line expression
>   *from* the shell, and having to edit away all the garbage?
> 
> - QuickCheck uses macros a lot. This could offer a way to use
>   QuickCheck with the useful macros from within the shell.
>   (Mats Cronqvist already wrote a preprocessor that pretty much
>   works for this purpose.)
> 
> - There are a few X-to-Erlang parsers (scheme, haskell, ...) that could
>   be plugged in and used with this. Plug in your own parser.
>   (Should it be possible to import/export variables...? Why not?)
> 
> I'd have to write some more code to make it reasonably useful,
> but not too much. It won't break any of the existing stuff. (:
> 
> Thoughts, flames?
> 
> BR,
> Ulf W
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions


-- 
Jan Henry Nystrom <jan@REDACTED>
Training & Research Manager @ Erlang Training and Consulting Ltd
http://www.erlang-consulting.com