R is such a vast landscape of complexity and that makes it easy to think there has no simplicity.
To check on the immediate feedback from the error
`?? export.asc
which confirms that it's missing and code using it will fail.
But that's only the most immediate problem. Usually, the hardest problem in troubleshooting R is coming up with the right question. Let's ask, instead
What is the difference between csv and asc and why do we care?
The easy answer is that we care if some resource we need demands one form rather than the other.
The difference lies in the purpose. A csv format is a layout convention (comma separated values) for data. The data can, in theory, be anything, but in practice is limited to numbers and characters. Discrete pieces of the data are generally separated by commas (corresponding to column variables) and newlines (corresponding to rows). It's a universal format because every system likely to open a csv file can do so with just the resources available from the operating system.
An asc file has no format expectations. It reflects a coding convention. It will happily read csv files but does not require delimiters. It does, however, impose an encoding restriction—all bytes must be encoded within a 128 character convention. The allowable characters include the 96 numbers, symbols and unaccented lower- and upper-case letters appearing on keyboards. No diacritical marks, no Greek, Cyrillic or other characters allowed; if included they will show up with a single symbol signifying "huh?"
The code reads Distance_Spring_2000_2010.csv and assigns it to the object distance. From distance it constructs data frame named csv that contains three variables from the distance file and then proceeds to convert it to a matrix object. Finally, failed attempts are made to use csv as an argument to the missing export.asc and as.csv functions.
Every R problem can be thought of with advantage as the interaction of three objects— an existing object, x , a desired object,y , and a function, f, that will return a value of y given x as an argument. In other words, school algebra— f(x) = y. Any of the objects can be composites.
Here, x is the csv object. In default of any other information, it must be assumed that y is identical to x but for its character encoding. If that is the case, the part of f can be played by iconv
x <- c("Ekstr\xf8m", "J\xf6reskog", "bi\xdfchen Z\xfcrcher")
Encoding(x) <- "latin1"
x
#> [1] "Ekstrøm" "Jöreskog" "bißchen Zürcher"
try(iconv(x, "latin1", "ASCII//TRANSLIT")) # platform-dependent
#> [1] "Ekstrom" "Joreskog" "bisschen Zurcher"
I've been didactic, however. It looks that what you really want is the long/lat coordinates and the distance (to be renamed Cadmium back on disk as a csv file that can be read in later.
If that's the case
csv <- data.frame(x = distance$lon, y = distance$lat, cadmium = distance$distance)
write.csv(csv, file = "mycsv.csv")
If you want to deal with encoding
write.csv(csv, file = "mycsv.csv", encoding = "ASCII")
but if these data are all numeric, that should not be a concern.
Consider using {readr} for better csv facilities and {sf} for easier integration of GIS with other data.