That's a good point. I don't know if it's really worthwhile.
If we went with a system that had partial wrappers, we'd run across the foreboding corner case of a wrapper that had no effect at all. We might wrap anything in this wrapper an arbitrary number of times and not notice until we start peeling off layers again. But that actually brings us a kind of consistency: We can decree as part of the language design that everything eventually unwraps into an infinite regress of boring wrappers. This gives us a great excuse for 'apply to work on fexprs.
(fn ('a b c . 'd) ...)
(wrap '(t nil nil . t)
(fexpr (a b c . d) ...))
...I meant to explore some other options here too, but you're probably thinking at least as deeply as I am about them, and none is as remarkable as that. (I'm not saying the partial wrapper infinite regress is better, just more remarkable, lol.)
Now then. Let's try (apply let '(a 5 a)) which should be equivalent to (let a 5 a):
(apply let '(a 5 a)) ->
(eval (cons (unwrap let) '(a 5 a))) ->
(eval (list (unwrap let) 'a '5 'a)) ->
(eval `(,(unwrap let) a 5 a)) ->
((unwrap let) a 5 a) ->
(let a 5 a)
Okay, so the apply works (as per my previous post on this subject) but you're concerned about the eval. So let's expand out the call to let:
(eval '((fn (a) a) 5) ...)
Notice how the argument passed to eval is quoted because the macro that generated it used quasiquote. Now this quoted expression is evaluated in the dynamic environment, thus giving us the result we want. Are you running into any problems with this approach?
Why would you do that, and how does wart handle macros, then?
"What would env be when the call to mac is translated to an fexpr in your scheme?"
It would be the environment where the macro is called. That is, in the dynamic binding of the macro call, x would be 4.
Using the environment of the place where the macro is defined would be static scope... which I assume wart already has, so that's redundant and pointless because you can just do this to evaluate the expression in the static scope of the fexpr:
I'm very concerned by your approach. It seems quite hackish to me, compared to the elegance of wrap/unwrap in Kernel.
When I was talking about unwrap, I was assuming that all functions are created with wrap, so all of them can be easily unwrapped, rather than unwrap generating a new fexpr. In other words, I was expecting this:
(unwrap (wrap f)) is eq to f
"Since unwrap doesn't change and at all.."
Yes, that's good. Calling unwrap on a fexpr should just return the fexpr itself, assuming you want them to work on apply without wrapping them first.
I think it still matters insofar as it suggests a very simple implementation, rather than the hacky one you came up with. Basically, I'm saying functions should just be annotated fexprs, and then unwrap can just return the rep of the function.
* : It obviously also matters in a Lisp with eq. It could also matter if you ever do decide to add in an eq-like thing to wart, even if you don't necessarily call it eq.
I wouldn't consider "I don't have eq, so do without it." to be a good reason anyway. So the reason my unwrap copies its argument is that it's not at all obvious to me that it matters in a lisp with eq.
When you repeatedly say 'hacky' you shed more heat than light. I'm not sure what the flaw is that you see, and whether it's the same flaws that make me embarrassed about it.
For example, the fact that it generates a new copy each time, I'm not sure that's a bad thing.
The implementation relies on the representation of functions in wart, but that's because it's the implementation, and implementations can be changed. The conception doesn't seem compromised to my imperfect understanding: unwrap.f is just like f except that evaluation of args is disabled. My concern is really: is this implementation behaving as unwrap should? Are there corner cases where behavior diverges from the desired?
 I personally find eq to be quite 'hacky' in the way it requires knowing about how atoms are interned. But again, that's neither here nor there.
 It's not as bad as the sb-bquote nonsense a macro body expands to in sbcl.
"For example, the fact that it generates a new copy each time, I'm not sure that's a bad thing."
From a practical standpoint, unwrap is used in apply, which means you end up copying a function and running your quotify function over it every single time you use apply. My method should be a lot faster, with no additional cost in flexibility or power. It should also be much shorter and easier to implement as well. In fact, I'll define wrap and unwrap right now, using Arc syntax:
(def must-combiner (x)
(if (in type.x 'fn 'fexpr)
(err "expected combiner but got" x)))
(def wrap (x)
(annotate 'fn must-combiner.x))
(def unwrap (x)
Do you think your implementation is equal to or superior to that, especially given that you only showed unwrap and not wrap in your post?
* : I still partially disagree with you even on theoretical grounds. I think that defining (unwrap (wrap f)) to be eq to f is a good equivalence that could prove useful in practice, or at least make it easier to reason about programs because it's so simple and intuitive (based on the names "wrap" and "unwrap").
However, if you've defined iso so it works on functions (that is, functions with the same arguments and body are equal), then I'm fine with that and don't care so much about eq, since iso is the default in wart.
* : Especially since wart is written in C++, so you should be able to make things like the fn wrapper very fast (to type check and extract the fexpr) and memory efficient.
* : I'm assuming that annotating something with the same type will wrap it a second time, which Arc doesn't currently do.
I'm also assuming eval has been changed so it understands things with type 'fn. This isn't a problem in Kernel because eval, wrap, and unwrap are all primitives. You could do the same in wart, or extend eval, or whatever.
I think I'm getting on your nerves again, so I'm going to go away after this.
If I cared about a superior or more efficient implementation I'd go use racket or kernel. I build things to better understand them.
My purpose in showing my unwrap was to show that I still don't understand your suggested implementation of apply. Not to get bogged down in considerations of performance. This is wart, where everything is in slow-mo. It can take a little more consing :)
Perhaps I'm getting stuck in a local optimum here. Now that I've slummed it out with an implicit-env eval for a while, perhaps I'll appreciate the benefits of an explicit env far faster if I just switch to it.
Anyways, thanks for the hand-holding. I should figure out the rest on my own.
And oh, I didn't show wrap because it's impossible in a language that allows some params to be eval'd (http://arclanguage.org/item?id=15813). There's no nice way to guarantee that:
Only a little. Although I think ignoring performance is an overall good thing (premature optimization and all that), I think it's still important to choose the best option (in terms of benefit-cost) that's currently available. If somebody gives you an implementation that's better in every way with no cost, why would you refuse it...?
"I still don't understand your suggested implementation of apply."
I think the trick to it is to stop thinking of things being automatically evaluated and then using quote to suppress it. If you see not evaluating (fexprs) as the default, and then evaluating (functions) built on top of it... it all clicks together. At least, it did for me.
Kernel is pretty clear and elegant in isolation. But can you get traditional (non-phase-separated) macros that way? Does giving eval an explicit env eliminate the need for the implicit eval in caller scope (http://www.arclanguage.org/item?id=15137)? Does the kernel doc address this question?
A non-phase-separated macro implemented as a Kernel-style fexpr is simply of the form ($vau <args> env (eval <body> env)), possibly with red tape so that env isn't in scope during the body.
I don't have answers to the other questions....
By the way, I've still never really understood wart's scope setup (or maybe I have and I said to myself "nah, that can't be it" :-p ). While I'm suspicious of it, I'd rather not just condemn it by default. When I talk about how things would work in Kernel, it's in the hopes that somehow it could translate over, and maybe that somehow you yourself would discover why your approach was better or worse.
Warning: I haven't tested the above and I don't think it'll work because I'm pretty sure Kernel doesn't define a gensym function. But assuming a suitable implementation of gensym, it's simple and straightforward enough that I would expect it to work.
And now you can use it to write macros in Kernel (I don't think that's a good idea, though...):
* : In Kernel, you sometimes find fexprs of the form ($vau ... env (eval ... env)) which is basically what the above $mac form does. To avoid the extra redundancy (boilerplate) of the call to eval, you might want to define a $mac form, but it should be anonymous, as in ($mac (a b c) ...):
In addition, $vau should still be the default way users deal with fexprs. This $mac form is only syntactic shortening for a common use case, but should not replace fexprs.
To clarify my position, you shouldn't have to think in terms of macros, you shouldn't have to try to change the problem to accommodate the way macros work. If it's natural to solve the problem with fexprs, then do so! If it's natural to solve the problem with macros, then do so! Don't try to shove a square peg into a round hole.
All the differences they discuss revolve around phase separation and the need to perform macroexpansion at call sites. So there's implicitly no other reason it can't be done.
Thanks a lot, guys! I have some rewriting to do in wart :)
You said Kernel doesn't have quasiquote for good reason. Can you elaborate? Ah, I googled around.. and found your comment earlier in this thread: http://arclanguage.org/item?id=15691 Lol, I'd missed footnote 1.
"You said Kernel doesn't have quasiquote for good reason. Can you elaborate?"
quote encourages you to think in terms of implicit eval, quasiquote makes it way too easy to break hygiene accidentally, and macros are indirect and differ significantly from functions, thus making certain programs harder to write/understand/debug/etc.
Like I said earlier, the trick to understanding it is to think in terms of fexprs evaling things, rather than using quote to suppress evaluation. The simplest way to do that is to just remove quote entirely from the language, thus deeply encouraging you to think in terms of fexprs.
Another problem is that if you encourage quasiquote, then people are more likely to use it to create symbols in fexprs, but that then introduces all the hygiene problems of Arc's macro system. Let me give an example. Let's suppose that you defined $mac in Kernel, and also quasiquote. Let's define an Arc-style $let fexpr:
So far so good, except... we're injecting the symbol $lambda rather than the fexpr $lambda, so this will break:
($let $lambda 5
Because the second $let uses the local definition of $lambda, which is currently bound to 5. Hygiene violation! Kernel avoids this by simply not providing quote/quasiquote at all. Instead, you explicitly call list and list* to build up lists:
This works because it's inserting the value of $lambda rather than the symbol, so it's inherently hygienic due to static scope. The problem with quasiquote is that it makes it really easy to break hygiene by accident, and Kernel's 3rd guideline is:
"Dangerous computation behaviors (e.g., hygiene violations), while permitted on general principle, should be difficult to program by accident"
As for macros... their problem is that trying to specify an expression that when evaluated will give the desired result is usually more complicated, more difficult to understand, and thus more error-prone because it's indirect. For instance, compare these two definitions of $or?:
In addition, the model for evaluation of a macro is waaay different than the model for functions, but fexprs and functions are extremely similar in model. I believe this simplicity and consistency make fexprs easier to understand and use.
* : But if you ever do want $quote, it's super easy to define:
($vau (x) #ignore x))
$quasiquote would be harder, and would be pointless if you don't have syntactic sugar for it. In addition, quasiquote is far less important in a Lisp that emphasizes fexprs and doesn't have macros (by default).
* : Arubic has a "hygienic" quasiquote called quasisyntax (borrowing from Racket's terminology):
"The problem with quasiquote is that it makes it really easy to break hygiene by accident, and Kernel's 3rd guideline is..."
A misguideline. :-p It's my least favorite part of Kernel's philosophy. I'd rather say desirable things should be easy to do by accident.
Pretty much everywhere Kernel uses G3, I'd rather see another justification. For instance, if Scheme has a "dangerous" feature people commonly use as though it did something slightly different, and Kernel replaces it with something else that's harder to make that mistake with, I might be swayed by an orthogonality argument.
By the way, Kernel replaces gensyms with "keyed static variables." As it happens, the R-1RK does justify this with an appeal to orthogonality!
It also notes that their main use case is environment mutation. Hygiene doesn't need them; as your '$or examples demonstrate, the primary replacement for gensyms is fexprs. :-p
Okay, so, I'm not saying that a facility for easily constructing lists (even unhygienic ones) is bad.
What I'm saying is that $quasiquote in specific is bad. But I'm perfectly fine with something like my $quasisyntax operator, which is hygienic.
The problem with $quasiquote is that $quote is the default, so in order to be hygienic (which is what you want most of the time), you have to $unquote everything.
My $quasisyntax operator, on the other hand, $unquote's things by default while still letting you easily break hygiene when you want to.
In other words...
#`(foo (bar qux) corge)
...is just syntactic sugar for:
(list foo (list bar qux) corge)
This is useful not only in macros, but also in ordinary fexprs and even functions. But it's only syntactic sugar for cons/list, so by default it doesn't support any way to use $quote to break hygiene.
Now, you might be sitting there saying, "but I want to break hygiene!" and I agree, it does need to be easy to break hygiene when you want to, just not to break it by accident.
So what do I need to change to allow for hygiene violations? Actually, I don't need to change anything. The above operator already supports hygiene breaking, without needing to bake it in, unlike $quasiquote which requires $quote to be built-in.
Let me give an example. Consider this definition of $afn, which is almost hygienic except for the deliberately inserted symbol 'self:
See that? I use unquote to evaluate an expression, and that expression just so happens to be the quoted symbol 'self.
So you can define a $quasisyntax operator in Kernel that allows you to use $quote'd (unhygienic) values, without $quasisyntax actually needing $quote at all! In that case it just serves as syntactic sugar for cons/list.
But, if you decided to add in a $quote operator, you can immediately use it with $quasisyntax to break hygiene, without needing to change/redefine $quasisyntax.
See how easy that is? So, with $quasisyntax, hygiene is the default, but you can still super-easily break hygiene, just by using ,' to insert the quoted symbol.
This is what I was talking about earlier, about making it hard to do dangerous things by accident while still making it possible (and hopefully easy) to do it on purpose. Whether John agrees with me on this particular point or not, I don't know, but that's how I see it.
* : This is logical in a Lisp that uses $quote to suppress evaluation, but Kernel uses explicit-eval and doesn't even define $quote by default; so $quasiquote is inconsistent with the very core of Kernel itself. On the other hand, as far as I can tell, the definition of $quasisyntax is perfectly compatible and consistent with Kernel in every way, though I concede that Kernel isn't particularly interested in things like syntactic shortcuts.
* : You might look at the above comparison of $afn and think, "pfft that's not a big deal" and you'd be right. The differences in the definition of $afn are small.
But in even slightly more complicated macros, the need to $unquote everything becomes a bigger issue, especially since it's very easy to forget to $unquote something (I've done this myself with $quasiquote, at least a few times, and I'm usually a very careful person; I usually double and even triple check my code).
It also looks ugly seeing the , character spewed out everywhere, therefore encouraging you to not use it, therefore encouraging you to break hygiene (by default) rather than breaking hygiene consciously, when you want to.
* : I, personally, would probably call it something other than $quasisyntax, and I would probably use ` or @ rather than #` for brevity and because it looks nicer.
* : Incidentally, this solves some issues I had had with $quasisyntax in Arubic... consider this old Arubic definition of afn:
Okay, so I'm using $quote as a way to say "the symbol self should be unhygienic". But that not only means that $quasisyntax hardcodes the symbol $quote (in addition to $unquote and $unquote-splicing), but it also means you need to double the $quote's if you want to insert the list ($quote ...):
#`(annotate ''mac ...)
Notice the double $quote's around the symbol 'mac. The above is equivalent to:
`(annotate 'mac ...)
This inconsistency bugged me, but just a short while ago I realized I could get rid of all that hackiness just by using ,' instead.
That also means that $quasisyntax could be made available by default in Kernel (if John wanted that) without requiring $quote to be defined!
I already understood the benefit of your quasisyntax operator. I agree that it makes desirable things easy to do by accident.
I don't agree that the original quasiquote should be difficult.
It's pretty much a matter of political spin. There's no need to work to make quasiquote difficult, but there's little need to work to make it easy either, since that effort would be better spent on quasisyntax. We can just neglect to give quasiquote any sugar, at the same time as we spoil quasisyntax with sugar of its own. We can also neglect to define quasiquote in the main language distribution altogether.
"I, personally, would probably call it something other than $quasisyntax"
If it's essentially a syntax that turns paren into a list literal syntax (with ,foo syntax as an escape), then maybe $lists or $es (evaluation structure) would be a nice brief name for it. :)
"I don't agree that the original quasiquote should be difficult. [...] We can just neglect to give quasiquote any sugar, at the same time as we spoil quasisyntax with sugar of its own. We can also neglect to define quasiquote in the main language distribution altogether."
tl;dr: I agree with you overall, so perhaps we're just using different terminology or wording, resulting in confusion.
Right, I'm not saying that users shouldn't be allowed to define $quasiquote if they want to, but given its problems and the fact that $quasisyntax is better overall, there's no need to provide $quasiquote by default in the language. And if there were a better alternative ($quasisyntax) in the language, then users would be encouraged to use it instead of defining $quasiquote themselves.
Even though Kernel goes out of its way to not provide $quote, it's trivial to add it in (literally just 1-2 lines of super-simple code). And it should only take ~20 lines or so to define $quasiquote, the same as it does in Arc. The only difference is Kernel doesn't have syntactic sugar for $quote, $quasiquote, or $quasisyntax.
I think syntactic sugar should have its own facility, such as reader macros (or something better), allowing users to add in syntax for $quote/$quasiquote/$quasisyntax/other things. But that's a different story.
"perhaps we're just using different terminology or wording, resulting in confusion."
In particular, I disagree with this statement of yours: "I already understood the benefit of your quasisyntax operator. I agree that it makes desirable things easy to do by accident."
As far as I can tell, quasisyntax does not make it easy to do "desirable things" (like breaking hygiene) by accident. It does make it easy to do them on purpose.
I think our primary disagreement is that we're using different meanings for the word "accident". It seems to me that when I say "it should be hard to do dangerous things by accident" you take that to mean "I, the language designer, shall deem what shall be dangerous, and you, the user, shall not be allowed to do those things without jumping through crazy hoops!!"
But that's not what I'm saying. When I'm talking about "on accident", I'm referring to the user, not the language designer. Let me give an example. Let's suppose you had an operator in your language for deleting files.
To look at a real-world example, let's use the Unix command "rm". If you want to remove the file /foo/bar you would say this:
Okay, but let's suppose you mistype something (we all do it occasionally) so you instead accidentally enter this:
rm / foo/bar
A difference of only a single character! But what the above command does is remove every file on your entire harddrive. This is what I mean by "doing dangerous things by accident" and I'm sure some people have been burned by this.
Thankfully that's not what actually happens (at least on my computer): rm doesn't remove directories without specifying the -r option. So for removing files you say `rm foo` and for removing folders you say `rm -r foo`. Of course, that doesn't help if you accidentally type `rm -r / foo/bar`...
That's an example of making dangerous things difficult to do by accident, while still making it easy to do them on purpose when you want to.
So when I say that dangerous things should be difficult to do by accident, this is really just a different way of saying that "computers should do exactly what we want them to do, no more and no less".
Alternatively, it could also just be a rephrasing of the principle of least surprise, that computers should do what people expect them to do, rather than going off and doing crazy things that the user didn't want.
You don't want the computer to go berserk and do things you didn't intend for it to do. But in the (rare) case that you do want to, say, remove your entire harddrive, you should still be able to do so, and ideally it should be easy as well. Just not easy by accident.
My quasisyntax operator makes it super-easy to break hygiene when you want to, but it doesn't make it easy to do it by accident. You have to manually and explicitly add ,' to a symbol to make it unhygienic. Contrast that with quasiquote where it's easy to forget to unquote something, therefore quasiquote has the same power as quasisyntax, but makes it easy to break hygiene by accident.
Essentially the difference between quasiquote and quasisyntax is that quasiquote makes it easy to make mistakes, but quasisyntax does exactly what you would expect it to do, without making mistakes, while still making it really easy to break hygiene when you want to.
* : I'm not actually sure about that... did older versions of rm automatically remove directories without specifying -r...? I vaguely remember some Unix horror stories, but they might have already been specifying -r in which case that won't help any.
I consider your quasiquote operator to make it easy to accidentally forget to quote things. Since we both consider that to be what people are most likely to want anyway, that's hardly a problem.
For a more detached example, consider someone who implements the same algorithm in Arc and Haskell. Their Haskell version uses call-by-need when their Arc version uses call-by-value, and at first they may even understand and disregard this discrepancy. Later they discover that one of these is detrimental--an undesirable accident. I consider the other one to be a desirable accident.
To me, this isn't just about whether the computer does what the user wants/expects it to do. It's about whether the computer does what the user doesn't know they want it to do. IMO, programming is all about specifying what one wants in really specific terms, even down to details one isn't truly sure about yet.
"It seems to me that when I say "it should be hard to do dangerous things by accident" you take that to mean "I, the language designer, shall deem what shall be dangerous, and you, the user, shall not be allowed to do those things without jumping through crazy hoops!!""
That's pretty much right. :) You have a good point that "by accident" is a key phrase, and your example of an accident is a nice thing to make difficult.
However, I still take any use of G3 in Kernel with a grain of salt, in case it turns out to be accidentally used in an "it should be hard to do things" way instead. There are many places where it's used for legitimate clarity of program behavior, but I'm not so convinced by these uses:
"Distinguishing long identifiers by case alone is error-prone, hence contrary to G3."
"One compromise is to G3 of §0.1.2. Naive traversal algorithms are
dangerous; and, inevitably, the more readily available naive traversal algorithms become, the more readily the programmer can use them by accident."
"Most algorithms, however, are intended by the programmer to be im-
mutable, and therefore, when an object is primarily meant to represent an algorithm, mutating it is a dangerous activity that ought to be difficult to do by accident (G3 of §0.1.2)."
I'm not convinced that these things are dangerous. I expect these kinds of accidents to cause run time errors nearly 100% of the time. They could do dangerous things in particularly contrived cases, but IMO, contrived cases are indistinguishable from non-accidents. (Yeah, I'm not being very empirical about this. >.> )
(When multiple antagonistic programmers are involved in a program, encapsulation prevents more than accidents, but I doubt that's the case under discussion....)
"I consider your quasiquote operator to make it easy to accidentally forget to quote things."
Sure, but I'd argue that A) you want hygiene most of the time, so forgetting to $quote something happens less often, and B) in the case where you forget to $quote something with $quasisyntax, it usually throws an error. The reverse is not true: if you forget to $unquote something with $quasiquote, it's usually not an error, it fails silently until the bug is later discovered (possibly after a long time).
In other words, $quasisyntax not only chooses a default that you (the programmer) want more often (hygiene), but it also tends to throw errors earlier in case you (the programmer) mess up. That's why I consider $quasiquote to be bad. But in some hypothetical language where you want to break hygiene a majority of the time... then $quasiquote would probably be superior to $quasisyntax.
"To me, this isn't just about whether the computer does what the user wants/expects it to do. It's about whether the computer does what the user doesn't know they want it to do."
If so, then in order for the user to be guided into areas where they don't know they want it to behave in that way, then the language needs to encourage/discourage various behaviors in some way. Every language does this, in different ways, and to different degrees.
"but I'm not so convinced by these uses"
1) I agree, that doesn't seem to have much to do with G3 simply because if you accidentally use the wrong case for a long identifier, it's very likely to throw a runtime error that the variable can't be found.
2) I actually think this does justify G3 (though I agree it's pretty weak), for the same reasons I mentioned that using $quasiquote encourages you to use bad hygiene. If you don't provide a solid traversal algorithm, programmers are going to write their own awful algorithms which are no doubt broken.
I don't think Kernel goes out of its way to prevent you from writing stupid naive algorithms, and writing stupid naive algorithms is really easy. Instead, that's a rationale for not including naive algorithms in the core. You can still write your own naive algorithm, it just isn't going to be baked into the language, especially since the only gain of a naive algorithm is execution speed, not power or flexibility.
3) That particular part of the Report is talking specifically about operand capturing, e.g. fexprs. What it's saying is that when you apply a value (usually an acyclic list) to a fexpr, that fexpr could potentially mutate it.
This could cause some unexpected "action at a distance" so Kernel instead makes an immutable copy of the value and applies that to the fexpr instead. I'm not actually sure how I feel about that...
Incidentally, I believe that's how most (all?) Lisps do it: if you use (apply foo bar) in Arc, the foo function gets a copy of the list bar, not bar itself.
If you want the fexpr to be able to mutate its arguments... I would have suggested to pass the (mutable) list as a single argument to the fexpr, but... I'm not sure if that's actually possible... but it should be, right...? I would assume so.
"I'm not convinced that these things are dangerous."
I don't think they're any more dangerous than breaking hygiene. But Kernel already specifically mentions breaking hygiene as being dangerous, therefore calling those things dangerous is consistent with Kernel's viewpoint. So I suppose it depends on how dangerous something is before you personally (the programmer) call it "dangerous". But John Shutt apparently did consider them dangerous, hence their design in Kernel.
I personally wouldn't call them "dangerous". I think that word should be reserved for disastrous things like, say, deleting your entire hard-drive by accident. I would call things like breaking hygiene and whatnot "undesirable violations" (with the caveat that they can be desirable in certain circumstances, so they shouldn't be banned outright). If you have a better word to describe it, I'd like to hear it.
"In other words, $quasisyntax not only chooses a default that you (the programmer) want more often (hygiene)..."
...which is what I said :) ...
"...but it also tends to throw errors earlier in case you (the programmer) mess up."
I agree with this too. Throwing an error early is a nicer accident than throwing an error late.
"If so, then in order for the user to be guided into areas where they don't know they want it to behave in that way, then the language needs to encourage/discourage various behaviors in some way. Every language does this, in different ways, and to different degrees."
I don't see how this has a point any different from what I'm saying. :-p
"I don't think Kernel goes out of its way to prevent you from writing stupid naive algorithms, and writing stupid naive algorithms is really easy. Instead, that's a rationale for not including naive algorithms in the core. You can still write your own naive algorithm, it just isn't going to be baked into the language, especially since the only gain of a naive algorithm is execution speed, not power or flexibility."
In a customizable language (which Kernel isn't), to do something the most obvious way makes that part of the language more intuitive to customize, even if the most obvious thing is naive.
In a language with a culture of sharing black-box libraries (which Kernel would probably be, but for instance wart might not be), to do something the same way a library would do it makes for a more consistent experience.
Instead, for consistency's sake, Kernel advocates for library writers to write non-naive algorithms, ultimately making library-writing more of a chore.
This is totally a "worse is better" line of argument, so I don't expect to convert you with it so much as to convince you the ideals aren't so clear-cut.
"If you want the fexpr to be able to mutate its arguments... I would have suggested to pass the (mutable) list as a single argument to the fexpr, but... I'm not sure if that's actually possible... but it should be, right...? I would assume so."
I think Kernel calls the copy algorithm "copy-es-immutable," and IIRC, what it does is [treewise cons idfn _], but with an immutable cons. So if your mutable conses are hidden behind a variable name (to be evaluated) or a thunk, they'll survive. If you're just trying to eval (foo (my mutable list)), that won't work.
"I personally wouldn't call them "dangerous". I think that word should be reserved for disastrous things like, say, deleting your entire hard-drive by accident."
I agree. That's why I brought up those uses of G3; they just seem like examples of accidental errors being prevented, rather than accidental disasters being prevented.
"I would call things like breaking hygiene and whatnot "undesirable violations" (with the caveat that they can be desirable in certain circumstances, so they shouldn't be banned outright). If you have a better word to describe it, I'd like to hear it."
I don't know what you mean by "things like breaking hygiene and whatnot," unless you mean all the perhaps-not-so-dangerous things John Shutt considered dangerous when writing the R-1RK, and that isn't a very well-defined set of things. :-p I would probably call them "bugs."
Maybe G3 becomes something like this: While permitted on general principle, bugs should be hard to introduce by accident.
Hmm, I think this could be another, more upfront way to phrase the way G3 is actually used: The language should allow more expressiveness than is recommended for everyday use, but programmers on the fringe cases should have to jump through extra hoops.
I might actually support a G3 worded this way, but only because it suggests that it's easy to write full programs without jumping through any hoops, just by sticking to a subset of the language. Do you think there's a clear subset like that in Kernel? I'm not sure.
"I don't see how this has a point any different from what I'm saying. :-p"
Right, I'm agreeing with you a lot, except that you seemed to be a bit against some of the things Kernel does, and I was pointing out that Kernel does that because it's trying to guide you toward a certain way of thinking that (hopefully) results in better programs. Whether you agree with Kernel's guidelines or not is another story.
"Instead, for consistency's sake, Kernel advocates for library writers to write non-naive algorithms, ultimately making library-writing more of a chore."
Library-writing already is a chore. If the only libraries available are hacky semi-broken things, then why would I use them? I can just write my own hacky semi-broken program faster than it would take to understand the library (usually).
So one of the primary benefits of libraries is that you can put a lot of extra effort into it, and then people use the top-notch shiny awesome library so they don't have to put all that effort into getting things perfect. Kernel just seems to embrace that and try to make even the core language itself rock-solid.
"This is totally a "worse is better" line of argument, so I don't expect to convert you with it so much as to convince you the ideals aren't so clear-cut."
I am generally an advocate of "worse is better", or else why would I be using Arc? When discussing Arc, I do tend to have a "worse is better" attitude about it. But at the same time, I also care about "doing the Right Thing", so my thinking shifts when talking about Kernel.
Essentially, Kernel seems to me to be a marvelous language that embraces the "do the Right Thing" attitude, whereas Arc seems to be a marvelous language that embraces the "worse is better" attitude. I like both of them, they have different atmospheres and feelings about them.
So, I think it really does depend on what you want to do, what you expect out of a language, etc.
I must say, though, Kernel has captivated me recently. I'm a total sucker for minimalism and elegance, while at the same time caring about speed and practicality. Inner conflict!
"unless you mean all the perhaps-not-so-dangerous things John Shutt considered dangerous when writing the R-1RK"
I was being hand-wavy and meaning things similar to hygiene breaking, like the 2nd and 3rd things on your list of things you mentioned in your post. So, not necessarily all the things John Shutt considered dangerous, but certainly some of them.
"Maybe G3 becomes something like this [...] I might actually support a G3 worded this way"
Indeed, though I already understood it to mean "accidentally introducing bugs into a program", though I'm not sure how John Shutt meant it... but judging by the way he uses it in Kernel, I'd say my interpretation is roughly correct.
Chapter 7.3 of John's dissertation discusses it in more detail. I particularly like how John uses a form of currying as a way to avoid defining $quote. That would probably be the best place to start if you want to understand why Kernel doesn't have quote. In fact, §7.3 basically makes the exact same points I do (and then some), so I'd suggest reading that:
I'm not sure, but I think R5RS macros ('syntax-rules, 'let-syntax, 'letrec-syntax, maybe others?) walk the whole template code, taking advantage of their knowledge of special forms like 'let to know when a binding is being introduced.
I think Pauan might be referring to that as a missing feature of that quasisyntax form, regardless of whether that actually causes imperfect hygiene.
That's correct. For instance, with proper full hygiene, you could write do1 like this:
(mac do1 args
#`(let g ,(car args)
The only change is I removed the w/uniq wrapper: quasisyntax would automatically make g into a gensym. It doesn't currently do that, but it could.
That would make it essentially a fully hygienic system that's vaguely similar to Scheme's macros, but it's much easier to implement, and you can choose to easily break hygiene at any time (by using quote) rather than fussing with syntax->datum.
It's also fully compatible with Arc 3.1 macros, and you can freely choose to use quasiquote or quasisyntax, or hell, use both in the same macro!
Of course, this requires you to actually write the macros in that style. Normal quasiquote macros won't gain any benefit from hygiene in this model: you'd need to convert them to use quasisyntax instead (which is quite easy and even mechanical to do).
* : That part requires a compiler change, but I think it's an overall good compiler change that can benefit even non-quasisyntax macros. It works correctly in Nu and ar, but not Arc 3.1.
Wart has a perfectly traditional lexical and dynamic scope setup now. Much of that link I posted earlier is stale. I backed out of that experiment ages ago (and I think I said so before on this forum). If the current version still has something that seems off I'd love to hear it.
The bits that are non-traditional are: eval can only operate using the current lexical scope and dynamic bindings, and the eval inside macros happens implicitly because I can't provide the caller scope to it.
Looks like it's time to revise this. All my questions were really the same question, so your answer to one of them is perfectly complete.
Isn't that the point of fexprs, though? That they can selectively eval their arguments? So couldn't the "quote the argument to suppress evaluation" just desugar into a fexpr that evals the argument? Something like this...
(fn ('a b c . 'd)
...would desugar (macro expand) into this...
(fexpr (a b c . d) env
(with (b (eval b env)
c (eval c env))
...assuming that env is a gensym to avoid clashes with variables in the function's body.
That is, a fn would either be wrapped or not depending on whether a quote appears in its argument list. I'm actually not fond of that, and would prefer to explicitly use fexprs when I want to not evaluate things, but... it is consistent with wart's already existing support for things.
Of course, that means that "fn" doesn't always create a function. It might potentially create either a fexpr or a function... not sure if you want that.