On Wed, Jan 23, 2013 at 6:20 PM, ノートン ジョーセフ ウェイ ン <[email protected] > 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 <[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
