3 ms·
Well, you asked for it, so: the #t gives away that you're more comfortable with Scheme than with Lisp, I suppose those string functions are present in some Sch
by guenthert 6y ago
Well, you asked for it, so: the #t gives away that you're more comfortable with Scheme than with Lisp, I suppose those string functions are present in some Scheme dialect as well, but they sure aren't in Common Lisp (not with that syntax at least). Scheme is quite dogmatically a functional programming language, Common Lisp is decidedly a multi-paradigm language. With that it shouldn't surprise that the article's author chose to write into a string in an imperative programming style. I don't think it would raise eyebrows in the Common Lisp community. There's more than one way to do it.
- mst 6y agoThe string functions were basically invented to allow me to express the algorithm, though a friend of mine who writes clojure looked at the original problem and produced an implementation that was logically similar to mine that used actual clojure functions that behave basically like that. I tend to do single assignment and minimal mutations in any language though, and try and push my side effects (I'm aware the string write is encapsulated therefore not a side effect) as far out to the edge as possible. As an example, in perl (which is probably my most-used language, so I'm 100% on board with "more than one way to do it" ;) I'd've written: sub add_text_padding ($str, $padlevel) { my ($first, @rest) = split /\n/, $str; my $pad = ' ' x $padlevel; join "\n", $first, map $pad.$_, @rest; } (my lisping has indeed been significantly in scheme, plus dabbling in other dialects and a tendency to prototype things in operative lisps derived from Shutt's kernel ... which is why I did, indeed, ask for it, so thank you for the reply)