Booleans in bit syntax

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Booleans in bit syntax

Viktor Söderqvist
Adding a boolean type specifier in the bit syntax would be useful, I
think. Then you could write

    decode_stuff(<<Flag1/boolean, Flag2/boolean, 0:6, Rest/binary>>) ->
        {Flag1, Flag2, Rest}.

instead of

    decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
        Flag1 = case F1 of 1 -> true;
                           0 -> false
                end,
        Flag2 = case F2 of 1 -> true;
                           0 -> false;
                end,
        {Flag1, Flag2, Rest}.

Many binary protocols contain flags and indicators, typically used as
booleans in application logic with 1 for true, 0 for false.

The default size would be 1 bit, i.e. Size = 1 and Unit = 1. It would be
for constructing binaries as well. It is intuitive and it would be
backward compatible.

What do you think? Any reason for not adding it?

Viktor
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Guilherme Andrade
Hi Viktor,

I've recently wondered exactly the same. It would be very helpful in doing away with boilerplate helpers for converting single bits into booleans and vice-versa.

On 20 January 2018 at 13:32, Viktor Söderqvist <[hidden email]> wrote:
Adding a boolean type specifier in the bit syntax would be useful, I
think. Then you could write

    decode_stuff(<<Flag1/boolean, Flag2/boolean, 0:6, Rest/binary>>) ->
        {Flag1, Flag2, Rest}.

instead of

    decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
        Flag1 = case F1 of 1 -> true;
                           0 -> false
                end,
        Flag2 = case F2 of 1 -> true;
                           0 -> false;
                end,
        {Flag1, Flag2, Rest}.

Many binary protocols contain flags and indicators, typically used as
booleans in application logic with 1 for true, 0 for false.

The default size would be 1 bit, i.e. Size = 1 and Unit = 1. It would be
for constructing binaries as well. It is intuitive and it would be
backward compatible.

What do you think? Any reason for not adding it?

Viktor
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



--
Guilherme

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Kostis Sagonas-2
In reply to this post by Viktor Söderqvist
On 01/20/2018 02:32 PM, Viktor Söderqvist wrote:

> Adding a boolean type specifier in the bit syntax would be useful, I
> think. Then you could write
>
>      decode_stuff(<<Flag1/boolean, Flag2/boolean, 0:6, Rest/binary>>) ->
>          {Flag1, Flag2, Rest}.
>
> instead of
>
>      decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
>          Flag1 = case F1 of 1 -> true;
>                             0 -> false
>                  end,
>          Flag2 = case F2 of 1 -> true;
>                             0 -> false;
>                  end,
>          {Flag1, Flag2, Rest}.
>
> Many binary protocols contain flags and indicators, typically used as
> booleans in application logic with 1 for true, 0 for false.
>
> The default size would be 1 bit, i.e. Size = 1 and Unit = 1. It would be
> for constructing binaries as well. It is intuitive and it would be
> backward compatible.
>
> What do you think? Any reason for not adding it?

Yes.  The Erlang type language already has a type boolean() which is
defined to comprise of the atoms 'true' and 'false'.

Suddenly adding some syntactic sugar which transforms 1s to trues and 0s
to falses in binaries does not add any significant expressive power to
the language; just confusion.

By the way, your "instead of" code is just bad programming.  The
following is shorter and nicer:

     decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
         {bit2bool(F1), bit2bool(F2), Rest}.

     bit2bool(1) -> true;
     bit2bool(0) -> false.

Kostis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Jacob-2
In reply to this post by Viktor Söderqvist
On 20.01.2018 14:32, Viktor Söderqvist wrote:

> Adding a boolean type specifier in the bit syntax would be useful, I
> think. Then you could write
>
>     decode_stuff(<<Flag1/boolean, Flag2/boolean, 0:6, Rest/binary>>) ->
>         {Flag1, Flag2, Rest}.
>
> instead of
>
>     decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
>         Flag1 = case F1 of 1 -> true;
>                            0 -> false
>                 end,
>         Flag2 = case F2 of 1 -> true;
>                            0 -> false;
>                 end,
>         {Flag1, Flag2, Rest}.

What about

  decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
      {F1 =:= 1, F2 =:= 1, Rest}

it's even shorter than your proposal and already works (okay, encoding
bools is a different thing).

> What do you think? Any reason for not adding it?

In my opinion, it changes much without really filling a gap. So far, the
<<>> expressions/matches only convert numbers to binaries/bitstrings and
vice versa.

Also, encoding 'true' as 1 and 'false' as 0 is just one possible
encoding (even if it is common).

I prefer to have explicit conversions, IMO they are much better to
maintain than using conversion magic.

Jacob
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Viktor Söderqvist
The topic 1=true and 0=false as a convention seems to be controversial. :-)

If not adding booleans in bit syntax, then how about adding build-in
conversion functions for booleans and bit values? E.g. boolean_to_integer/1.

