Macro-writing challenge

Write a macro check-arguments-non-nil to be used in function definitions, that would expand to assertion about every argument being non-nil.
The intended usage of this macro:

(defun foo (a b c d)
(check-arguments-non-nil)
foo-body)

This should expand to:

(defun foo (a b c d)
(assert (and (not (null a)) (not (null b)) (not (null c)) (not (null d)))
(a b c d)
"Null argument in FOO")
foo-body)

The macro must work whatever the number and names of the function parameters.

>>40
You're starting to grasp the reason Lisp has failed: macros are fundamentally uncompositional, in many ways. Unwanted capture is one of them, but there are others. For example, it's possible to define a custom defun or defmacro, but it's not possible to combine arbitrary customizations. Another way macros are non-compositional is they often don't accept other macros as arguments, even though those macros may expand to what the outer macros expect.

>>41
So you can't define this
#defime runmacro(macro,args...) macro(args)
in Lisp?

>>42
Yes you can. >>41's "often" means shit Lispers who just took a course in Scheme in school and don't know what they're doing.

(defmacro runmacro (macro &rest args)
`(,macro ,@args))

Of course, this is an exploded form to be more descriptive. It is effectively a no-op that degenerates to (defmacro runmacro (&rest form) form).

>>43
What about this one:
#define runmacro2(macro,code1,code2,args...) ({code1;code2=macro(args);})

>>44
C preprocessor macros are just string replacement. Lisp macros are full functions which receive an AST and return an AST, and have the full power of the language available at "compile time". The various quotes and commas are standard Lisp list processing shorthand, which apply to source code AST just as they would any other list-based "normal" data.

About the only time you'll be able to do something in a C macro that you can't 100% directly do in Lisp is when your macro leaves an open brace or something sub-syntactic like that, expecting to use multiple C macros in tandem at the beginning and end of a block. In that case, the Lisp macro would simply wrap the full body, doing whatever it wants to the beginning, end, or even nested contents of the code, lexically and semantically containing the scope of the code it's affecting.

(defmacro run-macro-2 (macro expr1 expr2 &rest args)
`(progn
,expr1
(setf ,expr2 (,macro ,@args))))

41
43
45

You say Lisp has failed, what is the alternative? If there is no alternative, can one be made?
How would you fix this?

>>45
Does lisp allow this one use of the macro:
#define abc(x1,y1,z1) (z1+(x1*y1));res+x+c
#define runmacro2(macro,code1,code2,args...) ({code1;code2=macro(args) ;})
p("result is ",runmacro2(abc,;u8 c=1;,;u4 x=c+23;u8 res,1,2,4));//p prints arguments(this prints "result is 31")

>>46
Lisp hasn't failed, its just has "standards" on how to compose macros. Lisp macros are parsed at later stage than C macros: that means they have to obey more rules.
The way to fix this is to write Lisp program that manipulates text(preprocessor in Lisp) and feed it back to Lisp interpreter/compiler.
C preprocessor is more powerful only in the sense its unrestricted by anything(at actual macro processing its quite slow and primitive).
With one minor change C preprocessor would be made quite powerful, see:
http://w11.zetaboards.com/frozenbbs/topic/11501531/
for proposal.

>>47
..to add, with _TokenOf() not only this becomes more powerful than C++ constexpr, but allows to implement anything BoostPP/ChaosPP/OrderPP does to simulate functional programming as simple macros.
Its basically eval() (apply-type decomposition is already implemented in apply.h and apply2.h subheaders of void.h) without any restrictions of parser stage(like Lisp eval).

>>46
>>41 (anti-lisp) is not >>43,45 (pro-lisp).

>>47
The entire Lisp syntax is implemented in character-by-character "reader macros", which are extensible to whatever you want at the raw syntax level. You can literally do infix Unicode mathematical operators, Python-style indentation awareness, whatever you want.

Beyond AST macros and reader macros, there's also compiler macros offering optional optimization-based equivalent transformations. There's plenty of ways to customize Common Lisp.

Regarding that C macro, I'm not even going to bother trying to parse that garble. At first glace, though, I will say it's generally bad form for macros to blindly insert local variable names into whatever it's generating, partially because in Lisp they're not just strings but symbols (which are interned & namespaced, and the macro & usage can be in different namespaces). The first step in converting it to Lisp would be to untangle that mess into a more sane expression.

>>49

which are extensible to whatever you want at the raw syntax level.
At first glace, though, I will say it's generally bad form for macros to blindly insert local variable names into whatever it's generating

Do you see there are some limits inherent in parsing stage? Even at AST-level you can't have the freedom to manipulate lexer-level tokens.

>>50
If you want to manipulate at the lexer level from inside a macro, then convert to string and drop back to re-reading it with a different interpretation. Or use the reader from outside before the macro invocation, which would be a lot cleaner.

BTW, blind insertion of variable names is absolutely possible, it's just ugly, both in C and in Lisp.

The real problem you're running into is trying to perform literal C preprocessor hacks in another language. Instead, in reality one would take a step back, figure out what you're seeking to accomplish semantically, and implement those semantics cleanly & directly. C forces you to hack them in, but you're free from that outside of C.

>>50
Oh, and if by "manipulate lexer-level tokens" you mean things like concatenating symbols, or adding up numbers at compile-time, that's kind of the definition of having the entire language available during macro expansion. You can do whatever you want to the code. You could convert (foo bar baz) into an array containing the two symbols #(foo53bar baz-blah) without dropping back into the string reader, but by directly manipulating the data items from the source.

