Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

callout defining function #46

Merged
merged 1 commit into from
Jul 17, 2015
Merged

Conversation

SamPenrose
Copy link

To address Issue #26

@SamPenrose
Copy link
Author

p.s., I also wrote this (per the issue), but I don't actually think its an improvement over just getting into the example:

Functions take the form:

function_name <- function( parameters ) function_body

where:

  • function_name what the programmer has decided to call her function
  • parameters is an optional list of named values the function accepts as input
  • function_body is a sequence of expressions

You invoke a function by entering its name followed by the call operator, a pair of parentheses: "()". If the function takes parameters, they go inside the parentheses. R will then execute the function's body, expression by expression. If you assign the result of the function to a variable:

x = some_function('some', 'parameters')

then, when the function finishes executing, whatever it returns will be stored in that variable. By default, R functions return the last evaluated expression. Many functions use the return keyword to send a specific object back to the caller.

@aammd
Copy link
Contributor

aammd commented Jun 5, 2015

I really like this Callout! I made a few line notes.

I have pretty mixed feelings about this "imitation syntax" approach that I've seen sometimes:

function_name <- function( parameters ) function_body

Because it doesn't really resemble actual syntax (ie no {), I'm not sure it doesn't generate more confusion than it solves. But that is just an hypothesis

@sritchie73
Copy link
Contributor

I think its a really good idea to have this callout: I'd even suggest putting it in the very first topic after the first instance where an instructor calls a function.

I'm also not a fan of the "imitation syntax". Novices seem to struggle with pseudocode, its too abstract for them to understand, especially since they've been hammered with lots of new concepts.

@hdashnow
Copy link
Contributor

hdashnow commented Jun 7, 2015

I think showing the general form of a function is pretty important. But I agree pseudocode can be confusing for beginners. How about something like this? It's still very general, but at least the code would run.

Functions take the form:

function_name <- function( input ) {
    result <- input + 1 # The body of the function. 
    return( result ) # Optional return statement
}

@sritchie73
Copy link
Contributor

I like it!

@aammd
Copy link
Contributor

aammd commented Jun 8, 2015

I really prefer this. Now we have a function that is instructive for beginners, while not being distressing to people who already write functions. I will resolve whatever conflicts (!) we have here and merge this.

@aammd aammd self-assigned this Jun 8, 2015
aammd added a commit to aammd/r-novice-gapminder-1 that referenced this pull request Jul 16, 2015
@aammd aammd merged commit 2c05908 into swcarpentry:gh-pages Jul 17, 2015
rgaiacs pushed a commit to rgaiacs/swc-r-novice-gapminder that referenced this pull request May 6, 2017
Minor correction: Author of "Thinking Physics"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants