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. thanks, Joe N. On Jan 23, 2013, at 17:43 , Alex Shinn <[email protected]> wrote: > On Wed, Jan 23, 2013 at 4:30 PM, ノートン ジョーセフ ウェイ ン <[email protected]> > 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 <[email protected]> wrote: > >> On Mon, Jan 21, 2013 at 3:12 PM, ノートン ジョーセフ ウェイ ン >> <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
