Erlang/OTP Forums

Author Message

<  Erlang patches mailing list  ~  tid() is not a predefined type anymore

Guest
Posted: Fri May 28, 2010 11:56 am Reply with quote
Guest
There is a patch that removes tid() from the list of predefined types.
It can be included as is provided that the 'export_type' branch is first
included in OTP. Otherwise, one has to manually remove the line which
reads:

-export_type([tab/0, tid/0]).

from file ets.erl


git fetch git://github.com/kostis/otp.git ets-tid-type

Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Fri May 28, 2010 11:57 am Reply with quote
Guest
There is a patch that removes tid() from the list of predefined types.
It can be included as is provided that the 'export_type' branch is first
included in OTP. Otherwise, one has to manually remove the line which
reads:

-export_type([tab/0, tid/0]).

from file ets.erl


git fetch git://github.com/kostis/otp.git ets-tid-type

Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Mon May 31, 2010 2:34 pm Reply with quote
Guest
On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> There is a patch that removes tid() from the list of predefined types.
> It can be included as is provided that the 'export_type' branch is first
> included in OTP. Otherwise, one has to manually remove the line which
> reads:
>
> -export_type([tab/0, tid/0]).
>
> from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type

I got into merge conflicts due to the bootstrap code
update and more. I will have to take this tomorrow...

>
> Kostis
>
> ________________________________________________________________
> erlang-patches (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Mon May 31, 2010 2:34 pm Reply with quote
Guest
On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> There is a patch that removes tid() from the list of predefined types.
> It can be included as is provided that the 'export_type' branch is first
> included in OTP. Otherwise, one has to manually remove the line which
> reads:
>
> -export_type([tab/0, tid/0]).
>
> from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type

I got into merge conflicts due to the bootstrap code
update and more. I will have to take this tomorrow...

>
> Kostis
>
> ________________________________________________________________
> erlang-patches (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Tue Jun 01, 2010 8:19 am Reply with quote
Guest
On Mon, May 31, 2010 at 05:43:12PM +0300, Kostis Sagonas wrote:
> Raimo Niskanen wrote:
> >On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> >>There is a patch that removes tid() from the list of predefined types.
> >>It can be included as is provided that the 'export_type' branch is first
> >>included in OTP. Otherwise, one has to manually remove the line which
> >>reads:
> >>
> >>-export_type([tab/0, tid/0]).
> >>
> >>from file ets.erl
> >>
> >>
> >> git fetch git://github.com/kostis/otp.git ets-tid-type
> >
> >I got into merge conflicts due to the bootstrap code
> >update and more. I will have to take this tomorrow...
>
> Raimo,
>
> The erl_lint.beam file in bootstrap is nothing special. It is just the
> .beam file that corresponds to the erl_lint.erl file so any such .beam
> file will do.
>
> The only thing that you have to be careful of is to include such a file
> before including the change in lib/debugger/src/dbg_iload.erl

Yes. That I can handle and/or ask Bj
Guest
Posted: Tue Jun 01, 2010 8:19 am Reply with quote
Guest
On Mon, May 31, 2010 at 05:43:12PM +0300, Kostis Sagonas wrote:
> Raimo Niskanen wrote:
> >On Fri, May 28, 2010 at 02:56:31PM +0300, Kostis Sagonas wrote:
> >>There is a patch that removes tid() from the list of predefined types.
> >>It can be included as is provided that the 'export_type' branch is first
> >>included in OTP. Otherwise, one has to manually remove the line which
> >>reads:
> >>
> >>-export_type([tab/0, tid/0]).
> >>
> >>from file ets.erl
> >>
> >>
> >> git fetch git://github.com/kostis/otp.git ets-tid-type
> >
> >I got into merge conflicts due to the bootstrap code
> >update and more. I will have to take this tomorrow...
>
> Raimo,
>
> The erl_lint.beam file in bootstrap is nothing special. It is just the
> .beam file that corresponds to the erl_lint.erl file so any such .beam
> file will do.
>
> The only thing that you have to be careful of is to include such a file
> before including the change in lib/debugger/src/dbg_iload.erl

Yes. That I can handle and/or ask Bj
Guest
Posted: Tue Jun 01, 2010 8:21 am Reply with quote
Guest
Raimo Niskanen wrote:
> ++<<<<<<< HEAD
> +-spec load_mod1(module(), file:filename(), binary(), tid()) -> no_return().
> ++=======
> + -spec load_mod1(atom(), file:filename(), binary(), ets:tid()) -> no_return().
> ++>>>>>>> ks/ets-tid-type
>
> load_mod1(Mod, File, Binary, Db) ->
> store_module(Mod, File, Binary, Db),
>
> In your new branch ks/ets-tid-type you use atom() instead of module()
> that was added by ks/cleanups as suggested by tidier. I know that
> the tid() -> ets:tid() change is expected buth the module() -> atom()
> is not my home turf...

You should take the atom() one (or change it manually).

Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Tue Jun 01, 2010 8:22 am Reply with quote
Guest
Raimo Niskanen wrote:
> ++<<<<<<< HEAD
> +-spec load_mod1(module(), file:filename(), binary(), tid()) -> no_return().
> ++=======
> + -spec load_mod1(atom(), file:filename(), binary(), ets:tid()) -> no_return().
> ++>>>>>>> ks/ets-tid-type
>
> load_mod1(Mod, File, Binary, Db) ->
> store_module(Mod, File, Binary, Db),
>
> In your new branch ks/ets-tid-type you use atom() instead of module()
> that was added by ks/cleanups as suggested by tidier. I know that
> the tid() -> ets:tid() change is expected buth the module() -> atom()
> is not my home turf...

You should take the atom() one (or change it manually).

Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Wed Jun 02, 2010 9:21 pm Reply with quote
Guest
Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
However seeing the actual list of predefined types for the first
time:-), I think there are a few more of them that falls in the same
category as tid(), and should be made module-specific for the same
reasons:

{array, 0},
{dict, 0},
{digraph, 0},
{gb_set, 0},
{gb_tree, 0},
{queue, 0},
{set, 0},

E.g. having a predefined type queue(), which can only be defined as "The
opaque type returned by new/0 in the OTP module called 'queue'", and
which prevents all use of that type name in user-written modules (where
it could otherwise exist peacefully as mod:queue()), really doesn't seem
like a good idea to me. I won't argue this point further though.Smile

--Per

Kostis Sagonas <kostis@cs.ntua.gr> wrote:
>
>There is a patch that removes tid() from the list of predefined types.
>It can be included as is provided that the 'export_type' branch is first
>included in OTP. Otherwise, one has to manually remove the line which
>reads:
>
>-export_type([tab/0, tid/0]).
>
>from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type
>
>Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Wed Jun 02, 2010 9:21 pm Reply with quote
Guest
Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
However seeing the actual list of predefined types for the first
time:-), I think there are a few more of them that falls in the same
category as tid(), and should be made module-specific for the same
reasons:

