[mercury-users] Preferred coding style for switches

[Gustavo A. Ospina]

>I think I prefer the first style (multiple clauses). Even if you do get
>more heads, I get the feeling that it is actually a tad neater.
>To be fair though, I have been very unconsistant in the past with regards
>to this, though.
>I will still do a switch in style 2 for things like dealing with a list,
>but for a type with many constructors, I lean towards style 1. If
>anything, style 1 saves you one level of indentation. ;)
>
>So, in summary - I think that for a type with more than, say, three
>constructors the first style is `better'.

This is discutible. I would say that the two styles can be useful depending
of the intended relation between the two parameters. I would say that style
1 would be better when the foo's and bar's are a very closed relation (for
example, a descomposition of a thing in two subcomponents). If the foo's
and bar's correspond to two concepts completely differents and the problem
is solved by some sort of "structural induction", the results could be best
expressed in style 2.

In my Mercury coding style, I prefer write the switches as:

p(X) :-
(	X = foo1,
	...
;
...
;
	X = fooN,
	...
).

In this way I save one identation level, too. Of course, it's not the last
word.

>> In Mercury parlance, a switch is an exhaustive test against the possible
>> type constructors a variable can have.  This might be implemented as
>> cascading if-then-elses or as a lookup table [Mercury chaps: what rule
>> does get used?]  

>I believe the options `--dense-switch-req-density',
>` --lookup-switch-req-density' and so on decide whether or not a switch
>is output or a sequence of if-then-elses.

It's good to see that the compiler make this type of analysis. IMHO, it
seems not so trivial to perform an analysis to determine whether the heads
of the clauses in style 1 can correspond to a switch with two (or even
more) nested levels (foo's - bar's).

>Unfortunately our switch detection and generation code is spread through
>multiple modules.  Zoltan would like someone to go in and factor all the
>common parts out so that all the different types of switches are
>handled in one spot.  It would make a nice starting project for anyone
>wanting to learn about the Mercury project.  Volunteers?

That interests me.

Best regards.

+ Gustavo.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------