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

[Bob Ippolito]

Output filters sound really useful, I missed the message because I was
traveling :)

-bob

On 11/13/07, Roberto Saccon <rsaccon@REDACTED> wrote:
> Ulf, that is great stuff ! Most of all I liked the idea of plugging in
> an X-to-Erlang parser. I have a real use case for that (I am writing a
> Javascript to Erlang Parser)
>
> regards
>
> On Nov 13, 2007 1:52 PM, Ulf Wiger <ulf@REDACTED> wrote:
> > No one commented on my output filters for the shell.
> > Oh well, perhaps it wasn't weird enough... (:
> > 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
> >
>
>
>
> --
> Roberto Saccon
> http://rsaccon.com
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>