 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> The idea here is that we jump to one label, then jump to another, then
> jump to another, never returning to the "caller".
>
> If we implement this using C functions that never return, an unbounded
> amount of stack gets eaten.
>
> Hence, they arranged for each function to *return* the function it would
> like to jump to next, rather than actually jumping to it, and the loop I
> posted is apparently the magic incantation that implements the jumping.
Yes, indeed.
http://en.wikipedia.org/wiki/Tail_recursion#Implementation_methods
I take it that you were looking at the C output of GHC, right? Haskell relies
on tail-recursion as much as any other functional language, as Scheme. The
method it is implemented underneath is as a trampoline.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> There was an entry over at the Daily WTF in which someone posted code,
> written by another person, containing this:
>
> #define TRUE 0
> #define FALSE 1
>
> I swear that I am not making this up.
I remember it well...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26-Jul-08 21:39, John VanSickle wrote:
> Chris Cason wrote:
>
>> In the real world, no programmer would ever do something
>> that mean with a macro called TRUE. Right? :-)
>
> There was an entry over at the Daily WTF in which someone posted code,
> written by another person, containing this:
>
> #define TRUE 0
> #define FALSE 1
>
> I swear that I am not making this up.
Probably Unix convention?
http://en.wikipedia.org/wiki/True_(Unix)
http://en.wikipedia.org/wiki/False_(Unix)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> There was an entry over at the Daily WTF in which someone posted code,
>> written by another person, containing this:
>>
>> #define TRUE 0
>> #define FALSE 1
>>
>> I swear that I am not making this up.
>
> Probably Unix convention?
Ah yes - return code 0 = OK, any other code = failure.
What have we learned here? That using integers to represent Booleans is
a Very Bad Thing. :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> >> There was an entry over at the Daily WTF in which someone posted code,
> >> written by another person, containing this:
> >>
> >> #define TRUE 0
> >> #define FALSE 1
> >>
> >> I swear that I am not making this up.
> >
> > Probably Unix convention?
> Ah yes - return code 0 = OK, any other code = failure.
C actually distinguishes between TRUE/FALSE and EXIT_SUCESS/EXIT_FAILURE.
They shouldn't be confused nor mixed.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Because "while(1)" is a common idiom, and avoids the ugly goto.
>
Either that or for(;;) { ... }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Because "while(1)" is a common idiom, and avoids the ugly goto.
>
> Either that or for(;;) { ... }
...and to think people complain when a Haskell programmer writes
fix ((1:) . scanl (+) 1)
or something... :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> (Another less fancy way would be to return a null pointer from the
> function, in which case the program will end with a segmentation fault.)
Well, maybe if you're lucky. :-) Otherwise, it just goes off happily
executing whatever is at memory address zero (or whatever NULL maps to).
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > (Another less fancy way would be to return a null pointer from the
> > function, in which case the program will end with a segmentation fault.)
> Well, maybe if you're lucky. :-) Otherwise, it just goes off happily
> executing whatever is at memory address zero (or whatever NULL maps to).
I'm pretty sure POSIX or some other type of standard states that jumping
to the null pointer will always cause a segmentation fault.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> (Another less fancy way would be to return a null pointer from the
>>> function, in which case the program will end with a segmentation fault.)
>
>> Well, maybe if you're lucky. :-) Otherwise, it just goes off happily
>> executing whatever is at memory address zero (or whatever NULL maps to).
>
> I'm pretty sure POSIX or some other type of standard states that jumping
> to the null pointer will always cause a segmentation fault.
But not the C standard. Try it on MS-DOS, Win 3.1, AmigaDOS, a credit
card terminal, a cell phone, etc. :-) Basically, you're saying you
can't have a POSIX-compliant system without memory mapping, methinks.
But C is used in particular because of its primitiveness and lack of
reliance on a particular complex bit of hardware.
"The operating system is there to provide the facilities the language
designer left out."
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
