I use a variation of waterhouse's eval-w/stdout [1] that is essentially the original wrapped in an on-err:

  ; don't especially like name

  (def eval-w/stderr/out (expr)
    (tostring:let result nil
      (on-err (fn (c) (pr "Error: " #\" (details c) #\"))
              (fn ()  (let output (tostring (= result (eval expr)))
                        (unless (empty output)
                          (pr output))
                        (write result))))))

Another question is are you using Arc 3.1 or Anarki?

  (w/stdout (outfile "fileio.txt")
    prn!hello
    prn!world)
  (pr:cadr:readfile "fileio.txt")

Furthermore, even though I think it was vague in the original description of the problem, the complaints indicate that the "world" line should be read into a variable.

So the first thing I tried was this, riffing off of evanrmurphy's version:

  (w/stdout (outfile "fileio.txt") prn!hello)
  (w/stdout (outfile "fileio.txt" 'append) prn!world)
  (pr:= line (string:cadr:readfile "fileio.txt"))

Speaking of bugs, do we even close these file handles?

And what if someone's mysteriously edited the file in between our commands, and we end up reading in a million-line file or barfing on a paren mismatch?

Also, most of the responses seem to use "putStrLn", "println", etc. for displaying the line that was read, even though that sacrifices two characters' worth of brevity. :-p

Let's try that again.

  (w/outfile f "fileio.txt" (disp "hello\n" f))
  (w/appendfile f "fileio.txt" (disp "world\n" f))
  (w/infile f "fileio.txt" (repeat 2 (= line readline.f)))
  prn.line

  (load "lib/util.arc")
  
  ; to be consistent
  (mac w/stdappendfile (name . body)
    (w/uniq gf
      `(w/appendfile ,gf ,name (w/stdout ,gf ,@body))))
  
  (w/stdoutfile "fileio.txt" prn!hello)
  (w/stdappendfile "fileio.txt" prn!world)
  (w/stdinfile "fileio.txt" (repeat 2 (= line (readline))))
  prn.line

  (= lathe-dir* "my/path/to/lathe/arc/")
  (load:+ lathe-dir* "loadfirst.arc")
  (use-fromwds-as ut (+ lathe-dir* "utils.arc"))
  
  (w/outfile f "fileio.txt" (disp "hello\n" f))
  (w/appendfile f "fileio.txt" (disp "world\n" f))
  (w/infile f "fileio.txt" (repeat 2 (= line ut.readwine.f)))
  prn.line

For what it's worth, here's how I'd write it in Groovy:

  def file = "fileio.txt" as File
  file.withWriter { it.writeLine "hello" }
  file.withWriterAppend { it.writeLine "world" }
  def line = file.withReader { it.readLine(); it.readLine() }
  println line

  sc fileio.txt 'hello'
  ac fileio.txt 'world'
  $line = (gc fileio.txt)[1]
  $line

1. It specifically says "Append the second line "world" to the file." Not just print those two lines, but print the first line and then append the second line to the file.

2. Your code doesn't close the output port. This really isn't a problem in a basic example like this, but if you did it repeatedly...

  arc> (repeat 4000 (w/stdout (outfile "fileio.txt") prn!hello prn!world))
  Error: "open-output-file: cannot open output file: \"/[elided]/fileio.txt\" (Too many open files; errno=24)"

  (w/outfile f "fileio.txt"
    (disp "hello\n" f))
  (w/appendfile f "fileio.txt"
    (disp "world\n" f))
  (pr:cadr:readfile "fileio.txt")

True, but then under Clarification, it says: "You don't need to reopen the text file after writing the first line." I'd thought that continuous write would pass for writing and then appending with the same file open, but I guess it doesn't.

The non-closed output port is a very good point though, and that disp makes it shorter is clever.

---

  (w/infile f "fileio.txt"
    (pr:cadr:lines:allchars f))

  ; Or, though this doesn't close the input port:
  (pr:cadr:lines:allchars:infile "fileio.txt")

  ; Both of the above, though fun, will read all characters
  ;  in the file, only to return the second line. Better:
  (w/infile f "fileio.txt"
    readline.f
    (prn readline.f))

  (w/infile f "fileio.txt"
    (repeat 2 (= l readline.f))
    (prn l))

  4. Read the second line "world" into an input string.
  5. Print the input string to the console.

Never fear! I'll show up to flog this horse in the nick of time! Y'know, before rigor mortis sets in.

Here's another I/O utility I think would be useful.

  (def readlines (n (o str (stdin)))
    (let line nil
      (repeat n (= line (readline str)))
      line))

  (tofile   "fileio.txt" (prn "hello"))
  (ontofile "fileio.txt" (prn "world"))
  (fromfile "fileio.txt" (prn (readlines 2)))

  (def all-lines ((o str (stdin)))
    (drain (readline str)))

  (def filelines (name)
    (fromfile name (all-lines)))

  (w/stdoutfile "fileio.txt"
      prn!hello
      prn!world)
    (pr:cadr:readfile "fileio.txt")

Then, using readline instead of readfile so that it (1) doesn't try to parse things as s-exprs and (2) doesn't read the entire file for no good reason, I'd envision it thus:

  (tofile "fileio.txt" (prn "hello"))
  (appendfile "fileio.txt" (prn "world"))
  (fromfile "fileio.txt" (readline) (pr (readline)))

  (mac tofile (f . body)
    (w/uniq gf
      `(w/outfile ,gf ,f
         (w/stdout ,gf
           ,@body))))
  (mac fromfile (f . body)
    (w/uniq gf
      `(w/infile ,gf ,f
         (w/stdin ,gf
           ,@body))))

As to waterhouse's suggestions, I had considered those names. I suppose if you read appendfile as a noun instead of a verb-and-noun, it's confusing (though infile and outfile don't really have the same problem, so it's not the train of thought my brain follows). It's hard modifying a name like tofile with a long word like append. We already have two words in tofile, so adding a third without hyphenation is stretching it, and adding hyphens breaks the flow with the other names (fromfile, tostring, etc.). We could go for something shorter, like addtofile, which delineates itself well without hyphens because each word is one syllable. If we can't avoid hyphens, using / instead (e.g., tofile/a or tofile/append) flows better, but isn't that great.

+1! ontofile is a great name, in my opinion, for all the reasons you listed.

Hahaha! Or worse: http://www.urbandictionary.com/define.php?term=fap :P

filepend is decent, but I think I prefer ontofile.

That's a good idea. I'm still using MzScheme 4.2.1. (Although before I go to the trouble, maybe I should skim recent release notes to see if they were supposed to have fixed any memory leak.)

One resource that really helped me learn faster was rntz's help system, available in Anarki [2]. It's very convenient because it gives you access to documentation right at the repl:

  arc> help.acons
  [fn]  (acons x)
   Determines if `x' is a `cons' cell or list.
      Unlike 'alist, this function will return nil if given an empty list
      See also [[atom]] [[alist]] [[dotted]] [[isa]] [[cons]] [[list]] 
  nil
  arc> help.alist
  [fn]  (alist x)
   Return true if argument is a possibly empty list
      Unlike 'acons, this function returns t when given an empty list
      See also [[atom]] [[acons]] [[dotted]] [[isa]] [[cons]] [[list]] 
  nil
  arc> help.afn
  [mac] (afn parms . body)
   Creates a function which calls itself with the name `self'.
      See also [[fn]] [[rfn]] [[aif]] [[awhen]] [[aand]] 
  nil

[1] Or Java (http://github.com/conanite/rainbow, http://jarc.sourceforge.net/), or JavaScript (http://jonathan.tang.name/files/arclite/index.html), or Arc itself (http://arclanguage.org/item?id=11128). ^_^ I think someone did a port to Common Lisp not too long ago as well, but I can't find the link.

Well put. My thoughts exactly. The suggestion wasn't necessarily to learn Arc by spending a couple days reading the source. I mean, that's what I did, but I was already familiar with Common Lisp. Just that once you reach a certain point (as Preston seems to have), it's not so daunting to say "hey, I wonder what filechars does?" and go read

  (def filechars (name)
    (w/infile s name (allchars s)))