If we can't assume that convention, then how about adding four
functions: is_zero/1, is_one/1, true_count/1 and false_count/1 instead?
That should get rid of any confusion.

Theoretically, of course there are two possible bijective mappings
between bit values (0, 1) and boolean values (true, false).

It may be radical, but in practice, I believe the convention (1 for
true) can be safely assumed to be generally understood by almost
everyone in almost every such such mapping situation. Even persons who
doesn't have any insight in programming often have an intuition that it
is all about ones and zeroes, representing true/false, or electric
switch on/off; the bit as the smallest and most basic unit of
information in computers.

Replies to Jacob and Kostis inline.

On 2018-01-20 15:53, Jacob wrote:
> In my opinion, it changes much without really filling a gap. So far, the
> <<>> expressions/matches only convert numbers to binaries/bitstrings and
> vice versa.

Bit syntax can also convert between Unicode codepoints, UTF-8, UTF-16
and UTF-32. It can convert endianess for IEEE floats and integers too.
Pretty much any convenient conversion for basic types to/from binary.

    << <<X/utf16-little>> || <<X/utf8>> <= <<"Example">> >>.

On 2018-01-20 15:58, Kostis Sagonas wrote:
> Yes. The Erlang type language already has a type boolean() which is
> defined to comprise of the atoms 'true' and 'false'.

true and false are not just any atoms. They have special meaning in
language constructs for branching, i.e. logic. Arguably the most basic
values of all.

On 2018-01-20 15:53, Jacob wrote:
> What about
>
>   decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
>       {F1 =:= 1, F2 =:= 1, Rest}
>
> it's even shorter than your proposal and already works (okay, encoding
> bools is a different thing).

You are right, the manual conversion is really just three tokens.

The simplest encoding I can think of would be a function call, given you
already have such a function in your module.

> I prefer to have explicit conversions, IMO they are much better to
> maintain than using conversion magic.

Doesn't the type specifier in the bit syntax indicate an explicit
conversion between binary and the explicitly specified type?

On 2018-01-20 15:58, Kostis Sagonas wrote:
> Suddenly adding some syntactic sugar which transforms 1s to trues and 0s
> to falses in binaries does not add any significant expressive power to
> the language; just confusion.

Isn't most of the binary syntax just syntactic sugar for conversions?

Viktor
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Mark Jones
I'd just like to point out that the logic is sometimes inverted. Specifically when you're interfacing to certain types of hardware. 

Cheers,
Mark

Sent from my PDP-11

On Jan 20, 2018 8:14 PM, "Viktor Söderqvist" <[hidden email]> wrote:
The topic 1=true and 0=false as a convention seems to be controversial. :-)

If not adding booleans in bit syntax, then how about adding build-in
conversion functions for booleans and bit values? E.g. boolean_to_integer/1.

If we can't assume that convention, then how about adding four
functions: is_zero/1, is_one/1, true_count/1 and false_count/1 instead?
That should get rid of any confusion.

Theoretically, of course there are two possible bijective mappings
between bit values (0, 1) and boolean values (true, false).

It may be radical, but in practice, I believe the convention (1 for
true) can be safely assumed to be generally understood by almost
everyone in almost every such such mapping situation. Even persons who
doesn't have any insight in programming often have an intuition that it
is all about ones and zeroes, representing true/false, or electric
switch on/off; the bit as the smallest and most basic unit of
information in computers.

Replies to Jacob and Kostis inline.

On 2018-01-20 15:53, Jacob wrote:
> In my opinion, it changes much without really filling a gap. So far, the
> <<>> expressions/matches only convert numbers to binaries/bitstrings and
> vice versa.

Bit syntax can also convert between Unicode codepoints, UTF-8, UTF-16
and UTF-32. It can convert endianess for IEEE floats and integers too.
Pretty much any convenient conversion for basic types to/from binary.

    << <<X/utf16-little>> || <<X/utf8>> <= <<"Example">> >>.

On 2018-01-20 15:58, Kostis Sagonas wrote:
> Yes. The Erlang type language already has a type boolean() which is
> defined to comprise of the atoms 'true' and 'false'.

true and false are not just any atoms. They have special meaning in
language constructs for branching, i.e. logic. Arguably the most basic
values of all.

On 2018-01-20 15:53, Jacob wrote:
> What about
>
>   decode_stuff(<<F1:1, F2:1, 0:6, Rest/binary>>) ->
>       {F1 =:= 1, F2 =:= 1, Rest}
>
> it's even shorter than your proposal and already works (okay, encoding
> bools is a different thing).

You are right, the manual conversion is really just three tokens.

The simplest encoding I can think of would be a function call, given you
already have such a function in your module.

> I prefer to have explicit conversions, IMO they are much better to
> maintain than using conversion magic.

Doesn't the type specifier in the bit syntax indicate an explicit
conversion between binary and the explicitly specified type?

On 2018-01-20 15:58, Kostis Sagonas wrote:
> Suddenly adding some syntactic sugar which transforms 1s to trues and 0s
> to falses in binaries does not add any significant expressive power to
> the language; just confusion.

