Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Macro-writing challenge

Name: Anonymous 2016-01-16 13:19

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.

Name: Anonymous 2016-01-16 14:19

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: Anonymous 2016-01-16 14:20

>>2
Whoever said anything about hygiene? This macro need not be hygienic.

Name: Anonymous 2016-01-16 14:23

>>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: Anonymous 2016-01-16 14:47

>>4
Common Lisp macro system is not hygienic. Plenty of people use unhygienic macros like anaphoric ones.

Name: Anonymous 2016-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.

Name: Anonymous 2016-01-16 15:07

>>5
I never said CL macros weren't unhygienic.

>>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 pointless 2016-01-16 17:28

what you should do is check for the actual type that you want.
e.g,

@check_argument_types
def foo(a: bool, b: string, c: int, d: Bar):
...

Name: Anonymous 2016-01-16 17:30

>>8
CL already has that.

... wait a second

>>1
CL already has that.

Name: Anonymous 2016-01-16 17:37

>>9
Prove it.

Name: Anonymous 2016-01-16 17:39

>>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: Anonymous 2016-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: Anonymous 2016-01-16 17:46

>>11
This isn't C, "uninitialised" variables in dynamic languages have "zero-ish" defaults.

Name: Anonymous 2016-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?

Name: Anonymous 2016-01-16 18:05

>>12
I'm >>1 but I'm a Haskeller, not a CL user.

Name: Anonymous 2016-01-16 18:06

Ideally, CL should have a (get-parent-form) to reference the outer form inside the macro.

Name: Anonymous 2016-01-16 18:06

>>12
Hello I'm >>1.
I found the check-type macro, but how do I install it?
https://www.npmjs.com/package/check-type

Name: the real >>1 2016-01-16 18:08

>>17
LOL

Name: Anonymous 2016-01-16 20:23

>>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: Anonymous 2016-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: Anonymous 2016-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.

Name: Anonymous 2016-01-16 21:55

>>21
Check 'em

Name: Anonymous 2016-01-16 23:22

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: Anonymous 2016-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.

But I think you're just clueless.

Name: Anonymous 2016-01-17 7:22

>>23
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: Anonymous 2016-01-17 10:50

>>24
That's because CL doesn't have (get-parent-form) to reference the outer form inside the macro.

Name: Anonymous 2016-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.

Name: Anonymous 2016-01-17 11:26

>>27
a sane default value for each type (in a dynamic language)

Name: Anonymous 2016-01-17 11:54

>>28
What's a "dynamic language"? Did you mean: unityped language?

Name: Anonymous 2016-01-17 11:55

>>29
Yes. Could I have meant anything else in this context?

Name: Anonymous 2016-01-17 12:16

>>30
It's kind of strange to say "for each type" when there is only one type.

Name: Anonymous 2016-01-17 12:18

>>27
The "zero-ish" function throws a fatal error.
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: Anonymous 2016-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.

Name: Anonymous 2016-01-17 14:12

>>33
still exist distinct from each other.
It's called "dynamic classification", it's the same as in Haskell, and has nothing to do with types. There is only one type, hence the name unityped.

Name: Anonymous 2016-01-17 14:43

>>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"?

Name: Anonymous 2016-01-17 16:31

>>35
woah.
that brought back memories.

nobody uses this posting anymore.

Name: Anonymous 2016-01-17 16:53

>>35
I hope you've realized that switching to the vernacular is a bad idea for plebs and only clouds comprehension.

Name: Anonymous 2016-01-17 22:20

>>34
Why don't you come say that to my face, you fucker‽‽!?!1 I'll unitype your monobrow with my fists!

Name: Anonymous 2016-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: Anonymous 2016-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.
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -