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.
That is not Lispthonic. By the design of hygienic macros and the non-hacky way syntax is implemented, (check-arguments-non-nil) has no knowledge that it is even inside a defun form. The correct macro to request is: (defun/non-nil foo (a b c d) foo-body)
Name:
Anonymous2016-01-16 14:20
>>2 Whoever said anything about hygiene? This macro need not be hygienic.
>>3 By necessity, in a hygienic macro system, it does. Of course, feel free to request a macro nobody will ever use nor write because it is unhygienic.
Name:
Anonymous2016-01-16 14:47
>>4 Common Lisp macro system is not hygienic. Plenty of people use unhygienic macros like anaphoric ones.
Name:
Anonymous2016-01-16 14:50
>>2 This approach is not composable and does not scale. What if you need to add some other property to defun? Pretty soon you'll be swamped by your multiple versions of it.
>>6 (defun/+ (anusoidal non-nil) foo (a b c d) foo-body) ; -> (defun/anusoidal anusoidal-foo (a b c d) foo-body) (defun/non-nil foo (a b c d) (anusoidal-foo a b c d)) ; -> or (defun foo (a b c d) (assert-anusoidal a b c d) (assert-non-nil a b c d) foo-body)
Name:
Checking for nil is pointless2016-01-16 17:28
what you should do is check for the actual type that you want. e.g,
>>8 You have 0 experience in programming, methinks.
muhNil : bool foo(muhNil)
Oy vey, muhNil is the right type but it is uninitialized and so nil! You are such an idiot!
Name:
Anonymous2016-01-16 17:45
>>10 If you are >>1 you should already be using CL, should therefore know your way around the documentation, and should finally therefore be able to find check-type in around 5 seconds. If you are >>8 you have no reason to be as much of an ass as you are.
Name:
Anonymous2016-01-16 17:46
>>11 This isn't C, "uninitialised" variables in dynamic languages have "zero-ish" defaults.
Name:
Anonymous2016-01-16 18:03
>>12 check-type does not cut it, because it requires explicit mention of every arguments. The challenge is for a macro that figures out what the arguments are on its own.
>>13 Not every type has a sane default. E.g. what's the default for boolean?
>>14 I know that. And I never said "sane" defaults, I said "zero-ish" defaults. So a default bool would be false, and a default int would be zero. Unless there was a value in the bottom type, of course.
Name:
Anonymous2016-01-16 20:33
>>19 There isn't even a sane way to assign "zero-ish" default to every type. For example the type of functions a -> b has no default.
Name:
Anonymous2016-01-16 21:28
>>15 Haskell from my point of view offers only one advantages: writing very terse code using built-in function composition. Disadvantages: 1.Hard to read other people code, cryptic functions requires frequent reference of operator/function usage 2.Garbage Collection, high memory use 3.slow speed in general:compiler doesn't optimize much 4.hard to optimize(due high level overhead & laziness) 5.for a high-level language, strings and IO are rather primitive& hard to use,so UnsafeIO is used 6.no macros.lacks easy metaprogramming 7.strict typing model: requires workarounds(like UnsafeIO) for real code.
The concept of an "uninitialised" variable makes no sense and the confusion only arises in languages that make the mistake of letting you reassign variables after creation.
Name:
Anonymous2016-01-17 4:33
>>1 Without the variables being passed into the macro, the only way to get at them would be the environment object, which is implementation-specific.
make the mistake of letting you reassign variables after creation.
The only "mistake" is quack "professors" not understanding the difference between a chunk of memory and an algebraic variable.
Name:
Anonymous2016-01-17 10:50
>>24 That's because CL doesn't have (get-parent-form) to reference the outer form inside the macro.
Name:
Anonymous2016-01-17 11:20
>>20 The "zero-ish" function throws a fatal error. This is not applicable to sane static languages anyway, so figuring out a sane default value for each type is moot, since it'll just figure one out once it figures out the type. Or just invent a value for the bottom type, in the same way undefined is basically the "bottom value" for all types in javascrot. That way the types still align, if you can call them that.
That's the same as NIL for practical purposes. You still need to check 'em before being able to use them. Thus, a macro to make assertions about non-NIL is very useful.
Name:
Anonymous2016-01-17 12:45
>>31 Nice try. The "one" type is the wrapping ADT VInt Int | VString String | .... Strings, integers and other values still exist distinct from each other.
>>32 I never said the macro was not useful. We are in agreement, friend.
>>34 I switched to the vernacular of a dynamic language because that was the context in which I was speaking. Now are you going to continue pointlessly lecturing me on distinctions irrelevant to the discussion at hand, or is this just your way of saying, "I enjoy derailing threads"?
>>34 Why don't you come say that to my face, you fucker‽‽!?!1 I'll unitype your monobrow with my fists!
Name:
Anonymous2016-01-17 23:14
>>26 That would be utterly useless, and you are an idiot.
You don't know what the parent form is, given that the context above it could change its semantics arbitrarily. Just reading the raw list (DEFUN NAME (PARAM PARAM) ...) might mean something completely different in a user's development environment, or there might be extra parameters inserted or whatever.
You have no clue what it takes to do proper code walking, or what an environment object is.
Name:
Anonymous2016-01-20 17:08
>>7 I don't get it. You still have to define non-nil using anusoidal, if I understood what you mean by (defun/non-nil foo (a b c d) (anusoidal-foo a b c d)) That makes it uncomposable still.
Name:
Anonymous2016-01-20 18:02
>>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.
Name:
Anonymous2016-01-20 18:13
>>41 So you can't define this #defime runmacro(macro,args...) macro(args) in Lisp?
Name:
Anonymous2016-01-20 18:49
>>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.
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).
Name:
Anonymous2016-01-20 22:00
>>43 What about this one: #define runmacro2(macro,code1,code2,args...) ({code1;code2=macro(args);})
Name:
Anonymous2016-01-21 0:08
>>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.
You say Lisp has failed, what is the alternative? If there is no alternative, can one be made? How would you fix this?
Name:
Anonymous2016-01-21 6:12
>>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.
Name:
Anonymous2016-01-21 6:34
>>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).
>>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.
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.
Name:
Anonymous2016-01-21 8:09
>>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.
Name:
Anonymous2016-01-21 8:32
>>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.
Name:
Anonymous2016-01-22 6:27
>>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.
Name:
!OUKY5mcbp62016-01-22 11:26
>>53 Lisp macros are definitely not non-intuitive.
Name:
Anonymous2016-01-22 12:54
(check (em (dubs)))))))))))))))
Name:
Anonymous2016-01-22 13:03
>>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.
Name:
Anonymous2016-01-22 16:36
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.
Name:
Anonymous2016-01-22 17:03
>>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.
Name:
Anonymous2016-01-22 18:21
>>59 Lisp macros are way more readable than that executable C preprocessor macro cobbled together shit.
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.
/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
That said, >>61faggot has presented a valid (and biting) satire of the LISP weenies.
Name:
Anonymous2016-01-23 4:44
>>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.
Name:
Anonymous2016-01-23 4:54
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.
>>69 Anii are not a sin, therefore they can't be sin taxed.
Name:
Anonymous2016-01-23 6:47
>>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.
Name:
Anonymous2016-01-23 7:14
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.
Name:
Anonymous2016-01-23 8:18
>>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!
Name:
Anonymous2016-01-23 8:38
>>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.
Name:
Anonymous2016-01-23 9:44
>>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.
Name:
Anonymous2016-01-23 10:03
#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()
Name:
Anonymous2016-01-23 10:07
>>77 its better should be name CountVoidArguments(arguments...) since it returns count of zeroargs(arg) matches, i.e. void/nil/empty arguments.
added to varmacro.h as: #define validargs(args...) !(sum(apply(zeroargs,args)))
Name:
Anonymous2016-01-23 11:06
>>74 Haskell & Lisp use whitespace as a separator. Why the fuck do you need more punctuation than that? C syntax is just messy and backwards in its goals: Harder to parse, harder for the human to input, harder for the human to read.
When C came out, everybody was railing against the ridiculous semicolons everywhere, because other languages weren't stupid enough to do that. You're just living in an age of Stockholm Syndrome.
Name:
Anonymous2016-01-23 11:19
>>82 H a s k e l l & L i s p u s e w h i t e s p a c e a s a s e p a r a t o r . W h y t h e f u c k d o y o u n e e d m o r e p u n c t u a t i o n t h a n t h a t ? C s y n t a x i s j u s t m e s s y a n d b a c k w a r d s i n i t s g o a l s : H a r d e r t o p a r s e , h a r d e r f o r t h e h u m a n t o i n p u t , h a r d e r f o r t h e h u m a n t o r e a d.
When(C) came.out(); everybody? was:railing; against== the ridiculous semicolons everywhere; because other languages weren't stupid enough to do that; You're= just= living( in(an,nage))->of Stockholm Syndrome;
Haskell & Lisp use whitespace as a separator. Why the fuck do you need more punctuation than that? C syntax is just messy and backwards in its goals: Harder to parse, harder for the human to input, harder for the human to read.
Because that's already space-delimited symbols. Like our normal Latin-ish languages. Dumbfuck.
Name:
Anonymous2016-01-23 11:32
>>84 i g u e s s i t s e a s i e r t o r e a d i f y o u h a v e a u t i s m
Name:
Anonymous2016-01-23 11:38
w h o n e e d s a n y t h i n g b e s i d e s w h i t e s p a c e i t s a p e r f e c t l y c r o m u l e n t p u n c t u a t i o n s t y le th a t r e pl a c e s a ll th e s e i ne f f ic i en c e s o f e n gl i sh l a n g u a g e a n d s im p l if i e s s en t en c e s t r u c t u r e t o f o ll o w t h e h as k el l s t a n d ar d
Name:
Anonymous2016-01-23 11:48
y, e, s, c, o, m, m, a, s, l, i, k, e, i, n, C, a, r, e, w, a, y, b, e, t, t, e, r, a, n, d, d, o, n, t, a, d, d, a, n, y, t, h, i, n, g, v, i, s, u, a, l, l, y, s, o, t, h, e, y, d, o, n, t, d, i, s, r, u, p, t, r, e, a, d, i, n, g, a, t, a, l, l, a, n, d, e, v, e, r, y, b, o, d, y, a, l, r, e, a, d, y, u, s, e, s, s, p, a, c, e, s, w, i, t, h, t, h, e, m, s, o, i, t, a, l, l, w, o, r, k, s, o, u, t, i, n, t, h, e, e, n, d, r, i, g, h, t;
Name:
Anonymous2016-01-23 11:54
>>87 C==doesn't(limit){ itself to white-space and comma-only syntax}; It=has !!operators + distinct from ? functions : variables, semicolons; and {braces.separating_content()}.
Name:
Anonymous2016-01-23 12:01
Why not just use Tcl? It's also a string-based language, but an actual programming language at that.
Name:
Anonymous2016-01-23 12:20
>>89 C preprocessor is simpler and is always present with a C compiler - its part of C standard. TCL could be used as preprocessor( www.drdobbs.com/open-source/c-preprocessing-with-tcl/184410635 ) if you add it as dependency, but extending the preprocessor(_TokenOf()) is more beneficial long-term, since even Tcl is in C. Any extension in the preprocessor benefits the entire software industry since at the base its layer of C code & C macros(and can be used with Assembler). There tons of C macros in every large C project, like e.g. Linux kernel. Making them less verbose, less cryptic and complex would actually be useful and orderPP would be useless.
Name:
Anonymous2016-01-23 21:07
>>90 Then as I've said before, just use C to generate C, if the priority is to do metaprogramming only with the standard C toolchain. It's a lot more sane and far less hackish of a setup.
Name:
Anonymous2016-01-24 5:12
>>91 Macros are more elegant and integrate into the code better. Its like JavaScript that generates the webpage on which its loaded.
Name:
Anonymous2016-01-24 5:24
Its like JavaScript that generates the webpage on which its loaded.
Diversity is shit. Homogenous syntax is lightyears ahead of any Blub syntax, it's easier to edit and read and write. You just need to get a real text editor and not some mouse-dragger.
Name:
Anonymous2016-01-24 20:58
real text editor
More like text interpreters for programming text. Editors actually edit text, emacsitors and vimitors require you to execute commands and macros to accomplish tasks.
Name:
Anonymous2016-01-25 9:47
>>95 Not just easier for a human to read & write, but also for the computer. Get that thing to start cranking out code for you so you don't have to. It's a pain in the ass when most other languages require you to build up source code as text blobs.
Name:
Anonymous2016-01-25 20:19
>>95 That's offensive. The correct term is "point-and-drool". You're giving textual text editors a bad name.
Name:
Anonymous2016-01-25 20:26
u just need good mice with 8K dpi and you can click faster than these nerds mistyping lunix commands into their text processors