Isn't most of the binary syntax just syntactic sugar for conversions?

Viktor
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Ian-2
In reply to this post by Viktor Söderqvist

On 20/01/2018 13:32, Viktor Söderqvist wrote:
> Many binary protocols contain flags and indicators, typically used as
> booleans in application logic with 1 for true, 0 for false.

Your description of the convention is loose and incomplete. I fear it
risks the wrong decision being made.

The convention is better expressed as...
   0 and anything that auto-converts to 0 is false.
   Everything else that can be compared is true.
   The system returns 0 for false, and 1 for true

Examples:
Php has  0, 0.0, "", null, and an empty array as all false,
while -1, NaN, and resources are all true.

In Java Script 0, -0, "", undefined, null, NaN, and false are false.
Everything with value is true.

C has had 0 for false, while true was often 1 but varied with version
and programmer. Since C99 implementation has been standardized and
hidden inside stdbool.h.

C++ would be the same as C.

Python has None, False, zero in any form, '', {}, [] and (), and user
defined types with a len() of zero as false. Everything else is True.
Also the operations 'and' and 'or' return one of their operands, and not
1 or 0.

As for your proposal, I think it adds complication without adding utility.

Ian

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Jesper Louis Andersen-2
Most languages with static typing does not permit the mixing of integers and boolean values unless you explicitly convert between them. At leas the languages which are sane do.

Whenever you propose a change for syntactic convenience, it is important to think about the dual as well: if we introduce the feature, does it lead to increased error rates due to misunderstanding. Here, a crash is considerably less of a problem than a silent acceptance of some value which the programmer might not have wanted.

This is why it is sometimes better to have the conversion be explicit in the program, because the removal of (dual) errors makes up for the extra typing that could be needed in the process.

Any bit on a wire is a representation of some underlying state or value. If I were to handle this, I would seek to map this representation into a meaningful internal state. And here I note that a boolean value isn't always what you want because it bears too little meaning. It is often better to invent meaningful atoms and pass those around as it improves the readability of the code. For instance, we could have written gen_tcp:listen/2 and gen_tcp:listen/16 and then supplied a large list of true false values, but it wouldn't work out. Rather, we pass in a list of options which are then parsed and interpreted. Some of those become bits in the underlying protocol, but we hide this from the high-level interface.

On Sun, Jan 21, 2018 at 12:25 PM Ian Hobson <[hidden email]> wrote:

On 20/01/2018 13:32, Viktor Söderqvist wrote:
> Many binary protocols contain flags and indicators, typically used as
> booleans in application logic with 1 for true, 0 for false.

Your description of the convention is loose and incomplete. I fear it
risks the wrong decision being made.

The convention is better expressed as...
   0 and anything that auto-converts to 0 is false.
   Everything else that can be compared is true.
   The system returns 0 for false, and 1 for true

Examples:
Php has  0, 0.0, "", null, and an empty array as all false,
while -1, NaN, and resources are all true.

In Java Script 0, -0, "", undefined, null, NaN, and false are false.
Everything with value is true.

C has had 0 for false, while true was often 1 but varied with version
and programmer. Since C99 implementation has been standardized and
hidden inside stdbool.h.

C++ would be the same as C.

Python has None, False, zero in any form, '', {}, [] and (), and user
defined types with a len() of zero as false. Everything else is True.
Also the operations 'and' and 'or' return one of their operands, and not
1 or 0.

As for your proposal, I think it adds complication without adding utility.

Ian

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Kostis Sagonas-2
In reply to this post by Viktor Söderqvist
On 01/21/2018 03:14 AM, Viktor Söderqvist wrote:
>
> On 2018-01-20 15:58, Kostis Sagonas wrote:
>> Suddenly adding some syntactic sugar which transforms 1s to trues and 0s
>> to falses in binaries does not add any significant expressive power to
>> the language; just confusion.
> Isn't most of the binary syntax just syntactic sugar for conversions?

No, it's not just syntactic sugar.  The binary/bitstring data type is
something that cannot be converted to some other Erlang term with the
same (space-efficient) underlying representation.

Kostis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Booleans in bit syntax

Pierre Fenoll-2
I'd just like to point out that the logic is sometimes inverted. Specifically when you're interfacing to certain types of hardware. 

How about introducing both /bool0 and /bool1


Cheers,
-- 
Pierre Fenoll


On 22 January 2018 at 01:36, Kostis Sagonas <[hidden email]> wrote:
On 01/21/2018 03:14 AM, Viktor Söderqvist wrote:

On 2018-01-20 15:58, Kostis Sagonas wrote:
Suddenly adding some syntactic sugar which transforms 1s to trues and 0s
to falses in binaries does not add any significant expressive power to
the language; just confusion.
Isn't most of the binary syntax just syntactic sugar for conversions?

No, it's not just syntactic sugar.  The binary/bitstring data type is something that cannot be converted to some other Erlang term with the same (space-efficient) underlying representation.

Kostis

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions