[erlang-questions] suggestion: shorthand functions

[Garrett Smith]

On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen
<raimo+erlang-questions@REDACTED> wrote:
> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote:
>> Since I've been writing a bunch of rebar.config.script code lately,
>> I've suffered the agony of trying to write concise and readable
>> code without having to do tons of copy-paste, weird unwrapping
>> funs etc.
>>
>> What I think would make this sort of thing easier, and also
>> escript programming in general, is if OTP could provide some
>> modules with concise naming and let-it-fail semantics.
>>
>> Just off the top of my head, I scribbled down a few functions that
>> I think would make *my* life easier. I pushed them to github to
>> get some discussion going.
>>
>> http://github.com/uwiger/shorthand
>>
>> The modules are:
>>
>> f.erl - shorthand functions for file.erl
>> fn.erl - ditto for filename.erl
>> e.erl - ditto for erl_eval.erl
>>
>> The least beneficial is perhaps filename:erl, but my fingers and
>> eyes ache from all the filename:join(filename:dirname(F), …)
>> code.
>>
>> Otherwise, I think the biggest benefit is to stick to let-it-crash
>> programming, which I find is usually the default when I write
>> scripts. The original functions are always available if you want
>> to take a closer look at return values.
>>
>> (For the file:script() counterparts, I also always pass the name
>> of the script as a binding).
>>
>> Comments?
>
> I think it is a nice idea that would improve scripting.
>
> But how to agree on module names and content is harder. There is a limited
> number of 1 and 2 character module names, and once in OTP they are written
> in stone.

Aye. I don't know how critical this use case is (scripting
simplification/improvements) to justify new modules in OTP space. And
I'm not sure there *is* a case that would be sufficiently ubiquitous.

I've resigned myself to writing little project specific
functions/libraries like this to deal with project specific problems.
E.g. this stuff drives me nuts:

{ok, X} = foo:x(),
{ok, Y} = foo:y(),
combine(X, Y)
...

So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get this:

combine(foo_x(), foo_y())

But who knew that I needed those particular variants? And what about
changes? It's my project, so I don't mind little wrappers, especially
since functions clarify intent.

E.g. when I see this:

ProjectFile = filename:join(ProjectDir, ProjectName)

I'll almost create a function like this:

project_filename(Dir, Name) -> filename:join(Dir, Name).

> For f.erl I miss e.g is_dir from filelib, which would introduce the notion
> of merging old module functionality. Using the name 'fl' for filelib
> functions would just be hard to remember.
>
> Aliasing filename:basename to fn:base is a bit unintuitive since the
> original Unix command is called 'basename' and for e.g file:list_dir
> you have aliased it to f:ls (as for many other) to make them more Unix:ish.
> I think it would be better to keep to unix command names where possible.
> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).]

It seems one could make these arguments ad nauseam. To me it's just
easier (and preferable frankly) to roll my own as the need arises.

> An alternative approach might be to have a helper module named 'es'
> containing all scripting aliases...

I love escripts but find myself intuitively avoiding them for a couple reasons:

- In most cases, bash is more portable and solves system level
problems more directly

- I don't have the escript foo required to wrench my program it into a
single script file

Setting bash aside (not Ulf's use case) the main barrier for me is in
the perceived complexity of getting a release-of-sorts into an
escript. If I could write up one of these wrapper libraries, or pull
it down from somewhere easily, I might use escript everywhere. It's
not hard to write the wrappers (you write them as you need them, it
takes literally less than a minute for each function) and they're
tailored to your requirements.

It may be trivial to package up the required bytes into an escript
today. If it is, I've love to know!

And I don't know how this fits into rebar specific scripting :)

Garrett