Re: add compiler checked atoms
Richard Carlsson <[email protected]> Thu, 1 Dec 2016 22:22:49 +0100
| Newsgroups | gmane.comp.lang.erlang.patches,gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <CANKG3zkKYJb+DkMaQGuCXAtREL5McRDZSKokh81h2snYrYhsWA@mail.gmail.com> |
--===============1307145388676932374==
Content-Type: multipart/alternative; boundary=001a114017ce73af6e05429f6ce4
--001a114017ce73af6e05429f6ce4
Content-Type: text/plain; charset=UTF-8
Wow, time flies... has it been that long? Anyway, I found this old branch
and decided to rework it like Kenneth suggested. Here's the PR:
https://github.com/erlang/otp/pull/1265
/Richard
2012-02-14 12:24 GMT+01:00 Kenneth Lundin <[email protected]>:
> I think atoms introduced in both -type and -spec should be respected in
> this feature. If you want to
> guard yourself against a misspelled atom in one -spec you can use -type
> but you are not forced to.
>
> And if you introduce an atom in a -spec and never use it in the code then
> you could maybe issue a warning for that too.
>
> /Kenneth
>
> On Tue, Feb 14, 2012 at 10:47 AM, Richard Carlsson <
> [email protected]> wrote:
>
>> On 02/14/2012 09:44 AM, Kenneth Lundin wrote:
>>
>>> Hi,
>>> I don't think this is a good way to introduce declared atoms.
>>> We already have the -type and -spec notation for definition of
>>> types and function signatures which are then used by Dialyzer for type
>>> checking.
>>> I don't think we should introduce yet another notation that is not
>>> harmonized with -type and -spec.
>>> It is already possible to declare atoms in -type and -spec. Why not use
>>> this already present notation and add
>>> optional checking of atoms against declared atoms inside -type and -spec
>>> instead.
>>> With the suggested -atom declaration we will probably get the same atoms
>>> declared 2 times with different notations and I think that
>>> will clutter down the code with redundant information to an
>>> unacceptable degree.
>>>
>>
>> Yes, that is probably a better idea: that any atom occurring in a -type
>> and/or -spec declaration is implicitly said to be known, and others are
>> not. This would be an incentive for people to define types for things like
>> the set of messages to a server or the set of atoms allowed as flags to a
>> function (or error codes returned from a function).
>>
>> The question is, should atoms occurring in -spec declarations be taken as
>> implicit "exists"-declarations, or should it only be those in -type? If
>> it's only -type that counts, you could get checking of the atoms in -spec
>> declarations as well, so you don't spell an atom wrong in the spec for one
>> of 3 versions of a function and suddenly that atom is also implicitly
>> allowed. I think -type only is the right way.
>>
>> I'll see if I can change my patch to do this instead.
>>
>> /Richard
>>
>
>
--001a114017ce73af6e05429f6ce4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Wow, time flies... has it been that long? Anyway, I found =
this old branch and decided to rework it like Kenneth suggested. Here's=
the PR: <a href=3D"https://github.com/erlang/otp/pull/1265">https://github=
.com/erlang/otp/pull/1265</a><br></div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><div class=3D"gmail_signature" data-smartmail=3D"gmail_signat=
ure"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /Richard</div></div>
<br><div class=3D"gmail_quote">2012-02-14 12:24 GMT+01:00 Kenneth Lundin <s=
pan dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a>></span>:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div>I think atoms introduced in both -type and -spec should be resp=
ected in this feature. If you want to </div>
<div>guard yourself against a misspelled atom in one -spec you can use -typ=
e but you are not forced to.</div>
<div>=C2=A0</div>
<div>And if you introduce an atom in=C2=A0 a -spec and never use it in the =
code then you could maybe issue a warning for that too.</div>
<div>=C2=A0</div>
<div>/Kenneth<br><br></div>
<div class=3D"gmail_quote">On Tue, Feb 14, 2012 at 10:47 AM, Richard Carlss=
on <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" targ=
et=3D"_blank">[email protected]</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT:1ex;MARGIN:0px 0px =
0px 0.8ex;BORDER-LEFT:#ccc 1px solid"><span class=3D"">
<div class=3D"m_-5983025024420299269im">On 02/14/2012 09:44 AM, Kenneth Lun=
din wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT:1ex;MARGIN:0px 0px =
0px 0.8ex;BORDER-LEFT:#ccc 1px solid">Hi,<br>I don't think this is a go=
od way to introduce declared atoms.<br>We already have the -type and -spec =
notation for definition of<br>
types and function signatures which are then used by Dialyzer for type<br>c=
hecking.<br>I don't think we should introduce yet another notation that=
is not<br>harmonized with -type and -spec.<br>It is already possible to de=
clare atoms in -type and -spec. Why not use<br>
this already present notation and add<br>optional checking of atoms against=
declared atoms inside -type and -spec<br>instead.<br>With the suggested -a=
tom declaration we will probably get the same atoms<br>declared 2 times wit=
h different notations and I think that<br>
will clutter down the code with redundant information to an<br>unacceptable=
degree.<br></blockquote><br></div></span>Yes, that is probably a better id=
ea: that any atom occurring in a -type and/or -spec declaration is implicit=
ly said to be known, and others are not. This would be an incentive for peo=
ple to define types for things like the set of messages to a server or the =
set of atoms allowed as flags to a function (or error codes returned from a=
function).<br>
<br>The question is, should atoms occurring in -spec declarations be taken =
as implicit "exists"-declarations, or should it only be those in =
-type? If it's only -type that counts, you could get checking of the at=
oms in -spec declarations as well, so you don't spell an atom wrong in =
the spec for one of 3 versions of a function and suddenly that atom is also=
implicitly allowed. I think -type only is the right way.<br>
<br>I'll see if I can change my patch to do this instead.<br><font colo=
r=3D"#888888"><br>=C2=A0 /Richard<br></font></blockquote></div><br>
</blockquote></div><br></div>
--001a114017ce73af6e05429f6ce4--
--===============1307145388676932374==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches
--===============1307145388676932374==--