Create a word that returns its own name?
Joe Knapka
I'd like to be able to create words that return their own
names (among, perhaps, other things). Of course, I could
repeat myself:
: my-name-is [ s" my-name-is" ] sliteral ;
but, well... bleh.
In Gforth, I can do it this way:
: quine
create latest name>string , ,
does> dup @ swap 1 cells + @ swap ;
quine my-name-is
Is there a more succinct, or more portable way?
Thanks,
-- JK
Joe Knapka
> This is mainly a matter of curiosity.
>
> I'd like to be able to create words that return their own
> names (among, perhaps, other things). Of course, I could
> repeat myself:
>
> : my-name-is [ s" my-name-is" ] sliteral ;
I just realized that's even dumber than I thought. Pretend
I wrote:
: my-name-is s" my-name-is" ;
Funny how hitting "send" engages all those dormant neurons...
Daniel Kalny
body), hence it can be used to find the name of that word. I would
suggest this:
: QUINE
CREATE DOES>
BODY> >NAME NAME>STRING ;
QUINE MY-NAME-IS
It works in gforth, although I do not know whether it is more portable
with that NAME>STRING word. Regards,
Daniel
Anton Ertl
>In Gforth, I can do it this way:
>
> : quine
> create latest name>string , ,
> does> dup @ swap 1 cells + @ swap ;
>
> quine my-name-is
>
>Is there a more succinct,
: quine ( "name" -- )
create latest ,
does> ( c-addr u -- )
@ name>string ;
Or, if you want to do the NAME>STRING at definition time:
: quine ( "name" -- )
create latest name>string 2,
does> ( c-addr u -- )
2@ ;
> or more portable way?
\ uses PARSE-NAME, implementation in
\ http://www.forth200x.org/reference-implementations/parse-name.fs
: quine ( "name" -- )
>in @ >r
:
r> >in !
parse-name postpone sliteral
postpone ; ;
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
Daniel Kalny
> create latest ,
> does> ( c-addr u -- )
> @ name>string ;
>
the word's body? Is this LATEST , necessary?
Daniel
Anton Ertl
>: QUINE
>CREATE DOES>
>BODY> >NAME NAME>STRING ;
>
>QUINE MY-NAME-IS
>
>It works in gforth,
Not in general. >NAME is not guaranteed to work correctly for all
words. This should also answer your other question.
Joe Knapka
> Joe Knapka <jk.u...@kneuro.net> writes:
>
>>In Gforth, I can do it this way:
>>
>> : quine
>> create latest name>string , ,
>> does> dup @ swap 1 cells + @ swap ;
>>
>> quine my-name-is
>>
>>Is there a more succinct,
>
>
> : quine ( "name" -- )
> create latest ,
> does> ( c-addr u -- )
> @ name>string ;
>
> Or, if you want to do the NAME>STRING at definition time:
>
> : quine ( "name" -- )
> create latest name>string 2,
> does> ( c-addr u -- )
> 2@ ;
Both of those are much clearer and more obvious than
mine. For some reason it did not occur to me to simply
compile the NT, even though the repeated work of acquiring,
taking apart, and later re-building the same string
was staring me in the face. I'll watch for that kind
of thing in future.
Thanks,
-- JK
Brad Eckert
Anton Ertl wrote:
>
> \ uses PARSE-NAME, implementation in
> \ http://www.forth200x.org/reference-implementations/parse-name.fs
> : quine ( "name" -- )
> >in @ >r
> :
> r> >in !
> parse-name postpone sliteral
> postpone ; ;
>
Besides being less wordy and allowing strings over 255 chars, what is
the advantage of using "PARSE-NAME" instead of "BL WORD COUNT" ?
Brad
Coos Haak
At first, it does no needless copying of the string to a character counted
string which may be at HERE but can be elsewhere. The string (c-addr u) is
still in the input buffer.
Next, as nearly every name parsing uses BL as delimiter, it is implicite
and white space before the string is skipped.
Third, the string is returned as a c-addr u pair, not the address of a
counted string. Counted strings are akward to handle, e.g. appending and
splitting.
<ASIDE>
I even have WORD and FIND in user loadable file, I removed them from my
working system. IMHO they are not needed. I have a FIND that uses c/u
pairs. Much more flexible.
</ASIDE>
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Anton Ertl
The main reason is that we should be getting rid of WORD.
However, thinking more about it, there is another reason: There might
be systems that don't get this particular combination of WORD and
SLITERAL right. The problem is that WORD puts its stuff HERE in many
systems, and SLITERAL might store something HERE before copying the
string to its final destination.
Hmm, I just tried it on Gforth and on PFE 0.33.34, and it did not work
as intended on either.
J Thomas
Daniel Kalny wrote:
> It works in gforth, although I do not know whether it is more portable
> with that NAME>STRING word. Regards,
>NAME etc are not present in the 94 standard, and they are as portable as they happen to be.
If you use them the way they are defined in the Forth-83 standard, then
they should work correctly on all Forth-83 standard systems. I don't
know how many that is, but people will tend to keep doing it the old
way unless they find a reason to change so it might work in a lot of
cases.
John Passaniti
> In Gforth, I can do it this way:
>
> : quine
> create latest name>string , ,
> does> dup @ swap 1 cells + @ swap ;
>
> quine my-name-is
>
> Is there a more succinct, or more portable way?
Others can work on that particular problem because I don't find it
terribly interesting or useful. What I wanted to comment on is the odd
choice of naming the word "quine". At least traditionally, a quine is a
program that reproduces its source, not a program that emits its own name.
Joe Knapka
> Others can work on that particular problem because I don't find it
> terribly interesting or useful.
Good on you, then. I actually have a use for this, though
it may not qualify as interesting or useful for you. (Was there
any purpose to this part of your post?)
> What I wanted to comment on is the odd
> choice of naming the word "quine". At least traditionally, a quine is a
> program that reproduces its source, not a program that emits its own name.
A word created by QUINE *is* a quine: a program consisting
solely of such a word will reproduce its source. (Yes, there is
code that must be loaded before such a program will run,
but that is true of practically all quines.) So maybe a better
name for QUINE would be "CREATE-QUINE".
Regards,
-- JK
John Passaniti
>> Others can work on that particular problem because I don't find it
>> terribly interesting or useful.
>
> Good on you, then. I actually have a use for this, though
> it may not qualify as interesting or useful for you. (Was there
> any purpose to this part of your post?)
Sure. It's another way of asking the question of how this is useful or
interesting. You now say you have a use-- neat. I'd be delighted to
learn it and expand my horizons.
>> What I wanted to comment on is the odd choice of naming the word
>> "quine". At least traditionally, a quine is a program that reproduces
>> its source, not a program that emits its own name.
>
> A word created by QUINE *is* a quine: a program consisting
> solely of such a word will reproduce its source. (Yes, there is
> code that must be loaded before such a program will run,
> but that is true of practically all quines.) So maybe a better
> name for QUINE would be "CREATE-QUINE".
I think you have a fundamental misunderstanding of what a quine is, and
I have yet to see any quine where code "must be loaded before such a
program will run". I invite you to educate me with an actual example of
such a quine. I've never seen any.
For a quine to work, you should be able to take the output *alone* and
have a working program.
What you have may be useful or interesting. But it isn't a quine. At
least not by any definition I've seen.
Alex McDonald
http://www.nyx.net/~gthompso/self_forth.txt
: ME S" SEE ME" EVALUATE ;
I think Elko may have been using Win32Forth.
--
Regards
Alex McDonald
Joe Knapka
> Joe Knapka wrote:
>
>>> Others can work on that particular problem because I don't find it
>>> terribly interesting or useful.
>>
>>
>> Good on you, then. I actually have a use for this, though
>> it may not qualify as interesting or useful for you. (Was there
>> any purpose to this part of your post?)
>
>
> Sure. It's another way of asking the question of how this is useful or
> interesting. You now say you have a use-- neat. I'd be delighted to
> learn it and expand my horizons.
I'm using it to name Tk widgets with Forth words. The Forth word
representing a particular widget (which happens to have the same
name as the widget in question) leaves the widget name (== the name
of the Forth word representing the widget) on the stack, so that
I can pass that name along to the Tcl interpreter.
It's not clear to me yet whether this is the most effective way
of interacting with Tk, but it works.
>>> What I wanted to comment on is the odd choice of naming the word
>>> "quine". At least traditionally, a quine is a program that
>>> reproduces its source, not a program that emits its own name.
>>
>>
>> A word created by QUINE *is* a quine: a program consisting
>> solely of such a word will reproduce its source. (Yes, there is
>> code that must be loaded before such a program will run,
>> but that is true of practically all quines.) So maybe a better
>> name for QUINE would be "CREATE-QUINE".
>
>
> I think you have a fundamental misunderstanding of what a quine is,
You're certainly entitled to that belief. Originally, I only named
the word "quine" because it produced words with a vaguely
quine-like effect. But after further consideration, I think the
word "quine" is perfectly applicable to any word created by
CREATE-QUINE. So let's throw down :-)
> and
> I have yet to see any quine where code "must be loaded before such a
> program will run". I invite you to educate me with an actual example of
> such a quine. I've never seen any.
For example, most quines are probably written by CS majors
on Linux boxes in C, and therefore depend on libc (and lots
of other stuff). You want a concrete example? Here's my
effort from sometime during my college years:
void p(char c){putchar(c);}char* s="main(){int
i,j;for(j=0;j<2;++j){i=0;if(!j){printf(\"void p(char
c){putchar(c);}char*
s=\");p(34);}while(s[i]){if(!j)if(34==s[i])p(92);p(s[i]);++i;}if(!j){p(34);p(59);}p(10);}}";
main(){int i,j;for(j=0;j<2;++j){i=0;if(!j){printf("void p(char
c){putchar(c);}char*
s=");p(34);}while(s[i]){if(!j)if(34==s[i])p(92);p(s[i]);++i;}if(!j){p(34);p(59);}p(10);}}
When compiled by gcc and run on my Linux box, it produces its source
(modulo line wrap). It does not, however, produce the source code
of GCC, glibc, or the Linux kernel, all of which are intimately
involved in its self-reproductive activity.
> For a quine to work, you should be able to take the output *alone* and
> have a working program.
"Working" in what context? If I take the code above *alone*,
I have a text file that doesn't do much of anything.
The context required for a quine whose source is the
name of a word created by CREATE-QUINE to work, is that it be
interpreted by a FORTH image containing a particular word created
by CREATE-QUINE. For example, if I create a file containing the
following text:
\ QUINE.F -- a slight variation on CREATE-QUINE.
: create-quine latest , does> @ name>string type cr ;
create-quine quine
and then do:
gforthmi quine.fi QUINE.F
then quine.fi is a Gforth image that, when asked to interpret
the source code
quine
produces the output
quine
In what way is the source code consisting of just the word
"quine" any less a quine than the preceding C code?
You might consider such a Forth image "cheating", but if so,
wouldn't you have to say the same thing about all those freshman
C quine programs that depend upon GCC etc?
All quines depend on context. Even if you have no OS on a particular
machine, any quine you might create for that machine would depend
on some underlying mechanism for displaying the quine's source code
in a human-readable way. CREATE-QUINE produces a *context* that is
custom-designed to permit a *particular* quine to be written.
Admittedly, this is more context than most people would like to
depend upon, but IMO the word "quine" is still applicable.
You may be bothered by the fact that in this case, the context
actually contains a copy of the source code in question. Does
that somehow invalidate the quine-ness of the source code "quine"?
I don't think so, but if you disagree, then consider a Forth image
extended with the following word:
: quine cr ." quine " parse-word type cr ;
In this case, we have a context that does *not* contain the
source of any particular quine, yet in which any program of the
form
quine something
is a quine.
Now, the original CREATE-QUINE creates words that leave their
names on the stack, rather than writing them to the screen.
Do we need to argue about whether the destination of the output
is part of the fundamental definition of "quine"?
-- JK
John Passaniti
> It's not clear to me yet whether this is the most effective way
> of interacting with Tk, but it works.
I'm not sure either, and not being terribly familiar with Tk bindings I
have no comment.
>> and I have yet to see any quine where code "must be loaded before such
>> a program will run". I invite you to educate me with an actual
>> example of
>> such a quine. I've never seen any.
>
> For example, most quines are probably written by CS majors
> on Linux boxes in C, and therefore depend on libc (and lots
> of other stuff).
That's completely ridiculous.
The purpose of a quine is not to reproduce every last bit of software
involved in creating the self-reproducing program. The purpose of a
quine is limited to something simple and specific: Reproducing the
complete source code of the program itself. That's it.
You are free to come up with a private definition of a quine, but what
you're describing matches no definition I can find. You're also free to
play semantic games and warp definitions as you choose. But anyone
going to any of the quine pages can easily and intuitively see what a
quine is, and can see that what you're doing-- useful as it may be-- is
not a quine.
Joe Knapka
> Joe Knapka wrote:
>
>> It's not clear to me yet whether this is the most effective way
>> of interacting with Tk, but it works.
>
>
> I'm not sure either, and not being terribly familiar with Tk bindings I
> have no comment.
>
>>> and I have yet to see any quine where code "must be loaded before
>>> such a program will run". I invite you to educate me with an actual
>>> example of
>>> such a quine. I've never seen any.
>>
>>
>> For example, most quines are probably written by CS majors
>> on Linux boxes in C, and therefore depend on libc (and lots
>> of other stuff).
>
>
> That's completely ridiculous.
>
> The purpose of a quine is not to reproduce every last bit of software
> involved in creating the self-reproducing program. The purpose of a
> quine is limited to something simple and specific: Reproducing the
> complete source code of the program itself. That's it.
Which is exactly what I said: the context in which a quine is
executed *need not* be reproduced by the quine, in order for
it to count as a quine. I'm glad we agree.
-- JK
J Thomas
John Passaniti wrote:
> Others can work on that particular problem because I don't find it
> terribly interesting or useful.
> Sure. It's another way of asking the question of how this is useful or
> interesting. You now say you have a use-- neat. I'd be delighted to
> learn it and expand my horizons.
I can't imagine a group where I'd be the best person to coach a
clueless person about polite social interactions. But lacking anybody
else attempting it....
Never mind. Just think about it.
Elizabeth D Rather
Well said. Thank you!
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
John Passaniti
> I can't imagine a group where I'd be the best person to coach a
> clueless person about polite social interactions. But lacking anybody
> else attempting it....
>
> Never mind. Just think about it.
No, I would rather remind anyone offended by my offering that I didn't
find something interesting or useful to simply block future messages
from me. I'm likely to say something far worse in the future, and I
wouldn't want other's delicate sensibilities to be tweaked.
John Passaniti
> Which is exactly what I said: the context in which a quine is
> executed *need not* be reproduced by the quine, in order for
> it to count as a quine. I'm glad we agree.
Then in that case, the following is a Forth quine:
JoeKnapka
As you don't believe that code beyond what is provided by the language
itself is necessary to be emitted, this perfectly valid Forth program
perfectly qualifies. Given the other responses to your original email,
I think I clearly win.
And using that same logic, the following are also quines in other
languages. Here's C:
quine();
And here's one in Lisp:
(quine)
Thanks Joe for making quines so easy! All anyone has to do now is
simply say that the context has pre-existing code in it that does the
actual "quineing." Your innovative approach now leads to other exciting
possibilities to improve productivity. For example, using your
techniques, I have replaced the application code I've worked on with this:
DOIT
I simply rely on the execution context to have the necessary code in it.
Not even Charles Moore could factor that!
Aleksejj Saushev
> And using that same logic, the following are also quines in
> other languages. Here's C:
>
> quine();
>
> And here's one in Lisp:
>
> (quine)
>
> Thanks Joe for making quines so easy! All anyone has to do now
> is simply say that the context has pre-existing code in it that
> does the actual "quineing." Your innovative approach now leads
> to other exciting possibilities to improve productivity. For
> example, using your techniques, I have replaced the application
> code I've worked on with this:
>
> DOIT
>
> I simply rely on the execution context to have the necessary
> code in it. Not even Charles Moore could factor that!
Maybe, we should include QUINE into the standard?
This should reveal all the power of Forth,
the most free to modify programming language in the world.
Anton Ertl
>Maybe, we should include QUINE into the standard?
Well, we already have a quine-type word in the standard: SOURCE. Use it
like
source type
and you have a quine program.
John Passaniti
> Maybe, we should include QUINE into the standard?
It would certainly save time.
> This should reveal all the power of Forth,
> the most free to modify programming language in the world.
Modify Forth so that it isn't stack based or use a dictionary.
John Passaniti
> Well, we already have a quine-type word in the standard: SOURCE. Use it
> like
>
> source type
>
> and you have a quine program.
Does anyone here understand what a quine is? Is it that difficult to
Google the term and learn both what it means and why it is interesting
from a computer science perspective?
Not that Wikipedia is the last word on anything, but the definition
provided there is consistent with the one I've seen *everywhere* else:
http://en.wikipedia.org/wiki/Quine
So "source type" is not a quine program (unless "source type" was the
output). The point of a quine is not that when you type in something
you get the source for something else. The point of a quine is that
when you execute a particular program, you get back the source of that
same program.
Anton Ertl
>So "source type" is not a quine program (unless "source type" was the
>output).
If you don't know that by heart, just try it.
>The point of a quine is not that when you type in something
>you get the source for something else. The point of a quine is that
>when you execute a particular program, you get back the source of that
>same program.
That's exactly what the program
source type
does.
George Hubert
How about;
: QUINE S" SEE QUINE" EVALUATE ;
works in W32F V6.11.10 exactly (I cut and pasted the output -;)
George Hubert
John Passaniti
> : QUINE S" SEE QUINE" EVALUATE ;
>
> works in W32F V6.11.10 exactly (I cut and pasted the output -;)
A quine much like this was submitted here:
http://www.nyx.net/~gthompso/quine.htm
This is a quine (assuming your 'see' generates *exactly* the same
thing), but it's obviously specific to a particular implementation of
Forth. In the implementation of Forth I currently have handy (pForth),
I see this when I execute 'quine':
( 40179A3C ) S" SEE QUINE" EVALUATE ;
So no, at least for this particular implementation of Forth, 'see' is
not a sufficient quine generator since the output isn't the same as the
input.
Those wondering why any of this matters should actually try to write a
quine that doesn't depend on having a decompiler. It's not a trivial
problem and it can lead to some interesting insights.
John Passaniti
> John Passaniti <nn...@JapanIsShinto.com> writes:
>> So "source type" is not a quine program (unless "source type" was the
>> output).
>
> If you don't know that by heart, just try it.
Ah, you're right.
Yes. Finally we have a true quine. Now we just have to submit it to
Marcel Hendrix
> John Passaniti <nn...@JapanIsShinto.com> writes:
[..]
>> The point of a quine is not that when you type in something
>> you get the source for something else. The point of a quine is that
>> when you execute a particular program, you get back the source of that
>> same program.
> That's exactly what the program
> source type
> does.
Older, but still guaranteed to work:
TIB 11 TYPE
-marcel
John Passaniti
> Older, but still guaranteed to work:
>
> TIB 11 TYPE
Well, that's pretty much the same thing as "source type".
Okay, now that we're probably going down endless variations on simply
echoing the input buffer, how about we see if someone can come up with a
Forth quine that doesn't rely on such a mechanism.
Why? Because while (I believe) this matches the *letter* of what a
quine must do in order to be a quine, it doesn't match the *spirit*.
Part of the joy of writing quines is in figuring out a way to express
the source of a program as data that can be emitted. Really guys, try
it. It's more difficult than it may appear, which will become apparent
the moment you try it.
Neal Bridges
news:I_eTg.1920$ya1...@news02.roc.ny...
: quine [ source ] sliteral type ; quine
--
Neal Bridges
http://quartus.net Home of Quartus Forth for the Palm OS!
John Doty
> Well, that's pretty much the same thing as "source type".
>
> Okay, now that we're probably going down endless variations on simply
> echoing the input buffer, how about we see if someone can come up with a
> Forth quine that doesn't rely on such a mechanism.
>
> Why? Because while (I believe) this matches the *letter* of what a
> quine must do in order to be a quine, it doesn't match the *spirit*.
> Part of the joy of writing quines is in figuring out a way to express
> the source of a program as data that can be emitted. Really guys, try
> it. It's more difficult than it may appear, which will become apparent
> the moment you try it.
>
Over a year ago, I wrote the following to my son (who had helped me
implement dynamic linking in LSE64, but didn't know the language well)
after he told me about a homework assignment involving quining in Lisp:
Quining in LSE
I realized a self-printing program is really easy in LSE64:
" 34 put sp dup ,t 34 put sp ,t" 34 put sp dup ,t 34 put sp ,t
The main trick is using "34 put" to print a quote mark, thereby
trivially avoiding the problem of quoting a literal quote mark (for
which LSE has no mechanism anyway). A Gödelian trick, to my thinking.
Note that:
sp prints a space
dup duplicates the stack top (in this case, the address of the string to
be quined).
,t prints a string
So, the program
34 put sp dup ,t 34 put sp ,t
prints a string from the top of the stack twice, once quoted, once not.
Precede it by itself quoted, and you have a program that prints itself.
Inspired by Hofstadter's
"Yields falsehood when preceded by its quotation" yields falsehood when
preceded by its quotation.
--
John Doty, Noqsi Aerospace, Ltd.
--
In theory there is no difference between theory and practice. In
practice there is. -Yogi Berra
Joe Knapka
Nice. So the following might satisfy Mr Passaniti's request :-)
s" 2dup cr 115 emit 34 emit space type 34 emit space type cr" 2dup cr
115 emit 34 emit space type 34 emit space type cr
I like to add the CRs so that the quine-ness of the result is
completely obvious.
Incidentally, my naming of the word "quine" at the start of this thread
was directly inspired by the same chapter of GEB, wherein Hofstadter
briefly discusses a language specifically designed to produce quines.
-- JK
John Passaniti
> : quine [ source ] sliteral type ; quine
Like I wrote, there are likely to be endless variations on simply
echoing the input buffer, and you provided another one. This is better
than the previous ones in that you're actually storing the source's text
in the definition.
Please submit it here:
http://www.nyx.net/~gthompso/quine.htm
But again, you're meeting the letter of what a quine must do, but not
the spirit. Your solution (and any solution based on capturing the
input buffer) is much like the joke solution of how to measure the
height of a building with a barometer (you give the barometer to someone
who knows the height of the building in exchange for that knowledge).
Honestly, just try it.
John Passaniti
> Quining in LSE
>
> I realized a self-printing program is really easy in LSE64:
>
> " 34 put sp dup ,t 34 put sp ,t" 34 put sp dup ,t 34 put sp ,t
>
> The main trick is using "34 put" to print a quote mark, thereby
> trivially avoiding the problem of quoting a literal quote mark (for
> which LSE has no mechanism anyway). A Gödelian trick, to my thinking.
Good. You captured the essence of what a quine is about. It doesn't
(or shouldn't) take much imagination to translate this to Forth.
Now, let me add one small twist. In many other languages (like C) you
can't have immediately executable code outside the context of some kind
of named entity. That's not a problem with Forth and LSE and many other
interpreted languages. But let's say you didn't have that ability.
Let's say you had to create a definition in order to execute it. Or
equivalently, let's say I want to create a word named "quine" that when
executed returns its source.
How would you do that?
This same question is open for Forthers as well.
Marcel Hendrix
> Neal Bridges wrote:
>> : quine [ source ] sliteral type ; quine
[..]
> But again, you're meeting the letter of what a quine must do, but not
> the spirit. Your solution (and any solution based on capturing the
> input buffer) is much like the joke solution of how to measure the
> height of a building with a barometer (you give the barometer to someone
> who knows the height of the building in exchange for that knowledge).
> Honestly, just try it.
Honestly, you have been changing the goalposts each time somebody met your
challenge.
From your reply to John Doty:
> Now, let me add one small twist. In many other languages (like C) you
> can't have immediately executable code outside the context of some kind
> of named entity. That's not a problem with Forth and LSE and many other
> interpreted languages. But let's say you didn't have that ability.
> Let's say you had to create a definition in order to execute it. Or
> equivalently, let's say I want to create a word named "quine" that when
> executed returns its source.
This is exactly what Neal gave you.
-marcel
John Passaniti
>> Honestly, just try it.
>
> Honestly, you have been changing the goalposts each time somebody met your
> challenge.
It was my assumption that people who were interested in this would read
about quines in any of the URLs I provided, or in the many other
resources on the subject that were available. Google is your friend.
It was my assumption that when people looked at quines in other
languages, they would see the basic problems that quines solve
(representing a program as data, coming up with a program that emitted
that data while getting quoting right, and doing all this in a minimal way).
It was my assumption that when people looked at quines in other
languages, they would recognize that decompilation and recording input
text would be trivial and uninteresting, at least compared to the class
of solutions offered by others.
It was my assumption that people would seek to find portable solutions
(which meant using the decompiler was out).
It was my assumption that instead of trivial and uninteresting solutions
involving capturing input source text, people would look at other quines
and try to solve that challenge.
So yes, I guess I did in a sense change the goalposts. And that's
because of some combination of the following:
1. The solutions were non-portable.
2. The solutions were trivial and uninteresting.
3. The solutions didn't solve the problem that quines address.
If you and others are happy with the solutions that use the decompiler
or that capture the input buffer, who am I to complain? Others who
"get" what quines are about and who enjoy these kinds of puzzles will
push forward and maybe gain some valuable insights.
>> Now, let me add one small twist. In many other languages (like C) you
>> can't have immediately executable code outside the context of some kind
>> of named entity. That's not a problem with Forth and LSE and many other
>> interpreted languages. But let's say you didn't have that ability.
>> Let's say you had to create a definition in order to execute it. Or
>> equivalently, let's say I want to create a word named "quine" that when
>> executed returns its source.
>
> This is exactly what Neal gave you.
Thanks for illustrating the problem. You quote a message from me to
John Doty where I acknowledge that his code is exactly the kind of thing
that quines are about. You threw away that context, and quote a later
paragraph where I suggest a small addition to John's code. Your focus
on the result and not the depth of the solution is the problem.
Neal Bridges
news:TGoTg.776$0L1...@twister.nyroc.rr.com...
> Neal Bridges wrote:
> > : quine [ source ] sliteral type ; quine
> But again, you're meeting the letter of what a quine must do, but not
> the spirit. Your solution (and any solution based on capturing the
> input buffer) is much like the joke solution of how to measure the
> height of a building with a barometer (you give the barometer to someone
> who knows the height of the building in exchange for that knowledge).
It's not a joke solution. Quines in most other languages are based on
providing the quine source text as a string inside the quine source, using
whatever mechanism the particular language provides for substituting the
string delimiters. Forth is a reflective language, and thus makes the
substitution unnecessary.
The program:
source type
is an entirely sufficient Forth quine, both in letter and in spirit. I
provided the longer one up top as a colon-definition, as I thought it might
appeal to people with a narrower definition of 'program'.
> Honestly, just try it.
Did, and done. It's a trivial exercise in Forth.
Anton Ertl
[source type]
>Yes. Finally we have a true quine. Now we just have to submit it to
>
>http://www.nyx.net/~gthompso/quine.htm
Do we have to? I see it right on top of
<http://www.nyx.net/~gthompso/self_forth.txt>, and that page was last
modified on 10/03/99 00:55:39.
Given your complaints about others not reading the pages you refer to,
one would think that you would at least read them yourself, but that's
apparently not the case.
Neal Bridges
complexity.
----------------------cut here-----------------------
decimal
create data
092 c, 032 c, 065 c, 032 c, 070 c, 111 c, 114 c, 116 c,
104 c, 032 c, 113 c, 117 c, 105 c, 110 c, 101 c, 046 c,
032 c, 032 c, 078 c, 101 c, 097 c, 108 c, 032 c, 066 c,
114 c, 105 c, 100 c, 103 c, 101 c, 115 c, 044 c, 032 c,
083 c, 101 c, 112 c, 116 c, 101 c, 109 c, 098 c, 101 c,
114 c, 032 c, 050 c, 048 c, 048 c, 054 c, 046 c, 010 c,
092 c, 032 c, 084 c, 104 c, 101 c, 032 c, 113 c, 117 c,
105 c, 099 c, 107 c, 101 c, 115 c, 116 c, 032 c, 070 c,
111 c, 114 c, 116 c, 104 c, 032 c, 113 c, 117 c, 105 c,
110 c, 101 c, 032 c, 105 c, 115 c, 032 c, 115 c, 105 c,
109 c, 112 c, 108 c, 121 c, 058 c, 032 c, 115 c, 111 c,
117 c, 114 c, 099 c, 101 c, 032 c, 116 c, 121 c, 112 c,
101 c, 010 c, 092 c, 032 c, 083 c, 111 c, 109 c, 101 c,
032 c, 109 c, 097 c, 121 c, 032 c, 112 c, 114 c, 101 c,
102 c, 101 c, 114 c, 058 c, 032 c, 032 c, 058 c, 032 c,
113 c, 117 c, 105 c, 110 c, 101 c, 032 c, 032 c, 091 c,
032 c, 115 c, 111 c, 117 c, 114 c, 099 c, 101 c, 032 c,
093 c, 032 c, 115 c, 108 c, 105 c, 116 c, 101 c, 114 c,
097 c, 108 c, 032 c, 116 c, 121 c, 112 c, 101 c, 032 c,
059 c, 032 c, 113 c, 117 c, 105 c, 110 c, 101 c, 010 c,
092 c, 032 c, 070 c, 111 c, 114 c, 032 c, 116 c, 104 c,
101 c, 032 c, 114 c, 101 c, 115 c, 116 c, 044 c, 032 c,
116 c, 104 c, 101 c, 114 c, 101 c, 039 c, 115 c, 032 c,
116 c, 104 c, 105 c, 115 c, 032 c, 097 c, 098 c, 115 c,
117 c, 114 c, 100 c, 108 c, 121 c, 045 c, 099 c, 111 c,
109 c, 112 c, 108 c, 101 c, 120 c, 032 c, 118 c, 101 c,
114 c, 115 c, 105 c, 111 c, 110 c, 033 c, 010 c, 010 c,
049 c, 048 c, 032 c, 099 c, 111 c, 110 c, 115 c, 116 c,
097 c, 110 c, 116 c, 032 c, 101 c, 111 c, 108 c, 010 c,
056 c, 032 c, 099 c, 111 c, 110 c, 115 c, 116 c, 097 c,
110 c, 116 c, 032 c, 100 c, 097 c, 116 c, 097 c, 045 c,
119 c, 105 c, 100 c, 116 c, 104 c, 010 c, 048 c, 032 c,
099 c, 111 c, 110 c, 115 c, 116 c, 097 c, 110 c, 116 c,
032 c, 115 c, 101 c, 110 c, 116 c, 105 c, 110 c, 101 c,
108 c, 010 c, 010 c, 058 c, 032 c, 113 c, 117 c, 105 c,
110 c, 101 c, 045 c, 104 c, 101 c, 097 c, 100 c, 101 c,
114 c, 032 c, 040 c, 032 c, 045 c, 045 c, 032 c, 041 c,
032 c, 032 c, 046 c, 034 c, 032 c, 100 c, 101 c, 099 c,
105 c, 109 c, 097 c, 108 c, 034 c, 032 c, 099 c, 114 c,
032 c, 046 c, 034 c, 032 c, 099 c, 114 c, 101 c, 097 c,
116 c, 101 c, 032 c, 100 c, 097 c, 116 c, 097 c, 034 c,
032 c, 099 c, 114 c, 032 c, 059 c, 010 c, 010 c, 058 c,
032 c, 046 c, 100 c, 097 c, 116 c, 097 c, 032 c, 040 c,
032 c, 099 c, 104 c, 097 c, 114 c, 032 c, 045 c, 045 c,
032 c, 041 c, 032 c, 032 c, 115 c, 062 c, 100 c, 032 c,
060 c, 035 c, 032 c, 035 c, 032 c, 035 c, 032 c, 035 c,
032 c, 035 c, 062 c, 032 c, 116 c, 121 c, 112 c, 101 c,
032 c, 046 c, 034 c, 032 c, 032 c, 099 c, 044 c, 032 c,
034 c, 032 c, 059 c, 010 c, 010 c, 058 c, 032 c, 063 c,
099 c, 114 c, 032 c, 040 c, 032 c, 097 c, 100 c, 100 c,
114 c, 032 c, 045 c, 045 c, 032 c, 097 c, 100 c, 100 c,
114 c, 032 c, 041 c, 032 c, 032 c, 100 c, 117 c, 112 c,
032 c, 049 c, 043 c, 032 c, 100 c, 097 c, 116 c, 097 c,
045 c, 119 c, 105 c, 100 c, 116 c, 104 c, 032 c, 109 c,
111 c, 100 c, 032 c, 048 c, 061 c, 032 c, 105 c, 102 c,
032 c, 099 c, 114 c, 032 c, 116 c, 104 c, 101 c, 110 c,
032 c, 059 c, 010 c, 010 c, 058 c, 032 c, 113 c, 117 c,
105 c, 110 c, 101 c, 045 c, 100 c, 097 c, 116 c, 097 c,
032 c, 040 c, 032 c, 045 c, 045 c, 032 c, 041 c, 010 c,
032 c, 032 c, 048 c, 032 c, 098 c, 101 c, 103 c, 105 c,
110 c, 032 c, 032 c, 100 c, 117 c, 112 c, 032 c, 099 c,
104 c, 097 c, 114 c, 115 c, 032 c, 100 c, 097 c, 116 c,
097 c, 032 c, 043 c, 032 c, 099 c, 064 c, 032 c, 063 c,
100 c, 117 c, 112 c, 032 c, 119 c, 104 c, 105 c, 108 c,
101 c, 032 c, 032 c, 046 c, 100 c, 097 c, 116 c, 097 c,
032 c, 032 c, 063 c, 099 c, 114 c, 032 c, 032 c, 099 c,
104 c, 097 c, 114 c, 043 c, 032 c, 114 c, 101 c, 112 c,
101 c, 097 c, 116 c, 032 c, 032 c, 100 c, 114 c, 111 c,
112 c, 010 c, 032 c, 032 c, 115 c, 101 c, 110 c, 116 c,
105 c, 110 c, 101 c, 108 c, 032 c, 046 c, 100 c, 097 c,
116 c, 097 c, 032 c, 032 c, 099 c, 114 c, 032 c, 099 c,
114 c, 032 c, 059 c, 010 c, 010 c, 058 c, 032 c, 046 c,
099 c, 104 c, 097 c, 114 c, 032 c, 040 c, 032 c, 099 c,
104 c, 097 c, 114 c, 032 c, 045 c, 045 c, 032 c, 041 c,
032 c, 032 c, 100 c, 117 c, 112 c, 032 c, 101 c, 111 c,
108 c, 032 c, 061 c, 032 c, 105 c, 102 c, 032 c, 032 c,
100 c, 114 c, 111 c, 112 c, 032 c, 099 c, 114 c, 032 c,
032 c, 101 c, 108 c, 115 c, 101 c, 032 c, 032 c, 101 c,
109 c, 105 c, 116 c, 032 c, 032 c, 116 c, 104 c, 101 c,
110 c, 032 c, 059 c, 010 c, 010 c, 058 c, 032 c, 113 c,
117 c, 105 c, 110 c, 101 c, 045 c, 099 c, 111 c, 100 c,
101 c, 032 c, 040 c, 032 c, 045 c, 045 c, 032 c, 041 c,
010 c, 032 c, 032 c, 100 c, 097 c, 116 c, 097 c, 032 c,
098 c, 101 c, 103 c, 105 c, 110 c, 032 c, 032 c, 100 c,
117 c, 112 c, 032 c, 099 c, 064 c, 032 c, 032 c, 063 c,
100 c, 117 c, 112 c, 032 c, 119 c, 104 c, 105 c, 108 c,
101 c, 032 c, 032 c, 046 c, 099 c, 104 c, 097 c, 114 c,
032 c, 032 c, 099 c, 104 c, 097 c, 114 c, 043 c, 032 c,
114 c, 101 c, 112 c, 101 c, 097 c, 116 c, 032 c, 032 c,
100 c, 114 c, 111 c, 112 c, 032 c, 059 c, 010 c, 010 c,
058 c, 032 c, 113 c, 117 c, 105 c, 110 c, 101 c, 032 c,
040 c, 032 c, 045 c, 045 c, 032 c, 041 c, 032 c, 032 c,
113 c, 117 c, 105 c, 110 c, 101 c, 045 c, 104 c, 101 c,
097 c, 100 c, 101 c, 114 c, 032 c, 032 c, 113 c, 117 c,
105 c, 110 c, 101 c, 045 c, 100 c, 097 c, 116 c, 097 c,
032 c, 032 c, 113 c, 117 c, 105 c, 110 c, 101 c, 045 c,
099 c, 111 c, 100 c, 101 c, 032 c, 059 c, 010 c, 010 c,
113 c, 117 c, 105 c, 110 c, 101 c, 010 c, 000 c,
\ A Forth quine. Neal Bridges, September 2006.
\ The quickest Forth quine is simply: source type
\ Some may prefer: : quine [ source ] sliteral type ; quine
\ For the rest, there's this absurdly-complex version!
10 constant eol
8 constant data-width
0 constant sentinel
: quine-header ( -- ) ." decimal" cr ." create data" cr ;
: .data ( char -- ) s>d <# # # # #> type ." c, " ;
: ?cr ( addr -- addr ) dup 1+ data-width mod 0= if cr then ;
: quine-data ( -- )
0 begin dup chars data + c@ ?dup while .data ?cr char+ repeat drop
sentinel .data cr cr ;
: .char ( char -- ) dup eol = if drop cr else emit then ;
: quine-code ( -- )
data begin dup c@ ?dup while .char char+ repeat drop ;
: quine ( -- ) quine-header quine-data quine-code ;
quine
----------------------cut here-------------------------------
Neal Bridges
There's a char+ in there that should be a 1+. Nothing that slows it down
under Gforth 0.6.2 though. I'd correct and re-post, but one version of that
monstrostiy is more than enough in the world.
Anton Ertl
>Inspired by Hofstadter's
>
>"Yields falsehood when preceded by its quotation" yields falsehood when
>preceded by its quotation.
This sentence is known as Quine's paradox, and since quines in many
languages follow the structure of this sentence, I guess that is the
reason for naming such programs quines (and not Hofstadters:-).
Anton Ertl
>Marcel Hendrix wrote:
>> Honestly, you have been changing the goalposts each time somebody met your
>> challenge.
That's good. It results in a number of quines that highlight various
features of Forth. I have collected them at
<http://www.complang.tuwien.ac.at/forth/quines.html>.
>It was my assumption that when people looked at quines in other
>languages, they would recognize that decompilation and recording input
>text would be trivial and uninteresting, at least compared to the class
>of solutions offered by others.
People using other languages have used more complex (or, if you like,
more interesting) solutions because their languages did not offer the
features Forth has. So, basically, it seems to me that what you are
asking of us is to restrict ourselves to features in Forth that
Algol-family languages have.
Similarly, solutions in other languages become longer, and therefore
maybe more interesting if you disallow some of the features of the
language. E.g., the C solutions generally use printf. How about
disallowing that? They also use strings. How about disallowing that?
Neal Bridges
news:2006Sep3...@mips.complang.tuwien.ac.at...
> John Passaniti <my-first-...@JapanIsShinto.com> writes:
> >Marcel Hendrix wrote:
> >> Honestly, you have been changing the goalposts each time somebody met
your
> >> challenge.
>
> That's good. It results in a number of quines that highlight various
> features of Forth. I have collected them at
> <http://www.complang.tuwien.ac.at/forth/quines.html>.
Here's a shorter and far more obfuscated version of the clumsy way of doing
it in Forth. This is all one line (though doubtless mangled into several by
UseNet), so it depends on a long-enough input buffer. Works fine in Gforth
0.6.2:
36 base ! create d 1M c, W c, 35 c, W c, 1A c, Y c, W c, 1F c, 1I c, W c, 2Q
c, 2P c, 37 c, 2T c, W c, X c, W c, 2R c, 36 c, 2T c, 2P c, 38 c, 2T c, W c,
2S c, W c, Y c, W c, 2S c, W c, 1E c, 1U c, W c, 1C c, W c, 2S c, 33 c, W c,
2S c, 39 c, 34 c, W c, 2X c, W c, 2R c, 2W c, 2P c, 36 c, 37 c, W c, 17 c, W
c, 2R c, 1S c, W c, 1A c, W c, 1A c, Y c, W c, 2R c, 18 c, W c, Y c, W c, 30
c, 33 c, 33 c, 34 c, W c, 2S c, W c, 1E c, 1U c, W c, 38 c, 3D c, 34 c, 2T
c, W c, 1N c, W c, 35 c, : q ." 36 base ! create d " d 2B 0 do dup i chars +
c@ . ." c, " loop d 2B type ; q
Anton Ertl
>Here we go. This should be sufficient overkill to satisfy anbody's need for
>complexity.
Ok, here's a shorter version of that:
: s s\" : quine .\\\" : s s\\\\\\\" \" 0 xpos ! s c-\\type .\\\" \\\" ;\\n\" s type ;" ;
: quine .\" : s s\\\" " 0 xpos ! s c-\type .\" \" ;\n" s type ;
It is Gforth-specific because of c-\type and xpos, but I don't think
that including the definition of c-\type makes it any more
interesting, and certainly not clearer. Anyway, here's its
definition:
: c-\type ( c-addr u -- )
\ type string in \-escaped form
begin
dup while
2dup newline string-prefix? if
'\ cemit 'n cemit
newline nip /string
else
over c@
dup '" = over '\ = or if
'\ cemit cemit
else
dup bl 127 within if
cemit
else
base @ >r try
8 base ! 0 <<# # # # '\ hold #> ctype #>> 0
recover
endtry
r> base ! throw
endif
endif
1 /string
endif
repeat
2drop ;
If you use EMIT and TYPE instead of CEMIT and CTYPE, there is no need
for clearing xpos.
Neal Bridges
news:2006Sep3...@mips.complang.tuwien.ac.at...
> >Here we go. This should be sufficient overkill to satisfy anbody's need
for
> >complexity.
>
> Ok, here's a shorter version of that:
>
> : s s\" : quine .\\\" : s s\\\\\\\" \" 0 xpos ! s c-\\type .\\\" \\\"
;\\n\" s type ;" ;
> : quine .\" : s s\\\" " 0 xpos ! s c-\type .\" \" ;\n" s type ;
>
> It is Gforth-specific because of c-\type and xpos,
Isn't it Gforth-specific because of s\" as well?
John Doty
> John Doty wrote:
>> Quining in LSE
>>
>> I realized a self-printing program is really easy in LSE64:
>>
>> " 34 put sp dup ,t 34 put sp ,t" 34 put sp dup ,t 34 put sp ,t
>>
>> The main trick is using "34 put" to print a quote mark, thereby
>> trivially avoiding the problem of quoting a literal quote mark (for
>> which LSE has no mechanism anyway). A Gödelian trick, to my thinking.
>
> Good. You captured the essence of what a quine is about. It doesn't
> (or shouldn't) take much imagination to translate this to Forth.
Huh? It *is* Forth, just not the backward, kludgy, obfuscated "standard"
dialect.
Joe Knapka
It is exactly the same in principle; the means of quotation is
different, that's all. We must "quote" the source by enclosing it
within a colon-def, instead of just a string quotation. We must
also, of course, invoke the defined word.
: quine s" 2dup 32 34 115 32 101 110 105 117 113 32 58 11 0 do emit loop
type 34 emit 32 emit type 32 101 110 105 117 113 32 59 32 9 0 do emit
loop" 2dup 32 34 115 32 101 110 105 117 113 32 58 11 0 do emit loop type
34 emit 32 emit type 32 101 110 105 117 113 32 59 32 9 0 do emit loop ;
quine
(All one line.) Of course, all the quines you've been offered, including
this one, are still only quines when executed in an appropriate context.
-- JK
Anton Ertl
>Isn't it Gforth-specific because of s\" as well?
Well, S\" is relatively common (IIRC at least Gforth, PFE, VFX,
SwiftForth). However, the use with \" is not as widely supported as
\q.
John Doty
> John Passaniti <my-first-...@JapanIsShinto.com> writes:
>> Marcel Hendrix wrote:
>>> Honestly, you have been changing the goalposts each time somebody met your
>>> challenge.
>
> That's good. It results in a number of quines that highlight various
> features of Forth. I have collected them at
> <http://www.complang.tuwien.ac.at/forth/quines.html>.
>
>> It was my assumption that when people looked at quines in other
>> languages, they would recognize that decompilation and recording input
>> text would be trivial and uninteresting, at least compared to the class
>> of solutions offered by others.
>
> People using other languages have used more complex (or, if you like,
> more interesting) solutions because their languages did not offer the
> features Forth has. So, basically, it seems to me that what you are
> asking of us is to restrict ourselves to features in Forth that
> Algol-family languages have.
>
> Similarly, solutions in other languages become longer, and therefore
> maybe more interesting if you disallow some of the features of the
> language. E.g., the C solutions generally use printf. How about
> disallowing that? They also use strings. How about disallowing that?
The actual intellectual content of the puzzle is that if you disallow
enough things to prevent a solution, you've crippled the language.
Direct reflection by tricks like access to the input buffer is not
required. But once you understand *indirect* reflection through quoting
and encoding, solution of the puzzle in any non-crippled language is
straightforward (although perhaps tedious). That's why direct reflection
is cheating: it's indirect reflection that's profound.
Of course, I found it nice that indirect reflection proved so easy in
LSE64: simplicity has its rewards.
John Passaniti
> Given your complaints about others not reading the pages you refer to,
> one would think that you would at least read them yourself, but that's
> apparently not the case.
Or in this case, read more carefully, since the only thing I read while
skimming the page was the decompiler-based quine at the bottom.
So "source type" is there. Congratulations. So Forth is represented
there by two methods-- one that asks if the method is cheating and the
other that is highly non-portable.
John Passaniti
> Here we go. This should be sufficient overkill to satisfy anbody's need for
> complexity.
But complexity is not the goal. Indeed, part of what's fun about quines
is coming up with the smallest solution.
Anton Ertl
>Direct reflection by tricks like access to the input buffer is not
>required. But once you understand *indirect* reflection through quoting
>and encoding, solution of the puzzle in any non-crippled language is
>straightforward (although perhaps tedious).
Good for languages that have hamstrung themselves by not providing
reflection.
>That's why direct reflection
>is cheating: it's indirect reflection that's profound.
Looking at it from the Quine's paradox viewpoint, it may seem
profound; after all, philosophers believed that one could prevent the
liar paradox by forbidding self-reference, and Quine's paradox proved
them wrong.
OTOH: "A quine exists in any programming language with the ability to
output any computable string, as a direct consequence of Kleene's
recursion theorem". Given this, the existence of quines in
reflection-less languages seems much less profound.
Anyway, I find the idea funny that non-profound solutions are cheats.
Do you also apply this in other areas of life?
Anton Ertl
>Nice. So the following might satisfy Mr Passaniti's request :-)
>
>s" 2dup cr 115 emit 34 emit space type 34 emit space type cr" 2dup cr
>115 emit 34 emit space type 34 emit space type cr
Ok, I'm getting the hang of this. The following should satisfy his
later request for a word that prints the source program:
s" 2constant s : quine 115 emit 34 emit space [ s ] sliteral 2dup type 34 emit space type ;" 2constant s : quine 115 emit 34 emit space [ s ] sliteral 2dup type 34 emit space type ;
Now, this still uses the interpreter for the string. To do it all in
colon definitions:
: s s" ; : quine [ char ' parse : s s' ] sliteral type 34 emit space s type 34 emit s type ;"; : quine [ char ' parse : s s' ] sliteral type 34 emit space s type 34 emit s type ;
Still uses the interpreter inside the colon definitions, so let's
eliminate that:
: s s" ; : quine 58 emit space 115 emit space 115 emit 34 emit space s type 34 emit s type ;"; : quine 58 emit space 115 emit space 115 emit 34 emit space s type 34 emit s type ;
Bernd Paysan
> Here's a shorter and far more obfuscated version of the clumsy way of
> doing it in Forth.
I've an even shorter one, which is not so clumsy, but meets the stupid
requirements (everything in one line as usual):
: quiche s" : quiche % 2dup bounds ?DO I c@ 37 = IF 's emit 34 emit space
type 34 emit ELSE I c@ emit THEN LOOP ; quiche" 2dup bounds ?DO I c@ 37 =
IF 's emit 34 emit space type 34 emit ELSE I c@ emit THEN LOOP ; quiche
The idea behind this program is a bit different - let's rewrite TYPE so that
it can be used for self-expanding quotation.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
John Passaniti
> People using other languages have used more complex (or, if you like,
> more interesting) solutions because their languages did not offer the
> features Forth has. So, basically, it seems to me that what you are
> asking of us is to restrict ourselves to features in Forth that
> Algol-family languages have.
I'm not sure where Algol-family languages come into this, but no, that's
not how I view this. Let's take the two features of Forth used so far:
: ME S" SEE ME" EVALUATE ;
This to me fails because not all Forths have a decompiler. And of those
that do, not all decompilers generate exactly the same output as the
source (for example, the pForth example I provided). So at best,
decompiler-based quines are highly specific to a particular Forth
implementation. So they are, to me at least, uninteresting. Does it
work? Sometimes.
So let's move now to the other Forth feature, access to the input buffer:
source type
Now we start getting into a gray area. The challenge of a quine is to
write a *program* that echos its own source. This to me isn't
programming. It doesn't result in any code being generated and it
doesn't even invoke the compiler. Does it work? Yep. Is it in any
sense interesting?
So Neal came up with a solution:
: quine [ source ] sliteral type ; quine
Okay, now we're actually invoking the compiler and generating code. We
have a real named program, not just statements issued to a command
interpreter. The "quine" on the end isn't necessary (quines don't have
to execute themselves) so we could remove that and save six characters.
I guess in a weak sense this is interesting because it shows that
application code has *some* access to its own source. I say "some"
because this is not a general feature that words can exploit:
: this-fails
some-source-we-care-about
[ source ] sliteral
do-something-interesting-with-source
;
The string literal compiled here is limited to the line it is compiled
on. So we don't have a general facility here in Forth that allows words
to read their own code. If we did, then yes, all this would be
interesting because it would show Forth words have reflexivity back to
source. But here, all we're demonstrating is that Forth code can access
a limited window of it's own source. It's sufficient for creating
quines, but not a general facility that programmers can exploit. So, I
consider that uninteresting. Useful? Maybe in some limited context.
It wouldn't be hard to add an outer loop that collected up program
source text and buffered it, allowing words to access their own source
code. But that's just a trivial variation on the typical read/eval loop
of most interactive programming languages.
> Similarly, solutions in other languages become longer, and therefore
> maybe more interesting if you disallow some of the features of the
> language. E.g., the C solutions generally use printf. How about
> disallowing that? They also use strings. How about disallowing that?
It isn't the length of a quine that makes it interesting or not.
I understand your point, but don't agree. I'm not asking you to
restrict yourself to features in Algol-family (or any other family) of
languages. If anything, I'm asking for a restriction to *interesting*
code. That's completely subjective, but I don't find limited access to
the input buffer particularly compelling. It's not even unique, since
it can be trivially emulated in *any* interpreted language that allows
evaluating strings at run-time.
Yep, this sort of thing allows a simple quine. But just like a compiler
that's tuned to generate superior code for a specific benchmark isn't
interesting in the general sense, neither is this.
Others will disagree. That's fine. But what most programmers will
agree on is that when you see a truly clever and elegant solution to a
problem, you just *know* it's right. There is a feeling of satisfaction
that comes from such solutions. To me, the variations on "source type"
leave me cold and looking for something more substantial.
Bernd Paysan
> The idea behind this program is a bit different - let's rewrite TYPE so
> that it can be used for self-expanding quotation.
For this single purpose, you can just know the position where to insert the
string, and then it becomes even smaller:
: quine s" : quine over 8 type 115 emit 34 emit space 2dup type 34 emit
8 /string type ;" over 8 type 115 emit 34 emit space 2dup type 34 emit
8 /string type ;
Anton Ertl
>: quine s" 2dup 32 34 115 32 101 110 105 117 113 32 58 11 0 do emit loop
>type 34 emit 32 emit type 32 101 110 105 117 113 32 59 32 9 0 do emit
>loop" 2dup 32 34 115 32 101 110 105 117 113 32 58 11 0 do emit loop type
>34 emit 32 emit type 32 101 110 105 117 113 32 59 32 9 0 do emit loop ;
>quine
Ok, I havs simplified that to:
: quine s" 2dup 32 34 115 32 101 110 105 117 113 32 58 11 0 do emit loop type 34 emit type ;"2dup 32 34 115 32 101 110 105 117 113 32 58 11 0 do emit loop type 34 emit type ;
I have left the final call out, because John Passaniti did not ask for
that. And everything at the end can be put directly into the string,
no second emit loop necessary.
Anton Ertl
>Bernd Paysan wrote:
>> The idea behind this program is a bit different - let's rewrite TYPE so
>> that it can be used for self-expanding quotation.
>
>For this single purpose, you can just know the position where to insert the
>string, and then it becomes even smaller:
>
>: quine s" : quine over 8 type 115 emit 34 emit space 2dup type 34 emit
>8 /string type ;" over 8 type 115 emit 34 emit space 2dup type 34 emit
>8 /string type ;
No need to exclude the S from the string:
: quine s" : quine s over 9 type 34 emit space 2dup type 34 emit 9 /string type ;" over 9 type 34 emit space 2dup type 34 emit 9 /string type ;
Joe Knapka
> Joe Knapka wrote:
>
>> Which is exactly what I said: the context in which a quine is
>> executed *need not* be reproduced by the quine, in order for
>> it to count as a quine. I'm glad we agree.
>
>
> Then in that case, the following is a Forth quine:
>
> JoeKnapka
No. It is a quine in a language that defines a word "JoeKnapka"
that returns its name when called. AFIAK ANS Forth is not such a
language (though that would be kewl!). Just to make sure we
understand one another: I am (and have always been) perfectly
aware that
quine something
is NOT a Forth quine; it is only a quine in a language that
defines the word
: quine ." quine " parse-word type ;
I'm reasonably sure I made that clear early on in the thread.
Anyway, I'm done; if you bother to reply to this, you get the
last word.
-- JK
John Passaniti
> Just to make sure we
> understand one another: I am (and have always been) perfectly
> aware that
>
> quine something
>
> is NOT a Forth quine; it is only a quine in a language that
> defines the word
>
> : quine ." quine " parse-word type ;
I am unaware of any language that defines such a word. You can
certainly *add* such a word to a language, but once you've done that,
the (informal) rules of quines demand that code also be emitted.
The objection that started this subthread was the name you had chosen.
The word "quine" has a well-understood and crisp common meaning, and the
code you offered didn't match that meaning. You are of course free to
do that, but you shouldn't be surprised if someone complains.
> I'm reasonably sure I made that clear early on in the thread.
> Anyway, I'm done; if you bother to reply to this, you get the
> last word.
You may have made such a statement early on. It wouldn't have mattered,
since the argument the statement is based on is flawed (you weren't
using a language that had 'quine' defined; you *added* the definition to
the language).
John Doty
> John Doty <j...@whispertel.LoseTheH.net> writes:
>> Direct reflection by tricks like access to the input buffer is not
>> required. But once you understand *indirect* reflection through quoting
>> and encoding, solution of the puzzle in any non-crippled language is
>> straightforward (although perhaps tedious).
>
> Good for languages that have hamstrung themselves by not providing
> reflection.
Hamstrung? In the end, the measure of a programming language is its
applications, and few applications benefit in any critical way from
direct reflection.
>
>> That's why direct reflection
>> is cheating: it's indirect reflection that's profound.
>
> Looking at it from the Quine's paradox viewpoint, it may seem
> profound; after all, philosophers believed that one could prevent the
> liar paradox by forbidding self-reference, and Quine's paradox proved
> them wrong.
>
> OTOH: "A quine exists in any programming language with the ability to
> output any computable string, as a direct consequence of Kleene's
> recursion theorem". Given this, the existence of quines in
> reflection-less languages seems much less profound.
It's easy to cite a theorem. But its related ancestral theorems were
very, very far from obvious before Gödel. I think that makes it
profound. Also, this (like many theorems) is more important for the
methodology that lies behind it, rather than the bald fact it states.
The techniques of quoting and coding used to achieve indirect reflection
are very important in actual computer applications.
>
> Anyway, I find the idea funny that non-profound solutions are cheats.
> Do you also apply this in other areas of life?
Sometimes yes, sometimes no. What's cheating depends on what you are
trying to achieve. Cheating at Solitaire is silly, but if you only need
a sorted deck, Solitaire is a silly way to get there.
Anton Ertl
>Bernd Paysan wrote:
>> The idea behind this program is a bit different - let's rewrite TYPE so
>> that it can be used for self-expanding quotation.
>
>For this single purpose, you can just know the position where to insert the
>string, and then it becomes even smaller:
>
>: quine s" : quine over 8 type 115 emit 34 emit space 2dup type 34 emit
>8 /string type ;" over 8 type 115 emit 34 emit space 2dup type 34 emit
>8 /string type ;
Instead of having one string and picking it apart, one can also have
two strings:
: x 83 emit 34 emit space type 34 emit ; : quine S" : x 83 emit 34 emit space type 34 emit ; : quine "S" 2swap 2dup type x 2dup x type ;"2swap 2dup type x 2dup x type ;
It is a little shorter if we put the strings in reverse order:
: x 83 emit 34 emit space type 34 emit ; : quine S" 2dup type 2over x x type ;"S" : x 83 emit 34 emit space type 34 emit ; : quine "2dup type 2over x x type ;
Anton Ertl
>Anton Ertl wrote:
>> People using other languages have used more complex (or, if you like,
>> more interesting) solutions because their languages did not offer the
>> features Forth has. So, basically, it seems to me that what you are
>> asking of us is to restrict ourselves to features in Forth that
>> Algol-family languages have.
>
>I'm not sure where Algol-family languages come into this,
The restrictions you ask for suggest it. E.g., the Scheme/Lisp
solution given in Wikipedia and
<http://www.nyx.net/~gthompso/quine.htm> also does not satisfy your
criteria.
> : ME S" SEE ME" EVALUATE ;
>
>This to me fails because not all Forths have a decompiler. And of those
>that do, not all decompilers generate exactly the same output as the
>source (for example, the pForth example I provided). So at best,
>decompiler-based quines are highly specific to a particular Forth
>implementation.
Sure. So what? If you are interested in quines, surely a Forth
system is deficient for the purpose if its decompiler does not even
try to decompile into compilable source code.
As for the formatting differences, that's just a minor nit that can be
fixed for any particular system by compiling and then running the
quine once. Also, the Scheme/Lisp solution given by the sources you
pointed to has the same problem.
The Scheme/Lisp solution also has the problem of not working on every
Lisp: I just tried it in Emacs 21.4.1 and the output was:
((lambda (x) (list x (list ... x))) (quote (lambda (x) (list x ...))))
>So let's move now to the other Forth feature, access to the input buffer:
>
> source type
>
>Now we start getting into a gray area. The challenge of a quine is to
>write a *program* that echos its own source. This to me isn't
>programming.
To me it is. And to the ANS Forth standard it is an ANS Forth
program.
>It doesn't result in any code being generated and it
>doesn't even invoke the compiler.
While a FORTRAN or Algol program may need such things, that is not
true of Forth programs. It is also not true of Lisp and Scheme
programs, and indeed, the Scheme/Lisp solution is also instantly
executed, leaving no re-executable residue.
>So Neal came up with a solution:
>
> : quine [ source ] sliteral type ; quine
>
>Okay, now we're actually invoking the compiler and generating code. We
>have a real named program, not just statements issued to a command
>interpreter. The "quine" on the end isn't necessary (quines don't have
>to execute themselves)
It is interesting that most people who rose to your challenge of
writing a colon definition ended their solution with an invocation of
the colon definition, even though you did not ask for that. These
Forth programmers don't seem to share your idea about what a program
is.
>That's fine. But what most programmers will
>agree on is that when you see a truly clever and elegant solution to a
>problem, you just *know* it's right. There is a feeling of satisfaction
>that comes from such solutions. To me, the variations on "source type"
>leave me cold and looking for something more substantial.
To me, SOURCE TYPE is perfect. The problem with the additional
restrictions is a fine puzzle, but the solutions are not very elegant,
and the clever idea is basically the same in all of them.
Anton Ertl
>Anton Ertl wrote:
>> Good for languages that have hamstrung themselves by not providing
>> reflection.
>
>Hamstrung? In the end, the measure of a programming language is its
>applications, and few applications benefit in any critical way from
>direct reflection.
Applications that are programmed in a language that does not offer
reflection certainly don't benefit. However, I have the impression
that reflection is a feature of Java that is used quite a lot.
>The techniques of quoting and coding used to achieve indirect reflection
>are very important in actual computer applications.
Can you elaborate on that? How come that direct reflection is
supposedly unimportant and these techniques are important?
>> Anyway, I find the idea funny that non-profound solutions are cheats.
>> Do you also apply this in other areas of life?
>
>Sometimes yes, sometimes no. What's cheating depends on what you are
>trying to achieve.
Writing a program that produces its complete source code as its only
output.
John Doty
> John Doty <j...@whispertel.LoseTheH.net> writes:
>> Anton Ertl wrote:
>>> Good for languages that have hamstrung themselves by not providing
>>> reflection.
>> Hamstrung? In the end, the measure of a programming language is its
>> applications, and few applications benefit in any critical way from
>> direct reflection.
>
> Applications that are programmed in a language that does not offer
> reflection certainly don't benefit. However, I have the impression
> that reflection is a feature of Java that is used quite a lot.
I see no evidence that Java gains any special ability to implement real
applications from this capability. Programmers love cleverness, but
cleverness rarely is important in getting the job done.
>
>> The techniques of quoting and coding used to achieve indirect reflection
>> are very important in actual computer applications.
>
> Can you elaborate on that? How come that direct reflection is
> supposedly unimportant and these techniques are important?
It's easy to find applications that require quoting and coding. I think
it's a real stretch to claim that *any* application requires direct
reflection in its implementation language.
>
>>> Anyway, I find the idea funny that non-profound solutions are cheats.
>>> Do you also apply this in other areas of life?
>> Sometimes yes, sometimes no. What's cheating depends on what you are
>> trying to achieve.
>
> Writing a program that produces its complete source code as its only
> output.
You know, that's the kind of thing that makes people with jobs to do
want to shoot programmers. If you're trying to get a job done with a
computer, you're already dealing with a mindless automaton. You don't
need another one in between: programmers are more difficult to program
than computers. If you're not willing to attempt to comprehend the point
of a spec, you're useless.
Why do you suppose that a professor would give quining as an assignment?
John Passaniti
>> Applications that are programmed in a language that does not offer
>> reflection certainly don't benefit. However, I have the impression
>> that reflection is a feature of Java that is used quite a lot.
>
> I see no evidence that Java gains any special ability to implement real
> applications from this capability. Programmers love cleverness, but
> cleverness rarely is important in getting the job done.
I think you're way off on this one.
Although I don't use Java, I do use C# in some of my work. And in C#,
I've had a lot of experience with the Java-like reflection capabilities
of the underlying .NET environment. This isn't just a gimmick; it's
used by application programmers all the time.
One interesting thing Microsoft does is to make .NET code available as
COM objects. This is mostly for supporting legacy environments, but
it's an important use of reflection. The runtime environment uses
reflection to dynamically write code to expose .NET classes as COM objects.
Microsoft also uses reflection a lot in the form of attributes being
attached to various kinds of entities in a system. For example, there
is an attribute that when seen by the runtime system causes the JIT
compiler to emit thread synchronization code.
Another very important use of reflection is serialization of objects. I
can (with some restriction) create completely arbitrary networks of
objects and serialize them simply. Reflection iterates over each object
in the network, inspects the underlying data types, and writes it out to
a stream.
I've used reflection in my own applications several times. In one case,
I wrote a Forth-like command interpreter that introspected on the
environment and automatically created a dictionary from methods of
classes. Traditionally, I would have to build up the dictionary with
code like this:
dict.add("+", add);
dict.add(".", dot);
And so on. But using reflection, I can do this dynamically at runtime:
[ForthName("+")]
public void add(void) { push(pop()+pop()) };
Reflection hunts down these methods and makes them available.
I've also used reflection to dynamically extend an application at
run-time. This was an application requirement, modeled after filters in
an image processing application or a plug-in in an environment like
Eclipse. To extend the application, the user only needed to add the
extension to a special directory. At run-time, all files in that
directory are loaded and reflection is used to introspect on the kind of
extension it is and make it available to the rest of the application.
Finally, I've started to play with Aspect Oriented Programming (and yes,
this is driven by an application need), and there reflection allows
dynamically finding and injecting code that is typical in AOP.
I guess my point with all this is that reflection used in the examples I
gave isn't "cleverness." It's all driven by application requirements,
and it can be simpler, more robust, and far less error-prone than other
techniques. If you can't find examples where reflection is a valuable
programming tool, then you simply aren't trying.
Now, having written all that, it is important to note that the kind of
reflection that is being discussed regarding quines is very different.
That is (for lack of a better name) "source reflection." The kind of
reflection I'm talking about is the ability of an application to
introspect on structure. Or basically, it's exposing the symbol table
and other information the compiler generates during compilation and
makes it available to the application.
Forth's native ability to reflect on the source (with code like "[
source ] sliteral") is very limited. It's obviously useful for quines,
and by extending Forth a bit, might be kinda-sorta-maybe useful as a
debugging tool (being able to "see" without decompiling, getting
original source with comments and formatting).
Forth's reflection capabilities are natively limited (or if you prefer,
primitive but extensible) compared to the reflection capabilities in
other languages. Forth is limited to introspecting on words found in
the dictionary, which means that redefined words aren't available-- at
least not directly. And as there are a variety of different threading
models, there is no portable way for an application to reflect on the
structure of words compiled by the compiler.
> It's easy to find applications that require quoting and coding. I think
> it's a real stretch to claim that *any* application requires direct
> reflection in its implementation language.
The only kind of application that I can think of are Forth-like
languages that use direct source interpretation to execute code. I have
a Forth-like language called Tester that works like this (the
application requirement that drove it is something I can discuss if you
care, but I doubt you do). In such languages, what you're calling
"direct reflection" is the primary method to extend the system. New
definitions are stored as source and executed by code resembling the
Forth outer-interpreter.
Bernd Paysan
> Writing a program that produces its complete source code as its only
> output.
Note that the Forth solution to this problem also is extremly readable:
source type
It does express what it's specification states it should do.
John Doty
> Anton Ertl wrote:
>> Writing a program that produces its complete source code as its only
>> output.
>
> Note that the Forth solution to this problem also is extremly readable:
>
> source type
>
> It does express what it's specification states it should do.
>
To a mindless automaton, yes. But a smart professional would question
the spec, find out what's *really* behind it.
Bernd Paysan
> Bernd Paysan wrote:
>> Note that the Forth solution to this problem also is extremly readable:
>>
>> source type
>>
>> It does express what it's specification states it should do.
>>
>
> To a mindless automaton, yes. But a smart professional would question
> the spec, find out what's *really* behind it.
Yes, and what's really behind it means bending the informal requirements so
that the solution does what the customer actually needs.
In the case of a quine, the solution that suits the customer probably best
is the SEE version, since a customer that wants a program to prints it own
source probably actually wants a program to print sources of an already
compiled program, and not a special-case puzzle to be solved.
But in this case it's rather the contrary: The original poster wanted a
specific puzzle to be solved, not a program that prints its own source. The
specific puzzle is to print a string in such a way that the string contains
itself in a quoted way, and as total represents the source of the program.
John Doty
> John Doty wrote:
>>> Applications that are programmed in a language that does not offer
>>> reflection certainly don't benefit. However, I have the impression
>>> that reflection is a feature of Java that is used quite a lot.
>>
>> I see no evidence that Java gains any special ability to implement
>> real applications from this capability. Programmers love cleverness,
>> but cleverness rarely is important in getting the job done.
>
> I think you're way off on this one.
We're closer than you think.
Under what circumstances might this fail? I suspect that question is a
lot harder to answer for your second solution.
>
> I've also used reflection to dynamically extend an application at
> run-time. This was an application requirement, modeled after filters in
> an image processing application or a plug-in in an environment like
> Eclipse. To extend the application, the user only needed to add the
> extension to a special directory. At run-time, all files in that
> directory are loaded and reflection is used to introspect on the kind of
> extension it is and make it available to the rest of the application.
>
> Finally, I've started to play with Aspect Oriented Programming (and yes,
> this is driven by an application need), and there reflection allows
> dynamically finding and injecting code that is typical in AOP.
>
> I guess my point with all this is that reflection used in the examples I
> gave isn't "cleverness." It's all driven by application requirements,
> and it can be simpler, more robust, and far less error-prone than other
> techniques.
Well, pardon my skepticism, but I've seen many cases where programmers
(and other kinds of engineers) have gotten hung up on things they
thought were requirements, when they were not requirements at all (like
demanding a POSIX RTOS in an embedded system where the application was a
nearly perfect mismatch to the nature of POSIX services). I've also
heard people try to sell really bad programming with the kinds of claims
you make. PL/I could be *proven* to yield more efficient, more robust,
less buggy software in less time. Yeah, right.
I've seen straight C programmers achieve the kinds of things you are
talking about by putting together programs that parse C code or examine
object files to extract information that was used to generate more C
code. Nobody would claim C has reflection built in, but any non-crippled
language can do this kind of thing. I've even seen FORTRAN programs
that analyzed FORTRAN programs.
> If you can't find examples where reflection is a valuable
> programming tool, then you simply aren't trying.
It's useful on the fringes. Long ago I had a job maintaining and
extending Bob Frankston's BASIC interpreter for ECD Corp (physics wasn't
paying the bills that year). Well, it was called BASIC, but the VM
underneath it was more like Lisp. I wrote my debugger for the ECD BASIC
interpreter in ECD BASIC, and as long as I didn't break the interpreter
too badly when I made a change (I don't recall I ever did), it was
rather handy to debug the system through reflection.
But situations like this are rare, and this kind of cleverness can make
for incomprehensible code. Straightforward is almost always better.
>
> Now, having written all that, it is important to note that the kind of
> reflection that is being discussed regarding quines is very different.
> That is (for lack of a better name) "source reflection."
Yes. I called it "direct" reflection.
> The kind of
> reflection I'm talking about is the ability of an application to
> introspect on structure. Or basically, it's exposing the symbol table
> and other information the compiler generates during compilation and
> makes it available to the application.
Yes, but that doesn't actually have to be built into the language.
>
> Forth's native ability to reflect on the source (with code like "[
> source ] sliteral") is very limited. It's obviously useful for quines,
> and by extending Forth a bit, might be kinda-sorta-maybe useful as a
> debugging tool (being able to "see" without decompiling, getting
> original source with comments and formatting).
>
> Forth's reflection capabilities are natively limited (or if you prefer,
> primitive but extensible) compared to the reflection capabilities in
> other languages. Forth is limited to introspecting on words found in
> the dictionary, which means that redefined words aren't available-- at
> least not directly. And as there are a variety of different threading
> models, there is no portable way for an application to reflect on the
> structure of words compiled by the compiler.
ANS Forth has the difficulty that its built in reflection facilities are
very irregular and ad hoc. Compare to the clean regularity of Python,
for example.
>
>> It's easy to find applications that require quoting and coding. I
>> think it's a real stretch to claim that *any* application requires
>> direct reflection in its implementation language.
>
> The only kind of application that I can think of are Forth-like
> languages that use direct source interpretation to execute code. I have
> a Forth-like language called Tester that works like this (the
> application requirement that drove it is something I can discuss if you
> care, but I doubt you do). In such languages, what you're calling
> "direct reflection" is the primary method to extend the system. New
> definitions are stored as source and executed by code resembling the
> Forth outer-interpreter.
Again, that might be a bit useful in some cases, but reflection built
into the language itself a hard requirement? I'm skeptical.
Anton Ertl
>Anton Ertl wrote:
>> However, I have the impression
>> that reflection is a feature of Java that is used quite a lot.
>
>I see no evidence that Java gains any special ability to implement real
>applications from this capability.
I asked some Java people, and they told me that most big applications
use reflection. They mentioned a number of uses, which I did not all
remember; one that I do remember is that it is used for implementing
plug-ins.
There are also useful applications of reflection in other languages.
E.g., Exceptions in Oberon-2 [hmp97], and various cool infrastructural
things in the .NET environment, e.g., Aspect-Oriented Programming.
Forth and its de-facto-standard indirect-threaded code model were
great for reflection. We dropped that model to gain other advantages,
but did not introduce words to support reflective features to make up
for the loss of the model. In the meantime, languages and
environments became mainstream that have such features. I think,
though, that Forth can still gain the upper hand here, because it's
simpler structure should result in a simpler reflection interface.
@INPROCEEDINGS{hmp97,
author = "Markus Hof, Hanspeter Moessenboeck, Peter Pirkelbauer",
title = "Zero-Overhead Exception Handling Using Metaprogramming",
booktitle = SOFSEM'97",
year = 1997,
booktitle= "LNCS????, Springer",
month = "nov",
address = "Milovy, Czech Republic",
url = "ftp://ftp.ssw.uni-linz.ac.at/pub/Papers/Exceptions.ps.Z",
abstract =
"We present a novel approach to exception handling which is based on
metaprogramming. Our mechanism does not require language support, imposes
no run time overhead to error-free programs, and is easy to implement.
Exception handlers are implemented as ordinary procedures. When an
exception occurs, the corresponding handler is searched dynamically using
the type of the exception as a search criterion. Our implementation was
done in the Oberon System but it could be ported to most other systems
that support metaprogramming.",
Andrew Haley
> John Doty <j...@whispertel.LoseTheH.net> writes:
>>Anton Ertl wrote:
>>> However, I have the impression
>>> that reflection is a feature of Java that is used quite a lot.
>>
>>I see no evidence that Java gains any special ability to implement real
>>applications from this capability.
> I asked some Java people, and they told me that most big applications
> use reflection. They mentioned a number of uses, which I did not all
> remember; one that I do remember is that it is used for implementing
> plug-ins.
> There are also useful applications of reflection in other languages.
> E.g., Exceptions in Oberon-2 [hmp97], and various cool infrastructural
> things in the .NET environment, e.g., Aspect-Oriented Programming.
> Forth and its de-facto-standard indirect-threaded code model were
> great for reflection. We dropped that model to gain other
> advantages, but did not introduce words to support reflective
> features to make up for the loss of the model.
Yes. All of this is true.
> In the meantime, languages and environments became mainstream that
> have such features. I think, though, that Forth can still gain the
> upper hand here, because it's simpler structure should result in a
> simpler reflection interface.
> @INPROCEEDINGS{hmp97,
> author = "Markus Hof, Hanspeter Moessenboeck, Peter Pirkelbauer",
> title = "Zero-Overhead Exception Handling Using Metaprogramming",
> booktitle = SOFSEM'97",
> year = 1997,
> booktitle= "LNCS????, Springer",
> month = "nov",
> address = "Milovy, Czech Republic",
> url = "ftp://ftp.ssw.uni-linz.ac.at/pub/Papers/Exceptions.ps.Z",
> abstract =
> "We present a novel approach to exception handling which is based on
> metaprogramming. Our mechanism does not require language support,
> imposes no run time overhead to error-free programs, and is easy to
> implement. Exception handlers are implemented as ordinary
> procedures. When an exception occurs, the corresponding handler is
> searched dynamically using the type of the exception as a search
> criterion. Our implementation was done in the Oberon System but it
> could be ported to most other systems that support
> metaprogramming.", }
That's a nice idea, but I would expect any implementation to have the
same features as gcc's current exception handling scheme -- very fast
if no exceptions are thrown, very slow if they are.
Andrew.
John Doty
> John Doty <j...@whispertel.LoseTheH.net> writes:
>> Anton Ertl wrote:
>>> However, I have the impression
>>> that reflection is a feature of Java that is used quite a lot.
>> I see no evidence that Java gains any special ability to implement real
>> applications from this capability.
>
> I asked some Java people, and they told me that most big applications
> use reflection. They mentioned a number of uses, which I did not all
> remember; one that I do remember is that it is used for implementing
> plug-ins.
Most big applications in C use automatic type conversion, yet C gains no
special ability to implement real applications from this capability. It
is merely a convenience (and occasionally a problem). Use by coders does
not mean that a feature is important or even a good idea.
>
> There are also useful applications of reflection in other languages.
> E.g., Exceptions in Oberon-2 [hmp97], and various cool infrastructural
> things in the .NET environment, e.g., Aspect-Oriented Programming.
You aren't using the word "application" in the sense I am. How do these
things help you get real-world things (not mere coding tricks) done?
--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.
Stephen J. Bevan
> Anton Ertl wrote:
>> John Doty <j...@whispertel.LoseTheH.net> writes:
>>> Anton Ertl wrote:
>>>> However, I have the impression
>>>> that reflection is a feature of Java that is used quite a lot.
>>> I see no evidence that Java gains any special ability to implement
>>> real applications from this capability.
>> I asked some Java people, and they told me that most big applications
>> use reflection. They mentioned a number of uses, which I did not all
>> remember; one that I do remember is that it is used for implementing
>> plug-ins.
>
> Most big applications in C use automatic type conversion, yet C gains
> no special ability to implement real applications from this
> capability. It is merely a convenience (and occasionally a
> problem). Use by coders does not mean that a feature is important or
> even a good idea.
Reflection is used in large various Java frameworks. For example look
at the source of JBoss or Spring. Those are applications that are
used to get real-world things done, though perhaps real-world things
that you don't care about. Whether reflection is merely a convenience
rather than being important is a debate you can have with the JBoss
and Spring people.
John Doty
> John Doty <j...@whispertel.LoseTheH.net> writes:
>> Anton Ertl wrote:
>>> John Doty <j...@whispertel.LoseTheH.net> writes:
>>>> Anton Ertl wrote:
>>>>> However, I have the impression
>>>>> that reflection is a feature of Java that is used quite a lot.
>>>> I see no evidence that Java gains any special ability to implement
>>>> real applications from this capability.
>>> I asked some Java people, and they told me that most big applications
>>> use reflection. They mentioned a number of uses, which I did not all
>>> remember; one that I do remember is that it is used for implementing
>>> plug-ins.
>> Most big applications in C use automatic type conversion, yet C gains
>> no special ability to implement real applications from this
>> capability. It is merely a convenience (and occasionally a
>> problem). Use by coders does not mean that a feature is important or
>> even a good idea.
>
> Reflection is used in large various Java frameworks. For example look
> at the source of JBoss or Spring. Those are applications that are
> used to get real-world things done, though perhaps real-world things
> that you don't care about.
So what? "Use by coders does not mean that a feature is important or
even a good idea".
> Whether reflection is merely a convenience
> rather than being important is a debate you can have with the JBoss
> and Spring people.
So why bring it up here? If you had an actual use of reflection that was
critical to a real application, that would be interesting. But merely
reporting on the habits of coders (good or bad, who knows?) is of no
interest to this discussion.
John Passaniti
> Most big applications in C use automatic type conversion, yet C gains no
> special ability to implement real applications from this capability. It
> is merely a convenience (and occasionally a problem). Use by coders does
> not mean that a feature is important or even a good idea.
I really wish I understood what your objection/concern is regarding
reflection. You seem to think it leads to "clever" code, yet in my
personal experience in the languages where I've used it, it has led to
clearer designs and overall simpler architectures. And even though I've
mentioned that environments like .NET don't just use reflection but
depend on it, you seem to think it isn't a good idea.
Is your objection/concern that the effect of reflection can be
accomplished by other means? If so, that argument doesn't impress me,
since pretty much *any* facility provided by a language or environment
could be provided by other means. The test isn't if someone can
construct something functionally equivalent. The test is if that
functional equivalent is by some objective measure *better*.
I can implement all the features of Forth by direct interpretation of
strings. That doesn't mean it is better. I can implement numbers in
Lisp purely symbolically. That doesn't mean it is better. I can
implement objects in C by using structures and naming conventions. That
doesn't mean it is better.
If functional equivalence isn't the basis of your objection/concern,
then maybe your argument is anecdotal. Perhaps you've seen some abuse
or loss of code clarity caused by a misuse of reflection. If so, are
you seriously suggesting that because a facility can be abused or
misused, that it shouldn't be provided?
Nah, I doubt you'd go for that kind of argument. Maybe your
objection/concern is centered on the perceived complexity of such a
facility. The only problem with that would be that those languages that
offer reflection, the typical implementation is little more than just
capturing the symbol table the compiler or interpreter created or
maintains in order to work. All reflection amounts to in most languages
is exposing the internal structure of the executing code through a
programmatic interface.
So I guess I'm at a loss to figure out what your objection/concern is.
I can't find a rational basis for it, so I guess we're moving more into
a subjective realm, which is neither interesting or useful.
But hey, show me wrong. Tell us what is wrong with reflection without
resorting to functional equivalence arguments, anecdotal discussion of
abuse/misuse, or perceptions of complexity.
Incidentally:
> You aren't using the word "application" in the sense I am. How do these
> things help you get real-world things (not mere coding tricks) done?
I'll be happy to illustrate my prior points about how reflection enabled
applications with actual code to illustrate. You are free to do the
same, which would likely add weight to your argument instead of
arm-waving generalizations that can't be proved or disproved.
Stephen J. Bevan
> I've seen straight C programmers achieve the kinds of things you are
> talking about by putting together programs that parse C code or
> examine object files to extract information that was used to generate
> more C code. Nobody would claim C has reflection built in, but any
> non-crippled language can do this kind of thing.
Sure, if the language is Turing complete. Thus the question isn't
"can a language do X" it is "how much effort it is to do X" where
"effort" can be time/space/LOC. C parsing C or FORTRAN parsing
FORTRAN requires a lot more effort than using reflection, even in Java
which has a quite verbose reflection system compared to say Lisp or
Smalltalk. Ruby on the Rails framework makes a lot of use of
reflection and while one can be skeptical about its use in ones own
domain, try and re-formulate various Ruby on the Rails examples in a
language of your choice (presumably without reflection) and compare
the effort involved.
J Thomas
John Passaniti wrote:
> Nah, I doubt you'd go for that kind of argument. Maybe your
> objection/concern is centered on the perceived complexity of such a
> facility.
I think he's asking how it's actually helpful.
> The only problem with that would be that those languages that
> offer reflection, the typical implementation is little more than just
> capturing the symbol table the compiler or interpreter created or
> maintains in order to work.
You mean, it's the equivalent of having a Forth dictionary? That's
certainly useful in Forth.
> But hey, show me wrong. Tell us what is wrong with reflection without
> resorting to functional equivalence arguments, anecdotal discussion of
> abuse/misuse, or perceptions of complexity.
I think he's offering a challenge to anybody to show how it's actually
useful.
> > You aren't using the word "application" in the sense I am. How do these
> > things help you get real-world things (not mere coding tricks) done?
>
> I'll be happy to illustrate my prior points about how reflection enabled
> applications with actual code to illustrate. You are free to do the
> same, which would likely add weight to your argument instead of
> arm-waving generalizations that can't be proved or disproved.
Examples of actual code that are easier to do with reflection looks to
me like just what he's asking for. Proving that it can't be useful
would be one of those theoretical exercises where he'd demonstrate that
for anything reflection is used for, there must be a better way. That
sounds hard. Providing an example where it's actually better might be
easy. On the other hand, it could turn out like the Forth claim that
Forth tends not to do so well on small benchmarks but does much better
in large applications. If reflection tends to be useful mostly in large
things, it might be hard to come up with a simple example that shows
it, even if it's true. So if you fail to come up with an example that's
convincing in a small usenet post, that doesn't mean you're wrong.
John Passaniti
> I think he's asking how it's actually helpful.
I already covered that in a past message with examples that I've
personally worked on. He just dismissed it (without saying *why*) as
"clever" but didn't address the fact that it was actually helpful. And
I pointed out that there are environments (like .NET) where reflection
isn't just helpful, it's fundamental to the way the entire system is put
together.
Repeating one of my earlier examples, I pointed to my use of attributes
in .NET in order to reduce the amount of effort and error of creating a
Forth-like system. I gave this example:
[ForthName("+")]
public void add(void) { push(pop()+pop()) };
Using reflection, I build my Forth-like dictionary automatically by
scanning members that have a particular signature (public methods that
return and accept void). But since C# doesn't allow arbitrary names for
members (the name "+" would cause a syntax error), I also use reflection
to provide an alternate name (using the ForthName attribute).
How this is actually helpful is that the dictionary is constructed
automatically. I can't accidentally forget to add words to the
dictionary since reflection hunts them down and installs them for me.
And I don't have to come up with some mapping table to allow names like
"+" to map to the "add" method. It's actually helpful because it saves
time, saves effort, and eliminates an entire class of errors-- all for
about 20 lines of code.
When you have an environment that support reflection, it's a no-brainer
to use the tools the environment provides you to do useful things.
>> The only problem with that would be that those languages that
>> offer reflection, the typical implementation is little more than just
>> capturing the symbol table the compiler or interpreter created or
>> maintains in order to work.
>
> You mean, it's the equivalent of having a Forth dictionary? That's
> certainly useful in Forth.
The built-in tools Forth has to do reflection are primitive and there is
no standard for using them. For example, you can easily do this:
' bingo
But you can't (in a portable way) take the resulting value on the stack
and answer the question of what "bingo" is. Is it a variable? Is it
code? If it is code, is it a primitive or a colon definition? If it's
a colon definition, can you programmatically decompile the code and
discover what words compose it?
For any given Forth, you can probably do any of this. Certainly words
like SEE use internal knowledge about how words are constructed to allow
decompiling them, and that is certainly a form of reflection. The issue
is that there isn't any standard that one could use to do this portably,
and thus, it isn't a technique used much by Forth programmers because it
is necessarily limited to the design of each particular Forth.
But yes, Forth's dictionary provides the primitive basics needed for the
kind of reflection I'm talking about. And one could build up from that
and do the kinds of things that are natural in other languages and
environments.
> I think he's offering a challenge to anybody to show how it's actually
> useful.
He offered the challenge before. It was met. He chose to dismiss the
examples without justification.
> Examples of actual code that are easier to do with reflection looks to
> me like just what he's asking for.
Such was provided, and again in this message.
> Proving that it can't be useful
> would be one of those theoretical exercises where he'd demonstrate that
> for anything reflection is used for, there must be a better way. That
> sounds hard. Providing an example where it's actually better might be
> easy. On the other hand, it could turn out like the Forth claim that
> Forth tends not to do so well on small benchmarks but does much better
> in large applications. If reflection tends to be useful mostly in large
> things, it might be hard to come up with a simple example that shows
> it, even if it's true. So if you fail to come up with an example that's
> convincing in a small usenet post, that doesn't mean you're wrong.
John is dismissing reflection as "clever" which he uses in a pejorative
sense. He isn't qualifying his statements by saying reflection is only
bad or clever or whatever for small applications but is fine for larger
ones. In fact, I don't see where he has qualified his statements at all.
It's much the same problem I have when you see people here talk about
other techniques and paradigms. Take object orientation for example.
There are a handful of folks here who trot out the same canonical
examples ("a ball doesn't throw itself!") as being somehow useful for
discussion or debate.
To me, it's very simple. There is a universe of languages, techniques,
paradigms, methodologies, and other ways to structure the way one tries
to solve a problem. There is no singular model that works for all
problems. There is no silver bullet anywhere. Forth itself is subject
to this-- there are applications where Forth is objectively the best
possible choice, and there are applications where Forth is dreadfully
awful and makes little to no sense.
It should be assumed that intelligent people will pick and choose what
makes sense. If reflection makes sense, use it. If object orientation
makes sense, use it. And when something doesn't make sense, move on to
something else. Those who argue against something without qualification
or limit or context provide little value to discussion and debate.
Stephen J. Bevan
> Stephen J. Bevan wrote:
>> Reflection is used in large various Java frameworks. For example
>> look at the source of JBoss or Spring. Those are applications that are
>> used to get real-world things done, though perhaps real-world things
>> that you don't care about.
>
> So what? "Use by coders does not mean that a feature is important or
> even a good idea".
>
>> Whether reflection is merely a convenience
>> rather than being important is a debate you can have with the JBoss
>> and Spring people.
>
> So why bring it up here? If you had an actual use of reflection that
> was critical to a real application, that would be interesting. But
> merely reporting on the habits of coders (good or bad, who knows?) is
> of no interest to this discussion.
The discussion will go nowhere without concrete examples of reflection
being used. I gave you two large, real-world, Java applications that
use it, precisely in context for a thread about Java applications that
use reflection. Whether I think their use of reflection is good or
bad is immaterial, I mentioned them so *you* could see reflection
being used and make that decision.
Stephen J. Bevan
>> I'll be happy to illustrate my prior points about how reflection enabled
>> applications with actual code to illustrate. You are free to do the
>> same, which would likely add weight to your argument instead of
>> arm-waving generalizations that can't be proved or disproved.
>
> Examples of actual code that are easier to do with reflection looks to
> me like just what he's asking for.
There are many facets to reflection and they are language dependent.
In some languages what passes for reflection may not even be called
that in another. For example, consider the problem that your
application uses MD5 for some reason and say you have more than one
implementation available (portable code, system specific code,
per-platform assembly, ... etc.) and you want to be able to choose
which you use when the application starts up.
In Java the easy way to do this is create an interface that covers the
different implementations, create a class for each of the
implementation and put the name of the class-file in a configuration
file. When the application starts it loads the file, uses the
class-name to load the appropriate class file and then uses reflection
to create an instance of the class and then you can call the method(s).
In C under Unix, you'd use a very similar approach, using dlopen&dlsym
to load the file, find the function(s) and then you can call them. In
C it probably wouldn't be considered reflection, though dlopen&dlsym
do provide a basic form of that.
In Forth, (or Smalltalk, Lisp, ... etc.), you could use a
configuration file and locate the correct word (method, function,
... etc) via REQUIRED and FIND or avoid the whole issue and have your
configuration file be Forth (Smalltalk, Lisp, ... etc.).
Thus in the above example whether reflection is important, or even
recognized as being reflection, depends on the language that you use.
John Doty
> J Thomas wrote:
>> I think he's asking how it's actually helpful.
>
> I already covered that in a past message with examples that I've
> personally worked on. He just dismissed it (without saying *why*) as
> "clever" but didn't address the fact that it was actually helpful. And
> I pointed out that there are environments (like .NET) where reflection
> isn't just helpful, it's fundamental to the way the entire system is put
> together.
.NET is not an application. Nor are applications created using .NET
demonstrably superior to those created without it.
>
> Repeating one of my earlier examples, I pointed to my use of attributes
> in .NET in order to reduce the amount of effort and error of creating a
> Forth-like system. I gave this example:
>
> [ForthName("+")]
> public void add(void) { push(pop()+pop()) };
>
> Using reflection, I build my Forth-like dictionary automatically by
> scanning members that have a particular signature (public methods that
> return and accept void). But since C# doesn't allow arbitrary names for
> members (the name "+" would cause a syntax error), I also use reflection
> to provide an alternate name (using the ForthName attribute).
>
> How this is actually helpful is that the dictionary is constructed
> automatically. I can't accidentally forget to add words to the
> dictionary since reflection hunts them down and installs them for me.
> And I don't have to come up with some mapping table to allow names like
> "+" to map to the "add" method. It's actually helpful because it saves
> time, saves effort, and eliminates an entire class of errors-- all for
> about 20 lines of code.
Yes, and LSE64 has to struggle with lines like:
build_primitive( add, "+" );
It's not much of a struggle, truthfully. Nor is it especially error
prone. So is your trickery worth it? Not to me! To me, being
straightforward is a virtue, being clever isn't (although I have been
known to "sin" here). A reader can easily understand not only what's
intended, but how its implemented, without having to decode any sort of
tricky underlying mechanism.
>
> When you have an environment that support reflection, it's a no-brainer
> to use the tools the environment provides you to do useful things.
>
Until somebody has to review your code. Obfuscation of mechanism will
get you in trouble. Been there: don't use currying in code that your
customer will want to review, even if it's just a design tool, not
deliverable. Straightforward coding would have cost minutes of extra
typing, saved hours of explanation.
>...
>> I think he's offering a challenge to anybody to show how it's actually
>> useful.
>
> He offered the challenge before. It was met. He chose to dismiss the
> examples without justification.
The challenge was not met. "Use by coders does not mean that a feature
is important or even a good idea". All you've shown is use, not value.
>
>> Examples of actual code that are easier to do with reflection looks to
>> me like just what he's asking for.
>
> Such was provided, and again in this message.
>
>> Proving that it can't be useful
>> would be one of those theoretical exercises where he'd demonstrate that
>> for anything reflection is used for, there must be a better way. That
>> sounds hard. Providing an example where it's actually better might be
>> easy. On the other hand, it could turn out like the Forth claim that
>> Forth tends not to do so well on small benchmarks but does much better
>> in large applications. If reflection tends to be useful mostly in large
>> things, it might be hard to come up with a simple example that shows
>> it, even if it's true. So if you fail to come up with an example that's
>> convincing in a small usenet post, that doesn't mean you're wrong.
>
> John is dismissing reflection as "clever" which he uses in a pejorative
> sense. He isn't qualifying his statements by saying reflection is only
> bad or clever or whatever for small applications but is fine for larger
> ones. In fact, I don't see where he has qualified his statements at all.
>
> It's much the same problem I have when you see people here talk about
> other techniques and paradigms. Take object orientation for example.
> There are a handful of folks here who trot out the same canonical
> examples ("a ball doesn't throw itself!") as being somehow useful for
> discussion or debate.
There's a lot of bad OO code out there. Often OO seems just another tool
in the arsenal of obfuscation. So I have some sympathy with the anti-OO
crowd.
On the other hand, I once managed to sneak asynchronous OO into a
project without publicly using either "O" word, so as not to scare the
application people who needed to be writing code. Worked great. A few
recognized what was going on as OO, the rest just wrote code that
worked. A rose by any other name...
>
> To me, it's very simple. There is a universe of languages, techniques,
> paradigms, methodologies, and other ways to structure the way one tries
> to solve a problem. There is no singular model that works for all
> problems. There is no silver bullet anywhere. Forth itself is subject
> to this-- there are applications where Forth is objectively the best
> possible choice, and there are applications where Forth is dreadfully
> awful and makes little to no sense.
There are no universal solutions. But it is important to know where in
the application universe various techniques have value. Unfortunately,
professional coders generally understand the application universe much
less well than they think they do: they're caught up in technique.
>
> It should be assumed that intelligent people will pick and choose what
> makes sense. If reflection makes sense, use it. If object orientation
> makes sense, use it. And when something doesn't make sense, move on to
> something else. Those who argue against something without qualification
> or limit or context provide little value to discussion and debate.
Again, I've never seen it be of significant value, and nobody in this
discussion has shown it to be of significant value. You've come the
closest, but your example seems pretty trivial to me.
John Doty
> configuration file be Forth (Smalltalk, Lisp, ... etc.).
>
> Thus in the above example whether reflection is important, or even
> recognized as being reflection, depends on the language that you use.
This is a good point.
sl...@jedit.org
You're sucking people into an unwinnable argument by moving the
goalposts every time.
You can use even the most ridiculously underpowered language to solve
any problem, as long as it is turing-complete. I'm sure there were
Basic programmers back in the day who did not see the value of proper
structured programming with subroutines, C programmers who thought that
OOP was completely useless and not suitable for any problem domain, and
here in this newsgroup we have Forth programmers who maintain that the
notion of a datatype does not help the programmer at all.
Have you written any non-trivial applications in LSE64?
Slava
John Doty wrote:
> .NET is not an application. Nor are applications created using .NET
> demonstrably superior to those created without it.
...
> The challenge was not met. "Use by coders does not mean that a feature
> is important or even a good idea". All you've shown is use, not value.
...
> There's a lot of bad OO code out there. Often OO seems just another tool
> in the arsenal of obfuscation. So I have some sympathy with the anti-OO
> crowd.
...
John Passaniti
> .NET is not an application. Nor are applications created using .NET
> demonstrably superior to those created without it.
The point of bringing up .NET is that *applications* written for it very
often use reflection because it is an intrinsic system service. I used
in a past example the serialization support, which uses reflection
internally to walk arbitrarily complex data structures and save/restore
them. The advantage is this:
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(someStream, someData);
... and later to restore ...
someData = (SomeDataType) formatter.Deserialize(stream);
Is this demonstrably superior to a specific solution hand-coded for this
case? In my case, yes, very much so. Since the overhead of this
approach was actually measured and found to be insignificant, this
solution to serialization was very much so demonstrably superior by this
very important metric: The cost of this code-- in terms of my time and
thus the amount I charged to the customer-- was *far* less than if I
wasted time hand-coding a specific solution. And indeed, this solution
has been very robust in that it has tracked changes to the data
structure with zero effort on my part.
But let me quote your gem again:
> .NET is not an application. Nor are applications created using .NET
> demonstrably superior to those created without it.
The second half is a meaningless standard. How does one objectively
measure "demonstrably superior" for an environment used to create
applications? I can certainly show that *my* .NET applications are
"demonstrably superior" to my past Windows-coding efforts. That doesn't
mean they always are anymore than you can say that LSE64 is
"demonstrably superior" for all possible applications.
I'm an engineer, not a philosopher. Tell me the objective standards you
want to use for "demonstrably superior" that could possibly satisfy
something so vague, and I'll see what I can do.
> Yes, and LSE64 has to struggle with lines like:
>
> build_primitive( add, "+" );
>
> It's not much of a struggle, truthfully. Nor is it especially error
> prone. So is your trickery worth it? Not to me! To me, being
> straightforward is a virtue, being clever isn't (although I have been
> known to "sin" here). A reader can easily understand not only what's
> intended, but how its implemented, without having to decode any sort of
> tricky underlying mechanism.
It isn't "trickery" to use a supported facility that has defined
interfaces and known behavior. It isn't "clever" to use the tools that
are provided. As for readability, I assume intelligence on the part of
the person who is maintaining my code. I assume they know the language,
and know the environment. I assume they know the facilities (like
reflection) that are fundamental to .NET. You're making a weird COBOL
argument of "the managers can understand the code." I don't find that
compelling.
Your solution, to me, is not "demonstrably superior." In my solution, I
don't have to do *anything* more than write the method and it gets added
to the dictionary. In terms of what my customer cares about, that means
I spend no additional billable time ensuring that my methods and the
dictionary are in sync.
Honestly, I think you're suffering from a kind of software Stockholm
Syndrome. You're using a language (C) that doesn't offer reflection and
so you've convinced yourself that your solution is best. Well, since
it's the only reasonable solution offered by C (unless you went to
parsing external artifacts like debugging information left by the
compiler), that's all you have. The question I would ask is if you
would do the same thing if you used a language or environment that
supported reflection.
You keep using words like "trickery" and "clever" but you don't justify
them. At best, these words reflect on your lack of understanding of the
facility, not some universal truth everyone can see. Your challenge is
to move from the subjective and towards the objective. Don't just tell
me you think reflection is "trickery" and "clever." *Show* it.
>> When you have an environment that support reflection, it's a
>> no-brainer to use the tools the environment provides you to do useful
>> things.
>
> Until somebody has to review your code. Obfuscation of mechanism will
> get you in trouble. Been there: don't use currying in code that your
> customer will want to review, even if it's just a design tool, not
> deliverable. Straightforward coding would have cost minutes of extra
> typing, saved hours of explanation.
The part you keep dancing around is that we aren't talking about some
exotic programming technique. We're talking about languages and
environments where reflection is a supported facility. If you don't
understand the facilities of a language, then you aren't qualified to
review code in that language. Seems pretty simple to me.
So in the interest of consistency, you would probably tell C++
programmers not to use objects because not all programmers understand
them. And you probably tell Lisp programmers to stick to procedural
coding and side effects because not all programmers understand the
functional style. Oh, and let's not use Forth at all because not all
programmers understand how to use the stack correctly.
Please let me know what application domain you work in where keeping all
code to the lowest common denominator so that inexperienced reviewers
don't panic makes sense. Sound to me like an ideal place to work!
Apparently one doesn't need actual fluency with the language where you
work. That probably saves a lot of time in the hiring process.
> The challenge was not met. "Use by coders does not mean that a feature
> is important or even a good idea". All you've shown is use, not value.
I have shown value. I have shown that in my example, no additional
effort is needed to achieve an effect. I have shown that my technique
disallows an entire class of errors that I personally have made. I have
shown that the cost of me adding words to my dictionary is practically
zero, and that the cost to the customer (in terms of billable time) is
thus practically zero.
I have also shown this isn't "trickery" or "clever" because I'm using a
facility the environment provides through defined interfaces with
documented behavior. This isn't an ad-hoc solution that requires diving
into my code. All it requires is fluency in the tool, which is (at
least where I work) assumed.
> On the other hand, I once managed to sneak asynchronous OO into a
> project without publicly using either "O" word, so as not to scare the
> application people who needed to be writing code. Worked great. A few
> recognized what was going on as OO, the rest just wrote code that
> worked. A rose by any other name...
Ah, now I understand the issue here. For whatever reason, your rational
mind has shut down and you are instead choosing to react to
preconceptions and assorted other illusions you harbor regarding
reflection. Maybe it's the name reflection. How about "introspection?"
Does that name cause you less worry? How about we call it "happy fun
time self looky-loo." That makes it more fun.
When I first came across object orientation, I didn't understand it. So
I did what I do whenever I don't understand something-- dive in and
understand the implementation. Things like virtual functions scared me
until I saw how they were typically implemented. By doing that, I
understood the costs and benefits.
Maybe you need to do the same thing.
> There are no universal solutions. But it is important to know where in
> the application universe various techniques have value. Unfortunately,
> professional coders generally understand the application universe much
> less well than they think they do: they're caught up in technique.
Gosh, I think I'll put up my 25+ years of industry experience in
embedded systems for a variety of application domains up to the test
here. You can talk abstractly about "professional coders" all you want.
I would rather talk from my direct experience.
> Again, I've never seen it be of significant value, and nobody in this
> discussion has shown it to be of significant value. You've come the
> closest, but your example seems pretty trivial to me.
I'm sorry that my example isn't more grandiose. I thought we were
discussing if a technique was valuable. Now you've tossed in the
additional qualifier that it has to make John Doty go "wow."
Albert van der Horst
For a real world example see my post-it fix-up assembler.
The disassembler inspects the data of assembler instructions,
to find which instruction fits a memory content.
Then it uses the name of that instruction in the disassembly.
Reflection (this assembler too, not accidentally) is tightly
coupled with self awareness and artificial intelligence.
The ease with which reflection can be done is one of the
reasons Forth is well suited as an ai language.
Groetjes Albert.
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
John Passaniti
> Reflection (this assembler too, not accidentally) is tightly
> coupled with self awareness and artificial intelligence.
You are aware of any software that can legitimately claim to be
self-aware? Let me be more specific-- any software that isn't the
product of bad science fiction movies?
> The ease with which reflection can be done is one of the
> reasons Forth is well suited as an ai language.
That's quite a stretch, but fine if you're looking for a high-hype
marketing-driven statement to rah-rah Forth.
Classic AI (and the vast majority of useful work in AI) is more about
the representation of knowledge and the derivation of facts from it than
it is any kind of introspection of the code that implements the AI engine.
John Doty
> John,
>
> You're sucking people into an unwinnable argument by moving the
> goalposts every time.
I don't think so. The goal is to show value to an application, not use
by coders. I believe I've been quite consistent here.
Stephen B. really nailed it with: "whether reflection is important, or
even recognized as being reflection, depends on the language that you
use". Most computer scientists would not consider C a language with
reflection, but reflective use of C is common. So, do I win or lose?
Both, of course! Reflection isn't critical to have in a language (I
win!) but once you consider that there a quite a few very useful C
programs that process C code itself in one way or another, reflection
looks very useful (I lose!).
Way back in 1970, I wrote a Fortran program to cross reference symbols
in an assembly language. Back in the punched card era, just finding out
where a variable was used in your deck could be a major chore, so this
was very useful. The first deck I used it on was a part of the Fortran
compiler. Reflection in Fortran? By Stephen B.'s reasoning, I think so.
>
> You can use even the most ridiculously underpowered language to solve
> any problem, as long as it is turing-complete. I'm sure there were
> Basic programmers back in the day who did not see the value of proper
> structured programming with subroutines, C programmers who thought that
> OOP was completely useless and not suitable for any problem domain, and
> here in this newsgroup we have Forth programmers who maintain that the
> notion of a datatype does not help the programmer at all.
And on the flip side, programmers are often miserably ideological, using
OO where it doesn't belong, obfuscating code in the name of
"abstraction", etc. "Proper structured programming"? Structured
programming is useful, but once you start thinking of it as "proper"
you've wandered beyond clear thinking into ideology. I've seen
wonderfully readable "spaghetti code" in Fortran: a clear vision of what
the code is for trumps any mere stylistic trick.
>
> Have you written any non-trivial applications in LSE64?
Two instrument control apps for MKI (and they mutated one of them into a
third without my help: *that's* success!). Yesterday on a telecon I got
a deadline from them for a test app for an instrument component under
development.
Testing of the chip design described at
http://space.mit.edu/home/jpd/SPIE-6276-67.pdf required elaborate SPICE
stimulus files: an LSE64 program generated them (thanks to MKI for
letting me continue to use their server). Yesterday I delivered the test
software for the real hardware (largely in LSE64) to Osaka.
All variations on a theme: operate imaging hardware, either real or
simulated. "Non-trivial"? Well, they're pretty simple: the whole point
of LSE64 to me is that it doesn't make mountains out of molehills. But
they're making me money, they're operating cutting-edge hardware, and
they're putting some real power and flexibility into the hands of the
users of that hardware. Returning Forth to its long-forgotten roots (and
its strength).
sl...@jedit.org
Fortran, we really have nothing to talk about. Have fun with your
PDP/11 and punch cards.
Slava
John Doty
> John Doty wrote:
>> .NET is not an application. Nor are applications created using .NET
>> demonstrably superior to those created without it.
>
> The point of bringing up .NET is that *applications* written for it very
> often use reflection because it is an intrinsic system service. I used
> in a past example the serialization support, which uses reflection
> internally to walk arbitrarily complex data structures and save/restore
> them. The advantage is this:
>
> BinaryFormatter formatter = new BinaryFormatter();
> formatter.Serialize(someStream, someData);
>
Good review requires a variety of viewpoints. If you're writing
spectroscopy code, I'd want a spectroscopist to review it. If you're
using some arcane programming method it becomes very difficult to find
people with the qualifications to understand both the code and the
application domain.
> I assume they know the language,
> and know the environment. I assume they know the facilities (like
> reflection) that are fundamental to .NET. You're making a weird COBOL
> argument of "the managers can understand the code." I don't find that
> compelling.
It isn't the managers I'm worried about. It's the experts who aren't
programming specialists.
>
> Your solution, to me, is not "demonstrably superior."
No, it just works. And most people who know something about programming
can read it and immediately understand what it's doing.
> In my solution, I
> don't have to do *anything* more than write the method and it gets added
> to the dictionary. In terms of what my customer cares about, that means
> I spend no additional billable time ensuring that my methods and the
> dictionary are in sync.
I haven't spent significant time there. But when my son implemented DLL
linkage, it helped that the dictionary building mechanism was trivial:
there was nothing extra to learn or explain. Simple and straightforward
saves communication time unless you're a hermit.
>
> Honestly, I think you're suffering from a kind of software Stockholm
> Syndrome. You're using a language (C) that doesn't offer reflection and
> so you've convinced yourself that your solution is best.
Well yes, in the past six months I've written a little C. Also LSE64
(Forth), Scheme, Mathematica, a little Python, and a little Perl. So how
is it that I'm somehow trapped in a world that doesn't allow reflection?
> Well, since
> it's the only reasonable solution offered by C (unless you went to
> parsing external artifacts like debugging information left by the
> compiler), that's all you have.
Parsing external artifacts is useful sometimes, but in simple cases it
isn't worth it. For building a Forth dictionary it's too much.
> The question I would ask is if you
> would do the same thing if you used a language or environment that
> supported reflection.
Yes. Just for clarity of implementation. So that when the neighborhood
mountain lion gets me, somebody can maintain the code.
> The part you keep dancing around is that we aren't talking about some
> exotic programming technique. We're talking about languages and
> environments where reflection is a supported facility. If you don't
> understand the facilities of a language, then you aren't qualified to
> review code in that language. Seems pretty simple to me.
Review often requires other difficult qualifications. If you like to
make code for which it is impossible to find qualified reviewers, use
arcane coding technique. Then, it's likely nobody will have both the
application and software expertise to do a proper review.
>
> So in the interest of consistency, you would probably tell C++
> programmers not to use objects because not all programmers understand
> them.
Actually, I think objects are pretty easy to understand. But many C++
programmers seem not to understand them, perhaps because C++ takes a
simple concept and obfuscates it to the point where it seems like
incomprehensible magic.
> And you probably tell Lisp programmers to stick to procedural
> coding and side effects because not all programmers understand the
> functional style.
I use a GPL electronic design suite, gEDA. And it's very nice, in many
ways nicer than expensive commercial packages. But I'm not alone in
thinking that its use of Scheme as a scripting language is a mistake,
because not many EE's get much exposure to Lisp. I seem to be one of a
small minority of users who actually use the Scheme layer.
> Oh, and let's not use Forth at all because not all
> programmers understand how to use the stack correctly.
Correctly? You mean as laid out in the Forth Gospels? Few LSE users have
had difficulty understanding the stack. They tend to use more variables
and less gymnastics than fanatical Forthers, but straightforward gets
the job done.
>
> Please let me know what application domain you work in where keeping all
> code to the lowest common denominator so that inexperienced reviewers
> don't panic makes sense.
By their standards, *you* are grossly inexperienced. It's all relative
to your point a view, and a cutting edge project must be reviewed from a
variety of points of view.
> Sound to me like an ideal place to work!
> Apparently one doesn't need actual fluency with the language where you
> work. That probably saves a lot of time in the hiring process.
You need a great deal of capability in a number of specialties. For
example, radiation produces charge traps in the silicon detector, and
you need to understand how that corrupts the data, how algorithms that
compensate for this data corruption can fail, and how this might cause
you to misunderstand what's happening around a black hole a gigaparsec
away. And then there's outgassing from the gyro shock mounts
contaminating your system, further affecting the data in ways difficult
to disentagle. And it goes on. Astrophysics, chemistry, materials
science, electronics, software, politics, sociology, all in a big
tangled mess. We try to keep the issues as separate as possible so we
*can* use the expertise of specialists, but specialists seem to delight
in making their work impenetrable to outsiders, making managing the mess
extremely hard.
>
>> The challenge was not met. "Use by coders does not mean that a feature
>> is important or even a good idea". All you've shown is use, not value.
>
> I have shown value. I have shown that in my example, no additional
> effort is needed to achieve an effect. I have shown that my technique
> disallows an entire class of errors that I personally have made. I have
> shown that the cost of me adding words to my dictionary is practically
> zero, and that the cost to the customer (in terms of billable time) is
> thus practically zero.
>
> I have also shown this isn't "trickery" or "clever" because I'm using a
> facility the environment provides through defined interfaces with
> documented behavior. This isn't an ad-hoc solution that requires diving
> into my code. All it requires is fluency in the tool, which is (at
> least where I work) assumed.
There are too many tools these days for the people with application
expertise to master them all. What happens if you fall into the Genesee?
>
>> On the other hand, I once managed to sneak asynchronous OO into a
>> project without publicly using either "O" word, so as not to scare the
>> application people who needed to be writing code. Worked great. A few
>> recognized what was going on as OO, the rest just wrote code that
>> worked. A rose by any other name...
>
> Ah, now I understand the issue here. For whatever reason, your rational
> mind has shut down and you are instead choosing to react to
> preconceptions and assorted other illusions you harbor regarding
> reflection. Maybe it's the name reflection. How about "introspection?"
> Does that name cause you less worry? How about we call it "happy fun
> time self looky-loo." That makes it more fun.
>
> When I first came across object orientation, I didn't understand it. So
> I did what I do whenever I don't understand something-- dive in and
> understand the implementation. Things like virtual functions scared me
> until I saw how they were typically implemented. By doing that, I
> understood the costs and benefits.
>
> Maybe you need to do the same thing.
You completely misunderstand. I have no problem here, but I depend on a
lot of people with less CS experience than I have.
>
>> There are no universal solutions. But it is important to know where in
>> the application universe various techniques have value. Unfortunately,
>> professional coders generally understand the application universe much
>> less well than they think they do: they're caught up in technique.
>
> Gosh, I think I'll put up my 25+ years of industry experience in
> embedded systems for a variety of application domains up to the test
> here.
Don't play that game with me, I worked on my first embedded system in
1971 (data acquisition for MIT's ALCATOR plasma fusion experiment). I
don't know you, but usually this sort of claim is followed by the
braggart falling in a pit of ignorance. Narrow expertise isn't worth
much after a few years: perspective comes from working a lot of
different angles.