deciphering a macro
Uno
#define putc(c, str) ((str)->_Next < (str)->_Wend \
? (*(str)->_Next++ = c) : (putc)(c, str))
So if str._Next is less than str._Wend then
str._Next, iterated once, equals c
else
you have to call the definition of putc.
How did I do with the logic on that?
Thanks for your comment, and cheers,
--
Uno
Eric Sosman
> This is Plauger's macro override for putc:
>
> #define putc(c, str) ((str)->_Next < (str)->_Wend \
> ? (*(str)->_Next++ = c) : (putc)(c, str))
>
> So if str._Next is less than str._Wend then
> str._Next, iterated once, equals c
> else
> you have to call the definition of putc.
>
> How did I do with the logic on that?
Your phrasing suggests that the pointer is incremented before
the character is stored, which it's not. I'd have preferred "store
c where str->_Next points, and increment str->_Next."
--
Eric Sosman
eso...@ieee-dot-org.invalid
Uno
Thx, eric.
if the value where str->_Next points is less than the value where
str->_Wend points then store c where str->_Next points, and increment
str->_Next, otherwise use the function.
Better?
I'm looking for more of this source, but as a macro neophyte, I have no
method for this.
Does this tell you anything?
typedef struct {
unsigned short _Mode;
short _Handle;
unsigned char *_Buf, *_Bend, *_Next;
unsigned char *_Rend, *_Rsave, *_Wend;
unsigned char _Back[2], _Cbuf, _Nback;
char *_Tmpnam;
} FILE;
--
Uno
Vincenzo Mercuri
> if the value where str->_Next points is less than the value where
> str->_Wend points then store c where str->_Next points, and increment
> str->_Next, otherwise use the function.
Here you are dealing with pointers. It means:
if the memory address str->_Next is lower than the memory
address str->_Wend, the comparison '<' refers to pointers
not to values pointed to.
--
Vincenzo Mercuri
Uno
if the memory address str->_Next points is numerically less than the
memory address str->_Wend points to, then store c where str->_Next
points, and increment str->_Next, otherwise use the function.
?
--
Uno
Francois Grieu
typedef struct {
unsigned short _Mode;
short _Handle;
unsigned char *_Buf, *_Bend, *_Next;
unsigned char *_Rend, *_Rsave, *_Wend;
unsigned char _Back[2], _Cbuf, _Nback;
char *_Tmpnam;
} FILE;
#define putc(c, str) ((str)->_Next < (str)->_Wend \
? (*(str)->_Next++ = c) : (putc)(c, str))
> if the memory address str->_Next points is numerically less than the
> memory address str->_Wend points to, then store c where str->_Next
> points, and increment str->_Next, otherwise use the function.
Yes. The macro putc is an alternative to the function putc,
that does not involve a function call, but behaves like a function
(although one can't take its address). It works by caching write into
a memory buffer (presumably _Buf), endind at _Bend, with current
pointer at _Next. If that can't work [e.g. when the buffer is full,
this corresponds to !((str)->_Next < (str)->_Wend) ], the function
putc is called. On many machines, this speeds up putc by several
binary orders of magnitude.
François Grieu
Uno
Is the definition of the _Next in the #define from this struct?
--
Uno
Francois Grieu
Yes. In putc, the second parameter is a pointer to FILE.
Francois Grieu
Eric Sosman
> Eric Sosman wrote:
>> On 6/30/2010 10:24 PM, Uno wrote:
>>> This is Plauger's macro override for putc:
>>>
>>> #define putc(c, str) ((str)->_Next < (str)->_Wend \
>>> ? (*(str)->_Next++ = c) : (putc)(c, str))
>>>
>>> So if str._Next is less than str._Wend then
>>> str._Next, iterated once, equals c
>>> else
>>> you have to call the definition of putc.
>>>
>>> How did I do with the logic on that?
>>
>> Your phrasing suggests that the pointer is incremented before
>> the character is stored, which it's not. I'd have preferred "store
>> c where str->_Next points, and increment str->_Next."
>>
>
> Thx, eric.
>
> if the value where str->_Next points is less than the value where
> str->_Wend points then store c where str->_Next points, and increment
> str->_Next, otherwise use the function.
>
> Better?
It still seems a bit confused, or maybe just a little baroque.
How about "If the value of str->_Next is less than the value of
str->_Wend, store c where str->_Wend points and advance str->_Wend,
otherwise use the function."
> I'm looking for more of this source, but as a macro neophyte, I have no
> method for this.
Do you have the book the source comes from? It's a good book
and does a good job of explaining why the source looks the way it
does, but it presupposes a certain proficiency in C. If you're
just looking at the source without the book's explanations (and
especially if you're the neophyte you say you are), I don't think
you're likely to gain much understanding. Get the book if you
don't already have it, and read it if you do.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Uno
>> I'm looking for more of this source, but as a macro neophyte, I have no
>> method for this.
>
> Do you have the book the source comes from? It's a good book
> and does a good job of explaining why the source looks the way it
> does, but it presupposes a certain proficiency in C. If you're
> just looking at the source without the book's explanations (and
> especially if you're the neophyte you say you are), I don't think
> you're likely to gain much understanding. Get the book if you
> don't already have it, and read it if you do.
>
What I meant when I said that I was looking for more of this source, I
was trying to find it on my own system, with which I have only 6 months
experience. My search for stdio.h turned up 7 results, and I was sunk.
Plauger's book is fascinating, and he was nice enough to send me the
source, so if I have trouble with any part of it, I can learn from my
compiler. (or copy, paste, and post to usenet)
It will be the only book that comes with me to Lake Heron, NM now for 4
days of camping at 7200 feet. I'll waive to you in your Arizona swelter.;-)
--
Uno
Eric Sosman
> Eric Sosman wrote:
>
>>> I'm looking for more of this source, but as a macro neophyte, I have no
>>> method for this.
>>
>> Do you have the book the source comes from? It's a good book
>> and does a good job of explaining why the source looks the way it
>> does, but it presupposes a certain proficiency in C. If you're
>> just looking at the source without the book's explanations (and
>> especially if you're the neophyte you say you are), I don't think
>> you're likely to gain much understanding. Get the book if you
>> don't already have it, and read it if you do.
>
> What I meant when I said that I was looking for more of this source, I
> was trying to find it on my own system, with which I have only 6 months
> experience. My search for stdio.h turned up 7 results, and I was sunk.
Do you understand that Plauger's code is *a* way of implementing the
Standard library, not *the* way? The library implementation(s) you
find on your system will certainly be different from Plauger's, in
detail and perhaps in overall structure.
> Plauger's book is fascinating, and he was nice enough to send me the
> source, so if I have trouble with any part of it, I can learn from my
> compiler. (or copy, paste, and post to usenet)
He sent you the code *and* permission to redistribute? I think
you should double-check before posting too freely. "Fair use" covers
a certain amount of copying (IANAL), but there's a limit.
> It will be the only book that comes with me to Lake Heron, NM now for 4
> days of camping at 7200 feet. I'll waive to you in your Arizona swelter.;-)
Never been there; not likely to go. And it's "wave."
--
Eric Sosman
eso...@ieee-dot-org.invalid
Uno
> On 7/1/2010 11:13 PM, Uno wrote:
>> Eric Sosman wrote:
>>
>>>> I'm looking for more of this source, but as a macro neophyte, I have no
>>>> method for this.
>>>
>>> Do you have the book the source comes from? It's a good book
>>> and does a good job of explaining why the source looks the way it
>>> does, but it presupposes a certain proficiency in C. If you're
>>> just looking at the source without the book's explanations (and
>>> especially if you're the neophyte you say you are), I don't think
>>> you're likely to gain much understanding. Get the book if you
>>> don't already have it, and read it if you do.
>>
>> What I meant when I said that I was looking for more of this source, I
>> was trying to find it on my own system, with which I have only 6 months
>> experience. My search for stdio.h turned up 7 results, and I was sunk.
>
> Do you understand that Plauger's code is *a* way of implementing the
> Standard library, not *the* way? The library implementation(s) you
> find on your system will certainly be different from Plauger's, in
> detail and perhaps in overall structure.
That's one thing that Keith has taught me over the years, namely, that
trapseing through the headers on your own implementation might not be
the best way to do what you're trying to achieve.
[OT]
Is there a linux or gcc command that will tell me the inclusion tree for
stdio.h?
>
>> Plauger's book is fascinating, and he was nice enough to send me the
>> source, so if I have trouble with any part of it, I can learn from my
>> compiler. (or copy, paste, and post to usenet)
>
> He sent you the code *and* permission to redistribute? I think
> you should double-check before posting too freely. "Fair use" covers
> a certain amount of copying (IANAL), but there's a limit.
Yeah, and again he is really cool about it. You *can* use his stuff and
make money off it; you simply have to acknowledge.
My quoting a paragraph here or line there could never be stitched
together into a workproduct; you would need *all* of the source.
I will tell people how to write a very gracious man and replicate my
steps to getting the soft version of Plauger's library. I would
consider owning his book _The C Standard Library_ as a prereq. During
the formation of the C standard, he chaired the effort on the standard
library.
My particular interest is not that I want to write a standard library
myself, but I want to be able to use C to call whatever library I need.
I've come to learn that "library" can mean "any number you can calculate
with fortran."
>
>> It will be the only book that comes with me to Lake Heron, NM now for 4
>> days of camping at 7200 feet. I'll waive to you in your Arizona
>> swelter.;-)
>
> Never been there; not likely to go. And it's "wave."
Your loss, it's beautiful. It was a little bit rugged up there, tho.
We camped in tents but could easily walk to a place where you have
electricity and could take a duke on a toilet with proper plumbing and
sanitation. (That's my dealbreaker for "roughing it.")
It has what every C programmer wants: no bugs.
--
Uno
Richard Heathfield
<snip>
> That's one thing that Keith has taught me over the years,
If you've been learning from Keith for years, how come you still don't
know that getc and related functions return int, not char?
You would do well to spend less time delving into the deep stuff (for
now), and a lot more time learning the basics. Once you have learned
them, try not to forget them.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Uno
> Uno wrote:
>
> <snip>
>
>> That's one thing that Keith has taught me over the years,
>
> If you've been learning from Keith for years, how come you still don't
> know that getc and related functions return int, not char?
Because the difference doesn't amount to a hill of beans when I'm
looking for something more important.
>
> You would do well to spend less time delving into the deep stuff (for
> now), and a lot more time learning the basics. Once you have learned
> them, try not to forget them.
>
You would do well not to sound like seebs.
--
Uno
Vincenzo Mercuri
> You would do well not to sound like seebs.
Maybe you mistook thread for threat. uno.
"Speaking words of wisdom, write in C...".
--
Vincenzo Mercuri
Richard Heathfield
> Richard Heathfield wrote:
>> Uno wrote:
>>
>> <snip>
>>
>>> That's one thing that Keith has taught me over the years,
>>
>> If you've been learning from Keith for years, how come you still don't
>> know that getc and related functions return int, not char?
>
> Because the difference doesn't amount to a hill of beans when I'm
> looking for something more important.
If there's anything more important than getting things right, I'd love
to hear what it is.
>>
>> You would do well to spend less time delving into the deep stuff (for
>> now), and a lot more time learning the basics. Once you have learned
>> them, try not to forget them.
>>
>
> You would do well not to sound like seebs.
Seebs will give you the same advice as me (in this regard) for the
simple reason that it's good advice. So will Keith Thompson. So will
anyone with a reasonable level of C knowledge. Why bother to ask C
people C questions if you are not even remotely interested in learning
the answers?
bart.c
news:89hp0i...@mid.individual.net...
>>> It will be the only book that comes with me to Lake Heron, NM now for 4
>>> days of camping at 7200 feet. I'll waive to you in your Arizona
>>> swelter.;-)
(The one time I camped in AZ, the overnight low was 22F (-5C).)
--
Bartc
Keith Thompson
> Richard Heathfield wrote:
>> Uno wrote:
>>
>> <snip>
>>
>>> That's one thing that Keith has taught me over the years,
>>
>> If you've been learning from Keith for years, how come you still
>> don't know that getc and related functions return int, not char?
>
> Because the difference doesn't amount to a hill of beans when I'm
> looking for something more important.
You should rethink your idea of what's important. Hint: correctness
should be high on the list.
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Uno
> Uno ha scritto:
>
>> You would do well not to sound like seebs.
>
> Maybe you mistook thread for threat. uno.
>
> "Speaking words of wisdom, write in C...".
>
>
I understand peace.
--
Uno
Uno
> You should rethink your idea of what's important. Hint: correctness
> should be high on the list.
Sentences of the form:
inanimate object should
are philosophically unintelligible.
Objects lack agency and volition.
Hence,
correctness should
is ludicrous.
But the first one's better. An interpersonal should:
x ought y
Was falling into Hume's is-ought gap something you're proud of, when
this failed-distinction creates wars, environmental disasters, and
people without HBO?
--
Uno
Uno
> Uno wrote:
>> Richard Heathfield wrote:
>>> Uno wrote:
>>>
>>> <snip>
>>>
>>>> That's one thing that Keith has taught me over the years,
>>>
>>> If you've been learning from Keith for years, how come you still
>>> don't know that getc and related functions return int, not char?
>>
>> Because the difference doesn't amount to a hill of beans when I'm
>> looking for something more important.
>
> If there's anything more important than getting things right, I'd love
> to hear what it is.
Where to start. I'd like to get accurate numbers from British
Petroleum. I refuse to let Jim Demint stand between two governments in
his awesome, wretched Southern, filibustering Repugnance.
I remember you as one of the good guys while Blair was dismantling your
higher laws.
>
>>>
>>> You would do well to spend less time delving into the deep stuff (for
>>> now), and a lot more time learning the basics. Once you have learned
>>> them, try not to forget them.
>>>
>>
>> You would do well not to sound like seebs.
>
> Seebs will give you the same advice as me (in this regard) for the
> simple reason that it's good advice. So will Keith Thompson. So will
> anyone with a reasonable level of C knowledge. Why bother to ask C
> people C questions if you are not even remotely interested in learning
> the answers?
>
Dream of C, Richard:
http://i27.tinypic.com/13zzknp.jpg
http://i26.tinypic.com/2eplz47.jpg
Tja,
--
Uno
Nick Keighley
> Richard Heathfield wrote:
> > Uno wrote:
> >> Richard Heathfield wrote:
> >>> Uno wrote:
> >>>> That's one thing that Keith has taught me over the years,
>
> >>> If you've been learning from Keith for years, how come you still
> >>> don't know that getc and related functions return int, not char?
>
> >> Because the difference doesn't amount to a hill of beans when I'm
> >> looking for something more important.
>
> > If there's anything more important than getting things right, I'd love
> > to hear what it is.
there are some subjects where being pedantically right is over kill.
You can be about right or good enough. Unfortunately computer
programming isn't one of those subjects. The computer does exactly
what you tell it. Absolute corretness is important.
> Where to start. I'd like to get accurate numbers from British
> Petroleum.
and this has what to do with comp.lang.c?
> I refuse to let Jim Demint stand between two governments in
> his awesome, wretched Southern, filibustering Repugnance.
I have no idea who Jim Demint (that's actually a name?) is. I suspect
many posters to clc don't either. Or care. I guess he is american
because you mentioned "filibuster" and "repugnance" (which, I
understand is a cool dood way to refer to the Republican party by
people who don't like them).
> I remember you as one of the good guys while Blair was dismantling your
> higher laws.
I'm from the UK and I didn't even know we *had* any higher laws. What
*is* a higher law?
<snip>
Nick Keighley
> Keith Thompson wrote:
> > You should rethink your idea of what's important. Hint: correctness
> > should be high on the list.
>
> Sentences of the form:
>
> inanimate object should
>
> are philosophically unintelligible.
>
> Objects lack agency and volition.
your grasp of english grammar is about on pair with your C. It's not
"correctness" that has the volition in that sentence but you.
Ben Bacarisse
> Keith Thompson wrote:
>
>> You should rethink your idea of what's important. Hint: correctness
>> should be high on the list.
>
> Sentences of the form:
>
> inanimate object should
>
> are philosophically unintelligible.
> Objects lack agency and volition.
>
> Hence,
>
> correctness should
>
> is ludicrous.
That's nonsense, and arrogant nonsense at that.
How silly of Shakespeare to use such ludicrous phrases as "Revenge
should have no bounds" (Hamlet) or "Which end o' the beam should bow"
(The Tempest). How lax of Russel to write "Philosophy should show us
the hierarchy of our instinctive beliefs" (The Problems of Philosophy,
1912). How fortunate we are to get instruction from you is such
matters!
<snip>
--
Ben.
Richard Heathfield
> Richard Heathfield wrote:
<snip>
>> If there's anything more important than getting things right, I'd love
>> to hear what it is.
>
> Where to start.
Do you, then, think that it's important to start in the wrong place?
<snip>
Richard Heathfield
> On 11 July, 08:34, Uno <merrilljen...@q.com> wrote:
<snip>
>> Objects lack agency and volition.
>
> your grasp of english grammar is about on pair with your C.
People in grass houses shouldn't stow thrones.
"Your grasp of English grammar is about on a par with your C" would have
made a lot more sense.
<snip>
io_x
>there are some subjects where being pedantically right is over kill.
>You can be about right or good enough. Unfortunately computer
>programming isn't one of those subjects. The computer does exactly
>what you tell it. Absolute corretness is important.
instead of "Absolute correctness", what about one
"relative correcteness" at last until when some error goes
out from some test, or from the use?
[and that error is so importat to be correct]
Keith Thompson
There are some things that are really easy to get right, including
getting the return type of getc right. Absolute correctness isn't
always possible, but getting the little things right is.
Richard Heathfield
> "io_x" <a...@b.c.invalid> writes:
>> "Nick Keighley" ha scritto nel messaggio
>> instead of "Absolute correctness", what about one
>> "relative correcteness" at last until when some error goes
>> out from some test, or from the use?
>> [and that error is so importat to be correct]
>
> There are some things that are really easy to get right, including
> getting the return type of getc right. Absolute correctness isn't
> always possible, but getting the little things right is.
To be fair, Nick K didn't demand absolute correctness.
He nearly did - but not quite. :-)
io_x
>> "Nick Keighley" ha scritto nel messaggio
>>>there are some subjects where being pedantically right is over kill.
>>>You can be about right or good enough. Unfortunately computer
>>>programming isn't one of those subjects. The computer does exactly
>>>what you tell it. Absolute corretness is important.
>>
>> instead of "Absolute correctness", what about one
>> "relative correcteness" at last until when some error goes
>> out from some test, or from the use?
>> [and that error is so importat to be correct]
>
> There are some things that are really easy to get right, including
> getting the return type of getc right. Absolute correctness isn't
> always possible, but getting the little things right is.
if you mean how getc is written: i see now in K&R2 getc() is a macro
in which there is the function _fillbuf(),
there could be errors, who know it?
if gets "little things" right is possible, than it is possible not
doing error in assembly: what is more small than these instructions? :)
Dann Corbit
a...@b.c.invalid says...
>
> "Keith Thompson" ha scritto nel messaggio > "io_x" <a...@b.c.invalid> writes:
> >> "Nick Keighley" ha scritto nel messaggio
> >>>there are some subjects where being pedantically right is over kill.
> >>>You can be about right or good enough. Unfortunately computer
> >>>programming isn't one of those subjects. The computer does exactly
> >>>what you tell it. Absolute corretness is important.
> >>
> >> instead of "Absolute correctness", what about one
> >> "relative correcteness" at last until when some error goes
> >> out from some test, or from the use?
> >> [and that error is so importat to be correct]
> >
> > There are some things that are really easy to get right, including
> > getting the return type of getc right. Absolute correctness isn't
> > always possible, but getting the little things right is.
>
> if you mean how getc is written: i see now in K&R2 getc() is a macro
> in which there is the function _fillbuf(),
> there could be errors, who know it?
In K&R2 there is an example of an implementation of fopen() and getc()
in section 8.5.
This has nothing to do with how any actual library implementor performs
the task. If the actual library implementor should create a function
called _fillbuf(), which resides in the implementation's namespace, and
if _fillbuf() was indeed used as shown in the sample implementation in
the book, then the library implementor is responsible for the
correctness of _fillbuf(). If getc() does not work as defined in the
standard and the reason is that they have done something wrong with
_fillbuf() then you should report the error to your library vendor. I
guess that such an errant version of a C library does not exist.
> if gets "little things" right is possible, than it is possible not
> doing error in assembly: what is more small than these instructions? :)
Colorless green ideas sleep furiously.
Nick Keighley
wrote:
> > I'd like to get accurate numbers from British Petroleum.
oh, and that isn't the name of the company that is leaking oil off
your coast
Nick Keighley
> Keith Thompson wrote:
> > "io_x" <a...@b.c.invalid> writes:
> >> "Nick Keighley" ha scritto nel messaggio
> >>> [...] Absolute corretness is important.
>
> >> instead of "Absolute correctness", what about one
> >> "relative correcteness" at last until when some error goes
> >> out from some test, or from the use?
> >> [and that error is so importat to be correct]
>
> > There are some things that are really easy to get right, including
> > getting the return type of getc right. Absolute correctness isn't
> > always possible, but getting the little things right is.
>
> To be fair, Nick K didn't demand absolute correctness.
>
> He nearly did - but not quite. :-)
:-)
Keith Thompson
> "Keith Thompson" ha scritto nel messaggio > "io_x" <a...@b.c.invalid> writes:
>>> "Nick Keighley" ha scritto nel messaggio
>>>>there are some subjects where being pedantically right is over kill.
>>>>You can be about right or good enough. Unfortunately computer
>>>>programming isn't one of those subjects. The computer does exactly
>>>>what you tell it. Absolute corretness is important.
>>>
>>> instead of "Absolute correctness", what about one
>>> "relative correcteness" at last until when some error goes
>>> out from some test, or from the use?
>>> [and that error is so importat to be correct]
>>
>> There are some things that are really easy to get right, including
>> getting the return type of getc right. Absolute correctness isn't
>> always possible, but getting the little things right is.
>
> if you mean how getc is written: i see now in K&R2 getc() is a macro
> in which there is the function _fillbuf(),
> there could be errors, who know it?
No, I mean how getc is called in user code. In this thread, when
someone pointed out that getc returns int, not char, Uno replied:
| Because the difference doesn't amount to a hill of beans when I'm
| looking for something more
| important.
[...]
io_x
"Dann Corbit" ha scritto nel messaggio
news:MPG.26a5da0ad...@news.eternal-september.org...
>> doing error in assembly: what is more small than these instructions? :)
>
> Colorless green ideas sleep furiously.
what does it mean?
i would traslate it in italian as
"meno colorate verdi idee dormono furiosamente"
Richard Heathfield
> "Dann Corbit" ha scritto nel messaggio
> news:MPG.26a5da0ad...@news.eternal-september.org...
>> In article <4c3c3186$0$12129$4faf...@reader4.news.tin.it>,
>> a...@b.c.invalid says...
>>> if gets "little things" right is possible, than it is possible not
>>> doing error in assembly: what is more small than these instructions? :)
>> Colorless green ideas sleep furiously.
>
> what does it mean?
The statement itself is a well-known example of a meaningless statement.
It is not the statement itself, but the fact that he made it, that is
significant.
> i would traslate it in italian as
> "meno colorate verdi idee dormono furiosamente"
<rhetorical>Why?</rhetorical>
Richard Harter
<r...@see.sig.invalid> wrote:
>io_x wrote:
>> "Dann Corbit" ha scritto nel messaggio
>> news:MPG.26a5da0ad...@news.eternal-september.org...
>>> In article <4c3c3186$0$12129$4faf...@reader4.news.tin.it>,
>>> a...@b.c.invalid says...
>>>> if gets "little things" right is possible, than it is possible not
>>>> doing error in assembly: what is more small than these instructions? :)
>>> Colorless green ideas sleep furiously.
>>
>> what does it mean?
>
>The statement itself is a well-known example of a meaningless statement.
>It is not the statement itself, but the fact that he made it, that is
>significant.
>
>> i would traslate it in italian as
>> "meno colorate verdi idee dormono furiosamente"
>
><rhetorical>Why?</rhetorical>
From http://home.tiac.net/~cri/1997/chomsky.html
(Essay by yours truly)
The sentence, "Colorless green ideas sleep furiously", was
presented by Chomsky, as a great example of a series of words
strung together randomly. Not only is it grammatical according to
the lexical classification, and non-sense on a semantic level. Or
so goes the claim. But is the claim correct?
A green idea is, according to well established usage of the word
"green" is one that is an idea that is new and untried. Again, a
colorless idea is one without vividness, dull and unexciting. So
it follows that a colorless green idea is a new, untried idea
that is without vividness, dull and unexciting. To sleep is,
among other things, is to be in a state of dormancy or
inactivity, or in a state of unconsciousness. To sleep furiously
may seem a puzzling turn of phrase but one reflects that the mind
in sleep often indeed moves furiously with ideas and images
flickering in and out.
So what is the poet telling us? (One assumes that the quoted line
is from the work of a poet working in a medium of studied
precision and ambiguity. Or rather, as we shall see...) Very
simply the poet seems to be saying that new ideas, not yet
sharply defined, circulate in the unconscious, rapidly altering
at a furious rate.
One is left then with a question. Why is this nice bit of poetic
imagery cited by its author as a quintessentially meaningless
sentence? Here we have an exquisite bit of irony. The author
evidently has a turn for poetry, a turn which he turns his face
against. And the hidden face, the denied self, has taken its
revenge. The scientist has called on his creative self to exhibit
a bit of nonsense. The poet denied has replied with a sentence,
apparently meaningless, which is no such thing when listened to
with an attentive ear. And yet consider; this sentence is a very
intellectualized production - it is indeed "colorless". It was,
we suspect, a new idea, a variant of a possibility, still new at
the very moment of production, one occurring by chance in the
froth of the unconscious.
In short, the cited sentence was a colorless green idea that had
slept furiously.
Richard Heathfield
> On Wed, 14 Jul 2010 17:13:26 +0100, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
>> io_x wrote:
>>> "Dann Corbit" ha scritto nel messaggio
>>> news:MPG.26a5da0ad...@news.eternal-september.org...
>>>> In article <4c3c3186$0$12129$4faf...@reader4.news.tin.it>,
>>>> a...@b.c.invalid says...
>>>>> if gets "little things" right is possible, than it is possible not
>>>>> doing error in assembly: what is more small than these instructions? :)
>>>> Colorless green ideas sleep furiously.
>>> what does it mean?
>> The statement itself is a well-known example of a meaningless statement.
>> It is not the statement itself, but the fact that he made it, that is
>> significant.
>>
>>> i would traslate it in italian as
>>> "meno colorate verdi idee dormono furiosamente"
>> <rhetorical>Why?</rhetorical>
>
> From http://home.tiac.net/~cri/1997/chomsky.html
> (Essay by yours truly)
>
>
> The sentence, "Colorless green ideas sleep furiously", was
> presented by Chomsky, as a great example of a series of words
> strung together randomly. Not only is it grammatical according to
> the lexical classification, and non-sense on a semantic level.
The above sentence is "antautological" (i.e. it exactly fails to be
self-describing) - it is non-grammatical, but meaningful at the semantic
level if one can see past its grammatical failures and strive to grasp
the meaning that is there.
A better attempt: "It is grammatical according to the lexical
classification, but nonsense on a semantic level".
> Or
> so goes the claim. But is the claim correct?
Puckering silent crises defuse hub forks.
<snip>
> In short, the cited sentence was a colorless green idea that had
> slept furiously.
In other word, autological.
Nick Keighley
> "Dann Corbit" ha scritto nel messaggionews:MPG.26a5da0ad...@news.eternal-september.org...
>
> > a...@b.c.invalid says...
> >> if gets "little things" right is possible, than it is possible not
> >> doing error in assembly: what is more small than these instructions? :)
>
> > Colorless green ideas sleep furiously.
>
> what does it mean?
it is meaningless. Like your sentence.
Ben Bacarisse
<snip>
> From http://home.tiac.net/~cri/1997/chomsky.html
> (Essay by yours truly)
>
> The sentence, "Colorless green ideas sleep furiously", was
> presented by Chomsky, as a great example of a series of words
> strung together randomly. Not only is it grammatical according to
> the lexical classification, and non-sense on a semantic level. Or
> so goes the claim.
That has become the common view, but it is not why the phrase was
originally presented. Specifically, Chomsky did not say that no meaning
could be attributed to it. For his purposes it was sufficient that it
be absurd enough to be unlikely to have been uttered before.
[You seem to be using "non-sense" in the way that it is used in
linguistics which has a different meaning to "nonsense" (i.e. "absurd")
which is the word Chomsky used.]
> But is the claim correct?
There is nothing wrong with refuting the common misconception that it
has no meaning, but that claim should not be attributed to Chomsky. I
am sure he is quite astute enough to know that meanings can be found for
superficially absurd statements.
<snip>
--
Ben.
Uno
The sun should shine on everyone, simultaneously.
Russell embarrassed himself in particular ways. (His sentiments on
coition are like Mr. Burns'. Isssshhhh.)
> "Which end o' the beam should bow"
I look at this as different than interpersonal normative posturing, as
there is a lot of tensor mathematics hiding in the modal there. The
"should" is an accounting of forces along the relevant member.
I don't want you to call me arrogant.
--
Uno
Uno
> Nick Keighley wrote:
>> On 11 July, 08:34, Uno <merrilljen...@q.com> wrote:
>
> <snip>
>
>>> Objects lack agency and volition.
>>
>> your grasp of english grammar is about on pair with your C.
>
> People in grass houses shouldn't stow thrones.
>
> "Your grasp of English grammar is about on a par with your C" would have
> made a lot more sense.
Well that's where being 2 meters and a hundred kilograms helps, in that
one needs to say less. Funny, I never got less than an A in English,
German, or Russian, deutsch ausgenommen, da es mich nicht heiss machte.
--
Uno
Nick Keighley
> Ben Bacarisse wrote:
> >>> You should rethink your idea of what's important. Hint: correctness
> >>> should be high on the list.
>
> >> Sentences of the form:
>
> >> inanimate object should
> >> are philosophically unintelligible.
> >> Objects lack agency and volition.
>
> >> Hence, correctness should is ludicrous.
>
> > That's nonsense, and arrogant nonsense at that.
>
> > How silly of Shakespeare to use such ludicrous phrases as "Revenge
> > should have no bounds" (Hamlet) or "Which end o' the beam should bow"
> > (The Tempest). How lax of Russel to write "Philosophy should show us
> > the hierarchy of our instinctive beliefs" (The Problems of Philosophy,
> > 1912). How fortunate we are to get instruction from you is such
> > matters!
<snip>
> Russell embarrassed himself in particular ways. (His sentiments on
> coition are like Mr. Burns'. Isssshhhh.)
don't post while drunk
<snip>
> I don't want you to call me arrogant.
don't be arrogant then
Uno
> Uno wrote:
>> Richard Heathfield wrote:
>
> <snip>
>
>>> If there's anything more important than getting things right, I'd
>>> love to hear what it is.
>>
>> Where to start.
>
> Do you, then, think that it's important to start in the wrong place?
I may have a little displaced anger about the British fucking my Gulf
right now. Sorry, it will pass. (The Gulf, not the anger.)
--
Uno
Richard Heathfield
I don't quite see how a non sequitur advances your argument.
Nick
Well she shouldn't have winked like that.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
blm...@myrealbox.com
Richard Harter <c...@tiac.net> wrote:
> On Wed, 14 Jul 2010 17:13:26 +0100, Richard Heathfield
> <r...@see.sig.invalid> wrote:
>
> >io_x wrote:
> >> "Dann Corbit" ha scritto nel messaggio
> >> news:MPG.26a5da0ad...@news.eternal-september.org...
> >>> In article <4c3c3186$0$12129$4faf...@reader4.news.tin.it>,
> >>> a...@b.c.invalid says...
> >>>> if gets "little things" right is possible, than it is possible not
> >>>> doing error in assembly: what is more small than these instructions? :)
> >>> Colorless green ideas sleep furiously.
> >>
> >> what does it mean?
> >
> >The statement itself is a well-known example of a meaningless statement.
> >It is not the statement itself, but the fact that he made it, that is
> >significant.
> >
> >> i would traslate it in italian as
> >> "meno colorate verdi idee dormono furiosamente"
> >
> ><rhetorical>Why?</rhetorical>
>
> >From http://home.tiac.net/~cri/1997/chomsky.html
> (Essay by yours truly)
I suspect you will not be pleased to hear that I found your essay
disturbingly reminiscent of someone who appears to have left the
building, for now anyway. Sort of a :-).
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Richard Harter
<blm...@myrealbox.com> wrote:
Pleased is not the word you want; highly amused would be
appropriate.
Richard Bos
> On 11 July, 12:56, Nick Keighley <nick_keighley_nos...@hotmail.com>
>
> > > I'd like to get accurate numbers from British Petroleum.
>
> oh, and that isn't the name of the company that is leaking oil off
> your coast
Well, to be fair, Amoco is no longer the official name of the company.
(IIRC they once considered changing their name to Cadiz American Oil,
but had second thoughts for some reason.)
Richard
blm...@myrealbox.com
Richard Harter <c...@tiac.net> wrote:
> On 22 Jul 2010 16:07:56 GMT, blm...@myrealbox.com
> <blm...@myrealbox.com> wrote:
>
> >In article <4c3e8dc7....@text.giganews.com>,
> >Richard Harter <c...@tiac.net> wrote:
> >> On Wed, 14 Jul 2010 17:13:26 +0100, Richard Heathfield
> >> <r...@see.sig.invalid> wrote:
> >>
> >> >io_x wrote:
[ snip ]
> >> >From http://home.tiac.net/~cri/1997/chomsky.html
> >> (Essay by yours truly)
> >
> >I suspect you will not be pleased to hear that I found your essay
> >disturbingly reminiscent of someone who appears to have left the
> >building, for now anyway. Sort of a :-).
>
> Pleased is not the word you want; highly amused would be
> appropriate.
Okay, s/pleased/highly amused/, and we get ....
"I suspect you will not be highly amused ...."
Very possibly that wasn't what you meant. Just nitpicking a bit.