forget

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

forget

James Hague-3
>There are a couple of problems here.  The first one someone has already
>mentioned, that while Forth has an explicit stack Erlang (the language)
>doesn't, it has variables. The second one is that I personally find that
>I seldom have this type of code,

I agree, in that the last thing Erlang needs is another fringe feature.  The
"language extensions since 4.4" section of the documentation is becoming
daunting.  But I do see this sort of "VarN =" code regularly, even in OTP
itself, and it always makes me think that there has to be a better way.


Reply | Threaded
Open this post in threaded view
|

forget

Alex Peake
Forgive my lack of Erlang knowledge, but this all seems like a standard
pattern of "Composition"?

%%%% Compose functions
compose([Fn]) ->
        Fn;
compose([Fn | FnTail]) ->
        fun(Args) ->
                apply(Fn,[apply(compose(FnTail),[Args])])
        end.


Alex


> -----Original Message-----
> From: owner-erlang-questions
> [mailto:owner-erlang-questions]On Behalf Of James Hague
> Sent: Thursday, May 30, 2002 8:06 AM
> To: 'erlang-questions'
> Subject: Re: forget
>
>
> >There are a couple of problems here.  The first one someone has already
> >mentioned, that while Forth has an explicit stack Erlang (the language)
> >doesn't, it has variables. The second one is that I personally find that
> >I seldom have this type of code,
>
> I agree, in that the last thing Erlang needs is another fringe
> feature.  The
> "language extensions since 4.4" section of the documentation is becoming
> daunting.  But I do see this sort of "VarN =" code regularly, even in OTP
> itself, and it always makes me think that there has to be a better way.
>




Reply | Threaded
Open this post in threaded view
|

forget

Ulf Wiger-4
On Thu, 30 May 2002, Alex Peake wrote:

>Forgive my lack of Erlang knowledge, but this all seems like a
>standard pattern of "Composition"?
>
>%%%% Compose functions
>compose([Fn]) ->
> Fn;
>compose([Fn | FnTail]) ->
> fun(Args) ->
> apply(Fn,[apply(compose(FnTail),[Args])])
> end.
>
>Alex

That is certainly a pretty common pattern, but I don't think it
suffices to solve the problem that James refers to (and I have
complained about in previous postings.)

Just to take an example (perhaps not the best one, but rather one
that I could find in about 10 seconds):

scan_xml_decl("encoding" ++ T,
              S0 = #xmerl_scanner{event_fun = Event},
              Decl0 = #xmlDecl{attributes = Attrs}) ->
    %% [80] EncodingDecl
    ?bump_col(8),
    {T1, S1} = scan_eq(T, S),
    {EncName, T2, S2} = scan_enc_name(T1, S1),
    Attr = #xmlAttribute{name = encoding,
                         parents = [{xml, XMLPos = 1}],
                         value = EncName},
    Decl = Decl0#xmlDecl{encoding = EncName,
                         attributes = [Attr|Attrs]},
    S3 = #xmerl_scanner{} =
      Event(#xmerl_event{event = ended,
                         line = S0#xmerl_scanner.line,
                         col = S0#xmerl_scanner.col,
                         data = Attr}, S2),
    scan_xml_decl(T2, S3, Decl).

This function, I think, reflects the nasty problems you can get
into with this style of programming. There are other functions in
the same module with greater complexity of numbered variables.
The suggestions so far don't offer a solution, as I see it. I
don't have one myself, other than (a) throwing it all out and
rewriting the code using a different programming model, or (b)
trying to live with the problem, carefully tracing by hand all
variable use in each funtion.

(Oh, if you're wondering where T and S came from, the
?bump_col(8) macro binds them (yes, ouch!))

/Uffe

--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks



Reply | Threaded
Open this post in threaded view
|

forget

Luke Gorrie-3
Ulf Wiger <etxuwig> writes:

> That is certainly a pretty common pattern, but I don't think it
> suffices to solve the problem that James refers to (and I have
> complained about in previous postings.)
>
> Just to take an example (perhaps not the best one, but rather one
> that I could find in about 10 seconds):

The solution is simply to name the intermediate variables S100, S200,
S300, so that you can then insert/delete lines safely without altering
the existing flow.

What did you learn to program on, anyway? ;-)

Cheers,
Luke



Reply | Threaded
Open this post in threaded view
|

forget

Ulf Wiger-4
On 30 May 2002, Luke Gorrie wrote:

>The solution is simply to name the intermediate variables S100,
>S200, S300, so that you can then insert/delete lines safely
>without altering the existing flow.
>
>What did you learn to program on, anyway? ;-)
>
>Cheers,
>Luke

Oh, I spent a lot of time writing code in Omnis 3. It didn't have
named variables at all -- only "hash variables": #1 - #60.
#1 - #10 were integers, some where floats, and the rest were
strings, if I recall correctly. Why?  (:

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks



Reply | Threaded
Open this post in threaded view
|

forget

Vance Shipley-2
In reply to this post by Ulf Wiger-4

I still would like to see the linter solution.

        -Vance

On Thu, May 30, 2002 at 08:10:17PM +0200, Ulf Wiger wrote:
> ...
> The suggestions so far don't offer a solution, as I see it. I
> don't have one myself, other than (a) throwing it all out and
> rewriting the code using a different programming model, or (b)
> trying to live with the problem, carefully tracing by hand all
> variable use in each funtion.


Reply | Threaded
Open this post in threaded view
|

forget

Matthias Lang-2
In reply to this post by James Hague-3

 > I agree, in that the last thing Erlang needs is another fringe feature.  The
 > "language extensions since 4.4" section of the documentation is becoming
 > daunting.  But I do see this sort of "VarN =" code regularly, even in OTP
 > itself, and it always makes me think that there has to be a better way.

As Joe alluded, the better way used by at least part of the functional
programming world is monads, for instance this article shows how they
could be used in Ulf Wiger's XML parser example (among others):

   http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm

But the R1, R2, R3 style of programming combined with the +warn_unused_vars
flag works reasonably sufficiently well for me that it doesn't seem
worth the added complexity (in the manual, among other places!) of monads.

Matthias