Arc Forumnew | comments | leaders | submitlogin
2 points by palsecam 5528 days ago | link | parent

Very interesting.

> it's useful to pass your arguments through some kind of a filter

A quite common pattern, at least in my programming experience.

However, like rntz, I'm not sure using ssyntax to do that is a Good Thing. But what about a special form "c"(check) like "o"(ptional)?

  arc> (def2 some ((c test testify) seq)
         (if (alist seq)
             (reclist test:car seq)
             (recstring test:seq seq)))
The first arg to "c" would be passed to the second arg, and the result of it would be bound back to the first arg. Or, if there an error, well, throw it.

----

Other notes: I hate to freely criticize, but the defs of 'some, 'find and co are sooooo ugly because of the string/list dichotomy. Not clean for a "code is the spec"-based language. And not extensible. Arc has a problem w/ the overloading issue. See also: 'map doesn't work for tables, but 'each does (my and some news.arc code would benefit from 'map working w/ tables [currently it uses 'accum & 'maptable]). See also: the def of 'each is also ugly/unextensible. See also: queues and the functions to manipulate them, like 'qlen, that have ugly names because you can't add "methods" to 'len. See also: 'rev doesn't work for strings?!!

'testify... Idea in the wild: make (coerce anAtom 'fn) do what 'testify does.