@sigue @lisp_discussions

Right.

Documenting requires some self-discipline, too.

May I offer two adages:

If it's not documented, it doesn't exist.

If it's not worth your time documenting your software, is it worth my time figuring out how to use it?

#CommonLisp
#SoftwareDocumentation

@lisp_discussions

What a useful article! And I completely agree with his introductory comments about the state of #CommonLisp documentation.

@hajovonta @sigue @nytpu

vnikolov> never mind that [`loop'] can't do sequences generically

hajovonta> I'm not sure how to interpret that, loop can iterate over lists, arrays, vectors, hashtables, ...

Not _generically_.
With `map', whether the arguments are lists or vectors can be known as late as run time.
With `loop' that must be known no later than compile time.

hajovonta> I can't think of other kind of sequences

By the way, non-vector arrays and hash tables aren't sequences.

@hajovonta @sigue @nytpu

(Continued.)

And today in most (though not all) cases the importance of performance is secondary to that of clarity, ease of change, and obviousness of the absence of bugs.

> [`loop'] is more versatile [than `map'] in terms of debugging and error control.

Sometimes at the expense of other qualities, such as clarity.
#ThereAreAlwaysTradeoffs

> I like that we have more options.

Right.

@hajovonta @sigue @nytpu

> abandoned map and its brothers when I learned loop has the same performance

Each has its uses and they are seldom equivalent replacements for each other.

For a very quick example,

(map 'list f xs)

is both clearer and more concise than

(loop for x in xs collect (funcall f x))

(never mind that the latter can't do sequences generically)
and so on regarding good use cases for each.

Continued.

@sigue @nytpu

> #DylanLang has separate functions for map, map-as, and do.

That is certainly a justifiable different design approach (than #CommonLisp's).

@sigue @nytpu

> We don't always learn every construct in a language by staring at the spec.

I'd say "hear about".
Learning is a stronger proposition.

> Frequently (thankfully) it's clear from the argument list

I'd say "(only) seems clear".

> The problem here is that (map nil ...) is completely unintuitive.

Partly, perhaps, but not completely.
This second argument means that it returns nothing, because nothing is of type nil.
Therefore it must be called for side effect.

@h4ckernews I usually have a much simpler requirement: I need to select a field from a JSON structure returned by an API.

I wrote a simple function that recursively iterates the structure, like this:

(select-field '(:node1 :node2 :node3) json-list)

I connected this to the cl-json output.

Works very reliably, although not an optimized approach.

@screwtape

P.S. My (non-authoritative) reading of the specification is that JavaScript tagged templates (function calls of backquote-delimited forms) can _only_ be _literals_ and can't be constructed at runtime.
Therefore I would definitely avoid an explicit call to `eval' in the lisp translation and just arrange for the placeholder expressions to be in for-evaluation positions.

#CommonLisp
#EvalOnlyWhenJustified
#JavaScript

@screwtape

The S-expression version seems to me to have too much nesting and extra quoting.

@tealeg @me

tealeg@mastodon.online> the specific macro expansion can differ though, right?

Yes, and it often does (and it may well contain implementation-specific items, of course).

And `macroexpand' is certainly a good way to explore things; just consult the specification as well (in this case the excellent Hyperspec, CLHS).

#CommonLisp
#CommonLispHyperSpec

@tealeg @me

Just a sidenote, but `in-package' and Co. are Common Lisp things, not just SBCL's.
And `*package*' is mainly used by the reader.

@me I guess you could fairly easily write a macro that automatically created a lexical scope and added some prefixes to variable used within its body - Doug Hoyte's "Let over lambda" book has #CommonLisp examples of this kind of approach as way to cut down the syntactic overhead of using gensym in macros. Without much thought, I'd assume something similar could be done in #EmacsLisp