<div class="gmail_quote">Sorry for taking so long to comment this, but I have been thinking. :-) Comments follow.</div><div class="gmail_quote"><br></div><div class="gmail_quote">2008/5/16 Mats Cronqvist <<a href="mailto:mats.cronqvist@gmail.com">mats.cronqvist@gmail.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">Andras Georgy Bekes wrote:<br>
> Hi,<br>
><br>
> I am trying to end this discussion with some usable result.<br>
><br>
> First let me state that<br>
> - I am now convinced that ~= is not a good idea, therefore I am not<br>
> going to submit it in an eep.</div></blockquote><div><br></div><div>Here I disagree, sort of. While I also think the ~= is not a good idea, I agree with Richard O'Keefe that having = as a legal guard test is a Good Thing. I also don't see any logical problems with it. If you have the semantics:</div>
<div><br></div><div>- if match succeeds it returns true and binds any unbound variables</div><div>- if match fails, it returns false, i.e. it does generate an error</div><div><br></div><div>Then you modify all boolean operations so that if they succeed, return true, then any new variables which are bound in them are exported, while if they fail, return false, no variables are exported.</div>
<div><br></div><div>- This will work for the whole guard as if the guard fails then no variables are exported but the clause is not chosen anyway.</div><div>- No problems with not(...) as it will never export variables.</div>
<div>- Same with other boolean operators, success implies export. This makes checking for variable bindings in and after guards relatively easy.</div><div><br></div><div>As far as I can see there are no problems with this.</div>
<div><br></div><div>Then as we allow = as a boolean test in guards we can extend it to be a valid *test* in list/binary comprehensions as well. It the match succeeds the test succeeds and exports the any new variable bindings. Someone asked for this earlier and while just having it in lc/bc might be a bit off having it as a valid *guard* test means it becomes acceptable as lc/bc test. It also easy to implement. I have the this feature already in LFE.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">
> - I am convinced that multiple patterns is a good idea (many of you<br>
> stated that you like it). I am about to send it as an eep, we just have<br>
> to agree on the right notation.<br>
><br>
><br>
>> Yes, but Virding's proposal uses ";" for the *SAME* meaning<br>
>> ("or") that it normally has.<br>
>><br>
><br>
> My problem with ; is that it's ambiguous.<br>
> I can write at least one pattern that could be parsed into two different<br>
> ASTs.<br>
><br>
>    Pattern when Guard; true -><br>
> now is this a single pattern: Pattern when (Guard; true) ?<br>
> or is it multiple patterns: (Pattern when Guard); true ?<br>
</div> i was reading virding's proposal as;<br>
<br>
case bla of<br>
  Pat when true ->;<br>
  Pat when false->;<br>
  Pat -><br>
    code()<br>
end.<br>
<br>
  but that's not what he wrote...<br>
<br>
  in that case i propose the above. currently gives syntax error.<br></blockquote></div><br><div>I don't have a problem with this, but I don't really see the need. The only time I have had repeated bodies they have been very simple no repeating just them has been very straight forward. While using ->; as syntax would be easy and cause no inconsistencies it has the downside that you would fail to capture the case where you have forgotten to give a body.</div>
<div><br></div><div>Actually thinking about it a bit more if you allow = in guards you really don't *need* this multiple pattern feature as you can express it as alternate guards. The problem would be that it would be more difficult to implement this pattern matching as efficiently as when it occurs the the head.</div>
<div><br></div><div>So maybe this solves the syntax question automatically.</div><div><br></div><div>Robert</div><div><br></div>