Re: [Scheme-reports] Question regarding R7RS draft 8 regarding section 1.3.3 Entry format

[Alex Shinn <alexshinn@x>]

On Wed, Jan 23, 2013 at 6:20 PM, ノートン ジョーセフ ウェイ ン <norton@x
> wrote:

>
> Alex -
>
> Sorry if my e-mail was not clear.
>
> I hope this example can illustrate what I was trying to say.
>
> The current report has:
>
> (floor/ n1 n2)                        procedure
> (floor-quotient n1 n2)         procedure
> (floor-remainder n1 n2)     procedure
>  :
>
>
> The prototype could be changed as follows:
>
> (floor/ n1 m2)                        procedure
> (floor-quotient n1 m2)         procedure
> (floor-remainder n1 m2)     procedure
>  :
>
> since it is an error if n2 is zero.
>
> m2 (or m, m1, m3, … etc.) could represent a non-zero integer.
>
>
> More specific prototypes (where relevant) could be friendlier for the
> reader.
>

Ah, I see.  I think there is no convention for this, though,
so it would be hard to remember.  Also since it's only really
used for a few procedures in one place it's better to explain
the domain clearly where it is used.

One can carry a good idea too far...

-- 
Alex


>
> thanks,
>
> Joe N.
>
>
> On Jan 23, 2013, at 17:43 , Alex Shinn <alexshinn@x> wrote:
>
> On Wed, Jan 23, 2013 at 4:30 PM, ノートン ジョーセフ ウェイ ン <
> norton@x> wrote:
>
>>
>> Alex -
>>
>> Thanks for your feedback/comments.
>>
>> Based on my partial review of the prototypes, the naming conventions used
>> to imply type restrictions could benefit from having the following
>> additions:
>>
>>   false
>>     #f boolean value
>>
>>   j, j~1~, ... , j~k~, ...
>>     exact non-zero integer
>>
>>   m, m~1~, ... , m~j~, ...
>>     non-zero integer
>>
>> This would help clarify the expected arguments and/or return value(s).
>>   NOTE: I choose j and m arbitrarily.
>>
>
> I think you misunderstand the purpose of the naming conventions -
> they document the conventions used in the report.  So they shouldn't
> be chosen arbitrarily but follow from the prototypes, and we don't
> currently use any of those names.
>
> --
> Alex
>
>
>>
>> thanks,
>>
>> Joe N.
>>
>> On Jan 22, 2013, at 11:56 , Alex Shinn <alexshinn@x> wrote:
>>
>> On Mon, Jan 21, 2013 at 3:12 PM, ノートン ジョーセフ ウェイ ン <
>> norton@x> wrote:
>>
>>>
>>> Hello.
>>>
>>> During my review of R7RS, I have felt that it would be friendlier to the
>>> reader if explicit return types for all procedures were added as part of
>>> the standard entry format.
>>>
>>> For example ...
>>>
>>> (number? obj) -> boolean
>>> (max x1 x2 …) -> x
>>> (inexact z) -> z
>>> (exact z) -> z
>>>   :
>>>   :
>>>
>>> I realize this information is included in the english description for
>>> each procedure.
>>>
>>> Has this type of change been considered before (or not)?  I'm new to
>>> this mailing list so I apologise if this has been discussed before.
>>>
>>
>> It's a likely change, though I don't recall it having been brought
>> up before.
>>
>> The primary objection would be that we already have a lot of
>> info on one line (name, argument types, library name and
>> procedure/syntax).
>>
>> It's also not very useful once you're familiar with the
>> conventions.  Names ending in '?' are predicates and
>> always return booleans, <type> and make-<type> return
>> a <type>, arithmetic operators all return complex (in some
>> cases with a range that can't be summarized on one line).
>>
>> And in other cases the description is short and the return
>> type mentioned soon enough after the prototype.
>>
>> So I'd have to see a sample change on one of the busier
>> prototypes to see how this looks.  If someone wants to
>> make the change I'll take a look - not sure if I'll get around
>> to it myself.
>>
>> [Although I will update scheme-complete.el which will show
>> you the return type in eldoc-mode.]
>>
>> --
>> Alex
>>
>>
>>
>
>

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports