[m-dev.] Help required with Erlang: Address review comments

[Paul Bone]

Address review comments
As above.
---
library/io.m | 150 ++++++++++++++++++++++++++++++++++++-----------------------
1 file changed, 91 insertions(+), 59 deletions(-)
:- pragma foreign_proc("Erlang",
- do_open_binary(FileName::in, Mode::in, ResultCode::out,
+ do_open_binary(FileName::in, Mode::in, Result::out,
StreamId::out, Stream::out, _IO0::di, _IO::uo),
[will_not_call_mercury, promise_pure, tabled_for_io, thread_safe],
"
@@ -9814,12 +9846,12 @@ set_binary_output_stream(binary_output_stream(NewStream),
case mercury__io:mercury_open_stream(FileNameStr, ModeStr) of
{ok, Stream} ->
{'ML_stream', StreamId, _Pid} = Stream,
- ResultCode = 0;
+ Result = ok;

Result = {ok};
etc? (That is at least, what the reference manual section on Erlang
data passing conventions suggests that it is.)

Doh! that was it.

Thanks.

[Julien Fischer]

Post by Paul Bone

Address review comments
As above.
---
library/io.m | 150 ++++++++++++++++++++++++++++++++++++-----------------------
1 file changed, 91 insertions(+), 59 deletions(-)
:- pragma foreign_proc("Erlang",
- do_open_binary(FileName::in, Mode::in, ResultCode::out,
+ do_open_binary(FileName::in, Mode::in, Result::out,
StreamId::out, Stream::out, _IO0::di, _IO::uo),
[will_not_call_mercury, promise_pure, tabled_for_io, thread_safe],
"
@@ -9814,12 +9846,12 @@ set_binary_output_stream(binary_output_stream(NewStream),
case mercury__io:mercury_open_stream(FileNameStr, ModeStr) of
{ok, Stream} ->
{'ML_stream', StreamId, _Pid} = Stream,
- ResultCode = 0;
+ Result = ok;

Result = {ok};
etc? (That is at least, what the reference manual section on Erlang
data passing conventions suggests that it is.)

Doh! that was it.

I'll adjust the reference manual to it a litle more obvious.

Julien.

[Paul Bone]

Post by Julien Fischer

Post by Paul Bone

Address review comments
As above.
---
library/io.m | 150 ++++++++++++++++++++++++++++++++++++-----------------------
1 file changed, 91 insertions(+), 59 deletions(-)
:- pragma foreign_proc("Erlang",
- do_open_binary(FileName::in, Mode::in, ResultCode::out,
+ do_open_binary(FileName::in, Mode::in, Result::out,
StreamId::out, Stream::out, _IO0::di, _IO::uo),
[will_not_call_mercury, promise_pure, tabled_for_io, thread_safe],
"
@@ -9814,12 +9846,12 @@ set_binary_output_stream(binary_output_stream(NewStream),
case mercury__io:mercury_open_stream(FileNameStr, ModeStr) of
{ok, Stream} ->
{'ML_stream', StreamId, _Pid} = Stream,
- ResultCode = 0;
+ Result = ok;

Result = {ok};
etc? (That is at least, what the reference manual section on Erlang
data passing conventions suggests that it is.)

Doh! that was it.

I'll adjust the reference manual to it a litle more obvious.

To be fair, it's probably already the kind of thing that would be obvious to
someone who actually knows Erlang.

[Julien Fischer]

Post by Paul Bone

Post by Julien Fischer

Post by Paul Bone

Result = {ok};
etc? (That is at least, what the reference manual section on Erlang
data passing conventions suggests that it is.)

Doh! that was it.

I'll adjust the reference manual to it a litle more obvious.

To be fair, it's probably already the kind of thing that would be obvious to
someone who actually knows Erlang.

Maybe, although it's really a question of how Mercury values map down to
Erlang values. In any case, there's no harm in adding a note saying
that pragma foreign_export_enum doesn't need to exist for Erlang and
pointing the reader to the section on Erlang data passing conventions
(which is what I am intending to do).

Julien.

[Paul Bone]

Post by Julien Fischer

Post by Paul Bone

Post by Julien Fischer

Post by Paul Bone

Result = {ok};
etc? (That is at least, what the reference manual section on Erlang
data passing conventions suggests that it is.)

Doh! that was it.

I'll adjust the reference manual to it a litle more obvious.

To be fair, it's probably already the kind of thing that would be obvious to
someone who actually knows Erlang.

Maybe, although it's really a question of how Mercury values map down to
Erlang values. In any case, there's no harm in adding a note saying
that pragma foreign_export_enum doesn't need to exist for Erlang and
pointing the reader to the section on Erlang data passing conventions
(which is what I am intending to do).

Agreed. Thanks.