Talk:Function annotations

concerning the "no print statements"

I probably agree with the intended, but not completely with the literally written phrase:

related to this is the request that functions do /not/ involve some kind of 'print' statements.

Consider for example the quite frequent situation where the natural (if not only) way to compute a(n) is to compute all preceding terms. Now several types of implementations are possible. I found that the following scheme has the benefit of being short & simple yet useful in practice:

Axxx(n, show=0, a=1)={ my( nxt = x -> ... );     \\ use 2nd or 3rd optional arg to print intermediate
 for(k=2,n, if(show, print(a",")); a=nxt(a)); a } \\    values or to use another starting value

Then Axxx(n) will indeed yield a(n), but Axxx(n,1) will print out ("for free") a(1),...,a(n-1) before returning a(n). There may also be other cases and applications where some optional verbosity involving print() commands does not lengthen the code yet adds at least a nice feature if not genuine fuctionality. — MFH 01:08, 4 December 2015 (UTC)

Knowing Mathematica and being barely familiar with Maple, I'm confused by this. For Mathematica in the OEIS, Print is generally used for computing sequences that take a lot of system resources to compute, so that each term is displayed as soon as it's obtained, rather than having to wait for the program to reach the designated threshold to display all the terms. This way, if the program crashes, you at least get some kind of result. For keyword:easy sequences, use of Print is absurd and unnecessary. Alonso del Arte 03:04, 4 December 2015 (UTC)

very good start!

I think this is an excellent start, thank you. I subscribe to the whole (I)ntroduction to 99% - 200%. Since most is already said in your (I)ntroduction, one might wonder what is left for other parts (II) - (???). One could imagine a section (II) developing pro's and con's concerning each of the suggested guidelines, and a section (III) listing particularities of specific programming languages.

PS1: there is a nonempty intersection with http://oeis.org/wiki/User:Charles_R_Greathouse_IV/Programs, but I'm strongly supporting your (5) which advocates in favour of Axxx() vs a().

PS2: Concerning coding conventions, I wish to express a feeling of injustice of (Haskell) vs (PARI) code. Most Haskell contributions take at least 3 lines because they read

(Haskell)
aXXX = ...
-- Author, Date

while (even lengthy) "PARI" contributions are formatted as

(PARI) Axxx = ... \\ Author, Date

although there is absolutely no reason for this difference, since all things are equal except that "--" is replaced by "\\" with exactly the same functionality and syntax. — MFH 02:29, 4 December 2015 (UTC)