<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 04/16/2012 08:42 AM, Erik Søe Sørensen wrote:
<blockquote
cite="mid:CAO1s=UWw0f-jYc6puGWjo=s8w7ay_E-vmbY=r-dYD0Kz02bHyw@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div>Den 16. apr. 2012 10.51 skrev Michael Truog <span><<a
moz-do-not-send="true" href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>></span>:<br>
<blockquote>
<div>On 04/15/2012 09:06 PM, Richard O'Keefe wrote:<br>
> On 16/04/2012, at 1:05 PM, Michael Truog wrote:<br>
>> So you believe that pattern matching in guards
requires binding local variables to be useful, right?<br>
> No, I just believe that it makes them *more* useful.<br>
><br>
>> You do not seem to be concerned about this change
causing guards to create side-effects, where they previously
where unable to do so.<br>
> Come off it! To start with, binding a variable is not
a side effect.<br>
> But consider: apart from 'if', guards are not found on
their own, but<br>
> has one part of a Pattern when Guard combination. If
the Pattern part<br>
> can bind variables, what is so evil about the Guard
part doing so?<br>
</div>
When you consider a side-effect as defined with the simplest
possible explanation ("a side-effect is where state in context
A impacts state in context B"), it should be easy to see that
a variable created within a guard that is then used within a
function body is a side-effect. I understand that normal
patterns can bind variables. Why must guards now bind
variables also?<br>
<div><br>
>> Are we just not aware or recognizing any potential
negative aspects of binding variables within guard
statements, or do we just accept them as a necessary evil?<br>
> I don't know who "we" are here. I can imagine no
negative aspects of binding variables<br>
> within guards that are not also negative aspects of
binding variables within patterns.<br>
><br>
> Erlang was strongly influenced by Strand 88 which owed
a fair bit to Parlog.<br>
> In Parlog, a clause has the form<br>
><br>
> H := G1, ..., Gm : Body.<br>
><br>
> where ":" is the "commit" operator, and is left out if
m = 0, the Gi being<br>
> the guards., and a Body is<br>
> - Body1 , Body2 "parallel AND"<br>
> - Body1 & Body2 "sequental AND"<br>
> - a call<br>
> Parlog guards are rather more general than Erlang
guards, and it was<br>
> implementation experience with nested layers of
processes that suggested<br>
> the simplified "flat" guards found in GHC, FCP, and
Erlang. But in all<br>
> the concurrent logic programming languages, including
GHC, FCP, and Parlog,<br>
> guards may include pattern-matches that bind variables.<br>
><br>
> I never heard of any negative consequences of _that_.<br>
</div>
My concern is that you never heard of negative consequences
because no one cared. You are arguing with examples from
Haskell and Parlog which both found no wide-spread use outside
of academia.</blockquote>
<div><br>
Saying that there's an abstraction leak in a wide-spread
Haskell component and no-one in the Haskell community cares
about it is like saying that the crew of the ISS doesn't care
if there's a leak in their, well, anything.<br>
I find the mention of Haskell in this context quite
appropriate.<br>
</div>
</div>
</blockquote>
I understand that the research community would care about the
abstract implications of the feature. My concern is instead about
sacrificing efficiency for no reason. Haskell and Parlog
development is not forced to consider performance implications as a
research language.<br>
<br>
<blockquote
cite="mid:CAO1s=UWw0f-jYc6puGWjo=s8w7ay_E-vmbY=r-dYD0Kz02bHyw@mail.gmail.com"
type="cite">
<div>
<blockquote> I know Haskell has tried very hard to be applied
outside of academia, however, it never really seems to stick
to any problems, so it seems to retain status as a language
that is a solution in search of a problem to solve (any
problem will do). You don't need to bother listing obscure
research projects done in Haskell here.<br>
</blockquote>
<div> </div>
<div>The XKCD's April Fool's prank recently was at least
partially done in Haskell. Oh, and Facebook, Google and a
number of banks use the language internally. Ericsson too.<br>
</div>
</div>
</blockquote>
I understand that the financial sector often uses functional
languages. However, with production code, I have only been aware of
things like MUMPS or ML. When Haskell is used at a company, it
seems to always just be one, or at most two Phds that are most
familiar with Haskell, so they would rather stick with that language
than risk the implementation in a language they haven't used as
often. However, the Haskell code never seems to find its way into
production, unless it is a batch algorithm for analysis which they
personally run.<br>
<br>
<blockquote
cite="mid:CAO1s=UWw0f-jYc6puGWjo=s8w7ay_E-vmbY=r-dYD0Kz02bHyw@mail.gmail.com"
type="cite">
<div>
<blockquote>
<div>
>> To me, the idea of guard statements binding
variables seems to contradict both the purpose/name "guard"
since it is guarding state, and binding a variable within
the guard statement would be allowing the state to leak out.<br>
> There are no guard statements, only guard tests. And
pattern matching is<br>
> a perfectly good test. Consider two clauses:<br>
><br>
> f(X = Y) when true -> g(X).<br>
><br>
> f(Y) when X = Y -> g(X).<br>
><br>
> How does the second clause "leak" any "state" that the
first one doesn't?<br>
</div>
I agree that both can be written with the changes mentioned in
the proposal to add variable bindings to guards. That is part
of the reason it appears to be an unnecessary addition that is
just meant to complicate Erlang code and the Erlang VM.<br>
</blockquote>
<div><br>
The Erlang VM would come to no harm.<br>
(I believe I have enough knowledge of BEAM bytecode to
guarantee you this.)<br>
</div>
</div>
</blockquote>
If there are no problems within the Erlang VM for the addition, then
it would only be the effect on Erlang code that seems problematic.<br>
<blockquote
cite="mid:CAO1s=UWw0f-jYc6puGWjo=s8w7ay_E-vmbY=r-dYD0Kz02bHyw@mail.gmail.com"
type="cite">
<div>
<blockquote>
<div><br>
> For that matter, these days Haskell has "pattern
guards":<br>
><br>
> <clause head> | <pattern> <-
<expr>{, ...} = <expr><br>
><br>
> See <a moz-do-not-send="true"
href="http://www.haskell.org/haskellwiki/Pattern_guard">http://www.haskell.org/haskellwiki/Pattern_guard</a><br>
><br>
> Nobody in the Haskell community thinks of this as
"leaking" any kind of "state",<br>
> and Haskell is notably purer than Erlang...<br>
</div>
Arguing that no one within the Haskell community thought about
this doesn't seem relevant. Erlang as a language is at a
different place than where Haskell is. I don't see these as
differences that should be resolved so that Erlang should be
more like Haskell. The purity argument about Haskell means
very little to someone who is interested in solving problems
outside of academia. If Haskell was completely pure, it would
never write to the screen, and we would know very little about
the language... wouldn't we?<br>
</blockquote>
<div> </div>
<div>Yes, Haskell can do I/O. If it couldn't, it'd be just as
irrelevant as you're trying to paint it.<br>
But what it also does is keep the I/O parts separate from the
parts which aren't intended to do I/O. And that separation is
quite pure. The purity argument about Haskell means quite a
lot to some which are interested in solving problems outside
of academia and wish to use less of their problem solving time
on hunting bugs caused by unintended side effects. Which, on
the face of it, would be something you care about too.<br>
<br>
</div>
</div>
</blockquote>
Yes, I am. I do admit I am interested in Haskell. However, I also
must manage my time, and spending time on a language that sees
little application would only be disappointing.<br>
<br>
<blockquote
cite="mid:CAO1s=UWw0f-jYc6puGWjo=s8w7ay_E-vmbY=r-dYD0Kz02bHyw@mail.gmail.com"
type="cite">
<div>
<blockquote>
<div><br>
>> I don't want to push this point if it isn't
regarded as a problem, but I just wanted to understand how
you see it.<br>
> Here's how I see it:<br>
> (1) The concurrent programming languages preceding
Erlang allowed<br>
> pattern matches in guards, using "=". There were
no conceptual<br>
> difficulties with this.<br>
> (2) I have never seen any explanation of why Erlang
didn't.<br>
> (3) It is technically possible to rewrite Erlang
clauses with<br>
> pattern matching to ones without, at a great loss
of clarity.<br>
><br>
> f(Args) when T1, P = E, T2 -> Body<br>
> =><br>
> f(Args) when T1 -> try E of P when T2 ->
Body<br>
> catch _ -> rest_f(Args)
end;<br>
> f(Args) -> rest_f(Args).<br>
><br>
> f'(Args, P) when T2 -> Body;<br>
> f'(Args, _) -> rest_f(Args).<br>
><br>
> I hope that gives you the idea. No "state" can be
"leaked" by<br>
> pattern guards that cannot be "leaked" in this way.<br>
> (4) Pattern guards in Haskell don't seem to cause any
problems.<br>
><br>
</div>
My argument is that if patterns already provide us variable
bindings, why weaken Erlang guards to also bind variables. I
would rather have a stronger guarantee that state from a guard
will not affect the context it controls. I do not think the
aspect in the Haskell language offers a convincing argument
for binding variables in guards (otherwise, that would be like
saying "Hey, some academics did something in a language the
industry doesn't use, but it seems conceptually pure, so lets
imitate them."). Implementing something in Haskell does not
create a requirement that it must be implemented in Erlang.</blockquote>
<div> </div>
<div>Certainly not, but countering a purity concern with
experience from that community is not far-fetched.<br>
<br>
</div>
<blockquote> A requirement that Haskell features be implemented
in Erlang would only help Haskell programmers, but if Haskell
programmers don't often work outside of academia, why would
they use Erlang to solve real problems?<br>
</blockquote>
</div>
<br>
/Erik (not a practising Haskell programmer myself, but I do know
the paradigm well enough to have respect.)<br>
</blockquote>
I respect the Haskell language. However, I also respect the Erlang
language. I don't see a requirement that the two languages share
features, and pursuing Haskell features in Erlang blindly seems like
a mistake.<br>
</body>
</html>