>>52
Whatever Lisp does is incredibly cryptic and non-intuitive while C preprocessor does it simple concise way without "reader macros" "string readers" and
doesn't require the code to be in format of (foo bar baz).
I actually considered using Eudoxia Lisp preprocessor for C but found its useless in most of cases and require writing more code of greater complexity.

>>53
Lisp macros are definitely not non-intuitive.

(check (em (dubs)))))))))))))))

>>53
It is literally the difference between using an actual programming language, and simple string concatenation syntax. The latter can do simple shit easily, but everything beyond that is bad hacks that are better served in an actual computing language.

>>56
Simple things should be simple, complex things should be possible.

most coders don't have the good taste or intelligence to use macros well.

they want to make random procedures macros for "fast". and just basically they have no fucking clue what they're doing. it's terrible.

C macros are wasted on these people. lisp macros are a universe they will never even observe.

>>58
However some small parts of "awesome Lisp power", could be introduced in form of _TokenOf() which doesn't require embedding Lisps in C preprocessor.
Its basically extending https://en.wikipedia.org/wiki/The_lexer_hack to feed back tokens of evaluated C constant expression(or unevaluated tokens if evaluation stops),like C++ constexpr but more powerful due being at earlier stage of source processing.

>>59
Lisp macros are way more readable than that executable C preprocessor macro cobbled together shit.

>>60
(Lisp(((macros are))) way()(( more) ((readable than that executable))) C (preprocessor macro ((cobbled (together shit))).))

>>61
how did you find /prog/?
what is it that drew you here?
what made you consider about posting?

please answer so we can fix them!

>>62

please answer so we can fix them!

If you "fix it", /prog/ would be a boring circlejerk staffed by self-important Lisp weenies who get triggered on slightest disagreement or anything that deviates from the autismal thought patterns.

>>63
61 is reddit-tier normie coder

/prog/ would be a boring circlejerk staffed by self-important Lisp weenies who get triggered on slightest disagreement or anything that deviates from the autismal thought patterns

wow sure wouldn't want that to happen, it sounds terrible

>>63
That's exactly how it should be.

That said, >>61 faggot has presented a valid (and biting) satire of the LISP weenies.

>>66
it's not valid, it's like I'm on reddit and someone posted a cool link that happens to be in lisp and some retard comes out with his hilarious joke about how lithp use brackets. It's extremely predictable, unfunny and tiresome. It's one of the things normals do to help push things like lisp aside and keep them marginalized so they don't have to bother learning them.

I like how /jp/ immigrants will bitch and moan about people's usage of the quote feature, but you won't hear a peep from them when people say completely idiotic reddit-tier shit about ``hurrrr durr lisp too many brackets''. I guess since they're not capable of complaining about the actual meaning of something they have to resort to complaining about its syntax.

SIN TAX MY ANUS

>>69
Anii are not a sin, therefore they can't be sin taxed.

>>67,68
Parens hell)))))))))))))))) is annoying, and counting parentheses is a pain in the anus when not using an editor with highlighting. If I recall correctly, Symta does something about that though.

I have never been to Reddit other than to shitpost, spam, and harass people, so I am unsure if how they react to Lisp. But no matter how they do it, it is a consequence to not achieving Satori, which causes all sorts of undesirable behavior such as mocking Lisp unjustly and abusing the quote feature, but that those things may also have other root causes; mockery of Lisp weenies is a healthy thing to do from time to time, otherwise they will become to arrogant.

Using the idea from Clean Code principles,
just make Lisp functions/macros very short, composed of other macros(i.e. maximum length of 2-3 lines).
Those giant Lisp expressions if separated into clear, small segments, would be as easy to read as any C expression.

>>72
But C is unreadable! All those semicolons, braces, and commas splattered all over the code are too much of a pain for any programmer to deal with!

>>73
C provides visual cues, diverse syntax that you could decode with minimal knowledge. These commas/braces/semicolons that Lisp/Haskell enthusiasts hate separate content visually an semantically: they help to segment the code into distinctive small chunks vs seas of parens(Lisp) or long streams or words with operators(Haskell).
The above means Lisp/Haskell produce write-only code, that normal people don't bother deciphering. If you have autism though and see patterns everywhere, its not a problem to read it - though you will never convince people its readable because it "works for you".

>>74
That you cannot read Lisp does not make Lisp unreadable.

>>75
Lisp is technically readable, but i can read 5 pages of unformatted ugliest C at the time it takes me to read a single paragraph in Lisp.

#include "void.h"
//returns 0 if all arguments are non-void(existing after token expansion) or 1+ otherwise
#define hasVoidArgs(args...) sum(apply(zeroargs,args))
//see varmacro.h for zeroargs()
//and argmacro.h for sum()

>>77
its better should be name CountVoidArguments(arguments...) since it returns count of zeroargs(arg) matches, i.e. void/nil/empty arguments.

#define countVoidArgs(args...) sum(apply(zeroargs,args))
#define allArgsValid(args...) proxy(merge)(tvalswap,reduce0arg(countVoidArgs(args)))
//reduce0arg reduce counts to 0:1 (varmacro.h)
//tvalswap switches boolean values (varmacro.h)
//return 1:all args valid 0:had void arguments
#define checkArgumentsNonNil allArgsValid

Optimized
#define checkArgumentsNonNil(args...) !!(sum(apply(zeroargs,args)))