[erlang-questions] Funargs: Ruby-like blocks for Erlang
Richard O'Keefe
ok@REDACTED
Fri Jul 22 01:11:45 CEST 2011
On 22/07/2011, at 12:34 AM, Jesper Louis Andersen wrote:
> TL;DR I don't think we need a new kind of syntax for certain kinds of
> lambda sections (see the 'cut' proposal a couple of days ago from
> SRFI-26 in Scheme-land). But I do agree the notation is heavier than
> it could be. A more convenient notation would encourage people to use
> anonymous functions more.
The whole of Erlang syntax is "heavier" than it might be.
I once devised a revised syntax which I called "hErlang".
For example, this is a hErlang module:
-module predict
-export (predict/2)
-import math:(pi/0 sqrt/1)
-author "Richard A. O'Keefe"
-date {2002,08,14}
-sccs "08/16/02"
predict X0 Ns =
let {Xs,Ys} = odds_and_evens Ns,
Np = length Xs,
XBar = if Np == 0 => 0.0 else sum Xs / Np fi,
YBar = if Np == 0 => 0.0 else sum Ys / Np fi,
Beta1 = sum [(X-XBar)*(Y-YBar) for X,Y in Xs,Ys] /
sum [(X-XBar)*(X-XBar) for X in Xs],
Beta0 = YBar - Beta1*XBar,
S = sqrt((sum [(Y-Beta1*X-Beta0)^2 for X,Y in Xs,Ys])/(Np-2)),
R = sqrt((Np+1)/Np + (X-XBar)^2/sum [(X-XBar)^2 for X in Xs]),
T70 = S * R * tfun 0.85 (Np-2),
T90 = S * R * tfun 0.95 (Np-2),
Y0 = Beta1*X0+Beta0
in {Y-T90,Y-T70,Y,Y+T70,Y+T90}
odds_and_evens [X,Y|XYs] = let {Xs,Ys} = odds_and_evens XYs in {[X|Xs],[Y|Ys]}
odds_and_evens _ = {[],[]}
tfun Goal N =
let G = (Goal-0.5) * (gam N / gam (N+1)) * sqrt (pi() * N),
F = \X. (1+X*X/N)^(-0.5*(N+1))
in bsearch F G 1.0 8.0
gam 1 = sqrt (pi())
gam 2 = 1.0
gam (K+2) = (K/2.0) * gam K
bsearch F G Lo Hi | Hi-Lo <= 0.5e-6 = (Lo+Hi)*0.5
= let M = (Lo + Hi) * 0.5,
S = simpson F 0 M 1.0e-5 10 0.0
in if S < G => bsearch F G M Hi
or S >= G => bsearch F G Lo M fi
simpson F X0 X1 Eps N R0 = % 2 'where' lines shorter.
let W = (X1 - X0) / (2 * N),
R = ( 4.0 * sum [F(X0 + W * (2*I-1)) for I in [1..N]]
+ 2.0 * sum [F(X0 + W * (2*I) ) for I in [1..N-1]]
+ F X0 + F X1 ) * (W/3.0)
in if abs (R-R0) <= Eps => R else simpson F X0 X1 Eps (N*2) R fi
It looks a lot like Haskell, but it's Erlang semantics all the way.
Not unlike LFE, in fact.
I never bothered finishing this, so don't ask for the code.
I just took it far enough to determine that the thing *could* be
done and *did* produce a useful payoff (my test files were about
1/3rd shorter than normal Erlang). But incorporating records and
binary patterns and all the other things seemed too much like work.
So a syntactically leaner Erlang *is* possible. The one thing I
found in that experiment that's really important here is that you
CAN'T get there from here one step at a time. To make a really
lean Erlang, you *have* to take a great big jump to a coherently
designed whole.
More information about the erlang-questions
mailing list