{array, 0},
{dict, 0},
{digraph, 0},
{gb_set, 0},
{gb_tree, 0},
{queue, 0},
{set, 0},

E.g. having a predefined type queue(), which can only be defined as "The
opaque type returned by new/0 in the OTP module called 'queue'", and
which prevents all use of that type name in user-written modules (where
it could otherwise exist peacefully as mod:queue()), really doesn't seem
like a good idea to me. I won't argue this point further though.Smile

--Per

Kostis Sagonas <kostis@cs.ntua.gr> wrote:
>
>There is a patch that removes tid() from the list of predefined types.
>It can be included as is provided that the 'export_type' branch is first
>included in OTP. Otherwise, one has to manually remove the line which
>reads:
>
>-export_type([tab/0, tid/0]).
>
>from file ets.erl
>
>
> git fetch git://github.com/kostis/otp.git ets-tid-type
>
>Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Wed Jun 02, 2010 9:57 pm Reply with quote
Guest
Per Hedeland wrote:
> Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
> However seeing the actual list of predefined types for the first
> time:-), I think there are a few more of them that falls in the same
> category as tid(), and should be made module-specific for the same
> reasons:
>
> {array, 0},
> {dict, 0},
> {digraph, 0},
> {gb_set, 0},
> {gb_tree, 0},
> {queue, 0},
> {set, 0},
>
> E.g. having a predefined type queue(), which can only be defined as "The
> opaque type returned by new/0 in the OTP module called 'queue'", and
> which prevents all use of that type name in user-written modules (where
> it could otherwise exist peacefully as mod:queue()), really doesn't seem
> like a good idea to me. I won't argue this point further though.Smile

Per,

You are absolutely right about this and it is indeed my intention to
take these out from the list of predefined types. However, this is a
bit tricky to do at this point (for various reasons that I will not go
into now) and IMO it is best done when two other features are in place:

1. The ability to write -import_type attributes (analogous to -import)
so that one does not have to write: gb_trees:gb_tree() all over the
place.

2. The ability to have parameterized opaque types, e.g. set(atom())
which is currently not possible.

The first addition is relatively easy and may happen soon. The second
one is a significant change. When these two are in place, we will take
out these types from the list of predefined types.

Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
Guest
Posted: Wed Jun 02, 2010 9:58 pm Reply with quote
Guest
Per Hedeland wrote:
> Thanks a lot for this! Applied with minor tweaks to our R13B03-ish OTP.
> However seeing the actual list of predefined types for the first
> time:-), I think there are a few more of them that falls in the same
> category as tid(), and should be made module-specific for the same
> reasons:
>
> {array, 0},
> {dict, 0},
> {digraph, 0},
> {gb_set, 0},
> {gb_tree, 0},
> {queue, 0},
> {set, 0},
>
> E.g. having a predefined type queue(), which can only be defined as "The
> opaque type returned by new/0 in the OTP module called 'queue'", and
> which prevents all use of that type name in user-written modules (where
> it could otherwise exist peacefully as mod:queue()), really doesn't seem
> like a good idea to me. I won't argue this point further though.Smile

Per,

You are absolutely right about this and it is indeed my intention to
take these out from the list of predefined types. However, this is a
bit tricky to do at this point (for various reasons that I will not go
into now) and IMO it is best done when two other features are in place:

1. The ability to write -import_type attributes (analogous to -import)
so that one does not have to write: gb_trees:gb_tree() all over the
place.

2. The ability to have parameterized opaque types, e.g. set(atom())
which is currently not possible.

The first addition is relatively easy and may happen soon. The second
one is a significant change. When these two are in place, we will take
out these types from the list of predefined types.

Kostis

________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist

Display posts from previous:  

All times are GMT
Page 1 of 1
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum