On Mon, 12 Jul 2010 19:21:08 -0400, Nick Sabalausky <a...@a.a> wrote:
"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message
news:op.vfq0aydoeav...@localhost.localdomain...
On Mon, 12 Jul 2010 16:22:28 -0400, bearophile
<bearophileh...@lycos.com>
wrote:
Steven Schveighoffer:
bearophile:
> String mixins are a hack, just a bit better than C preprocessor
(because
> they are scoped), they are not a replacement of clean macros.
Interesting statement, can you back it up? :) What can you do with a
macro that you can't do with a mixin?
In the meantime others have already given you some answers, I can add
one example. The Brainfuck language allows you to do every kind of
thing, I have seen even compilers written in it, but its usage is very
unhandy, it's bug-prone, requires lot of code to do even simple things,
and it's very hard to modify and debug programs written in it. What I
meant is that string mixins in theory allow you to do many things, but
in practice you can't use them for complex tasks, and you can't modify
and fix the resulting code if you try to use them for more complex
tasks. They are not a long-term solution for a language that seriously
wants to improve over C and its preprocessor macros, they are a hack.
Brainfuck is basically a toy example of a language. Nobody uses it for
serious work. Mixins are much better than a hack, the syntax of using
them is just not polished. They are easy to use/understand because a)
people understand the language and b) people understand string
manipulation.
But when you're talking about the string being actual code, you're not
always talking about typical string manipulation, sometimes you're
talking
about parsing which is only "string manipulation" superficially.
Not in most cases. For extremes, I think perhaps there could be a niche
for that, but it can be had via string mixins and CTFE (as long as CTFE is
robust enough). Having a compiler written in D wouldn't hurt either ;)
I'll give you another example -- javascript and HTML editing. Most
people
would prefer to just use the innerHTML component of an element than have
to use the DOM methods to create individual elements and add them as
children, etc.
For writing, yes, but there's also reading: How many people do you know
who
would rather find the elements they want by parsing innerHTML instead of
just dealing with the readily-available tree? None, I would hope, but the
latter is essentially what we have to do for many of the more advanced
things that string mixins *technically* replace AST macros for.
But you can't manipulate D code "on the fly" as you can HTML.
Essentially, you are *always* writing code when using string manipulation
to do mixins, because the compiler hasn't parsed it yet.
Essentially, there is no requirement that the input that you are about to
manipulate must be valid D code, only the output should be. That isn't to
say it can't be valid D code, but in most cases, wouldn't you rather have
simpler input?
-Steve
