On 4/20/2012 5:18, Warp wrote:
> Darren New<dne### [at] sanrrcom>  wrote:
>> If you could #include<abc.o>  you'd get rid of all the silliness of
>> declaring inline functions multiple times, function prototypes, and all that
>> kind of BS.
>
>    So you would be simply changing the dependency to a .h file to dependency
> to a .o file. What would be the relevant difference?

You'd be getting rid of function prototypes, declaring inline functions 
multiple times, mismatched declarations between compilation units, 
compatible compiler flags between separately-compiled modules, and etc. That 
would be the relevant difference.

(Of course, if you *want* to have header files, you can still depend on the 
.o file instead of the .h file, and let people write the .c file even though 
you can still compile against the .h file.)

>    Also, I assume you understand that templated code cannot be precompiled
> into an object file? They need to be recompiled each time they are used...
> which is kind of the whole idea.

Of course. It's basically macro expansion. That's why I didn't say depending 
on a .h file would get rid of template functions.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/20/2012 0:20, Le_Forgeron wrote:
> Le 20/04/2012 03:56, Darren New a écrit :
>> On 4/19/2012 18:38, Alain wrote:
>>> Le 2012/04/17 09:40, Warp a écrit :
>>>
>>>>> is a perfectly valid statement in C++. On the other hand, it also
>>>>> means that
>>>>
>>>>> while (x[i] = y[i--]) ;
>>>>
>>>>> is perfectly valid. You sick, sick people.
>>>>
>>>> I think that's Undefined Behavior because the same variable is being

>>>> modified and referenced more than once in the same expression.
>>>>
>>>
>>> Nothing undefined here.
>>
>> Does it compare x[i] to y[i] or to y[i-1]?  Why do you answer that way
?
>>
> You missed the point: let's name k the initial value of i;

I don't think I missed the point. I just got the possible answers wrong. 
The 
*point* was that there *were* multiple possible answers. :-)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/20/2012 0:55, Invisible wrote:
>>>>> while (x[i] = y[i--]) ;
>>>>
>>>>> is perfectly valid. You sick, sick people.
>>>>
>>>> I think that's Undefined Behavior because the same variable is being
>>>> modified and referenced more than once in the same expression.
>>>>
>>>
>>> Nothing undefined here.
>>
>> Does it compare x[i] to y[i] or to y[i-1]? Why do you answer that way?
>
> Last time I checked, the /comparison/ operator is ==.
>
> The = operator performs *assignment*. :-P

Yah yah. Still missing the point. It's still undefined, whether it's an 
assignment or a comparison.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/20/2012 0:57, Invisible wrote:
>>> When will we see the Haskell# language?
>>
>> I'm pretty sure the whole .NET bit is too OO to make that useful.There's
>> way too much stateful stuff (like I/O) that you'd want to use from .NET
>> to make it reasonable to have a purely function .net language.
>
> Haskell already supports a wide range of I/O operations. That's pretty
> stateful, and it's not a problem.
>
> Yeah, if you wanted to talk to the .NET libraries, it would all end up being
> monadic. (Even the .NET stuff that's actually pure - since it isn't /marked/
> as pure.) But it would still work fine.
>
> I think it's probably vacuous to try to estimate how "useful" it would be
> without actually trying it...

Well, they tried making STM work on .NET and gave up because of all the 
state, if you remember.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/20/2012 10:02, Orchid Win7 v1 wrote:
> On 20/04/2012 02:41 AM, Darren New wrote:
>> Plus, the IDE for Smalltalk doesn't really deal too much with the fact
>> that it's OO. It didn't do any of the sorts of completion you're talking
>> about.
>
> Well, to be fair, since Smalltalk isn't statically typed, you'd be
> hard-pressed to figure out what messages are applicable to a given variable.
> ;-)

You'd be surprised. People write code that looks at javascript, for example, 
and comes up with something like 70% of the variables being statically typed 
in ways that it's even easy to tell.  Even when you *could* figure it out, 
indeed even when the variable had a value already, you didn't get the sorts 
of completion you're talking about.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

On 4/20/2012 1:07, Invisible wrote:
>>> (And besides, any kind of detection of this cannot be 100% accurate,
>>> as the problem "will this line of code ever be reached?" is unsolvable
>>> in the general case.)
>>
>> But detecting type errors isn't 100% accurate either.
>>
>> int x = 1 ? 5 : "hello";
>>
>> That's not legal, but it's not a type violation either.
>
> The general problem of determining whether every possible code path is
> well-typed is undecidable. Type systems insert artificial restrictions to
> /make/ the problem decidable. Hence, there are expressions and statements
> which are well-typed, but do not type-check.

Which is the point I'm making. We put up with saying "that'll never be the 
wrong type, but it's still illegal", so the argument that "whether this code 
is reachable is unsolvable, so we shouldn't even try" is equally bogus.)

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message

>> Does it round towards zero, or towards negative infinity?
>
> I don't remember. I never use it under those circumstances, probably
> because it's implementation-defined.

No wonder so many programs don't compile if you (say) change from a 
32-bit OS to a 64-bit OS...

>> A better way might be to think of true and false as 1 and 0. (Although of
>> course C allows true to be /anything/ that isn't 0, not just 1.)
>
> The real way to think of it is "BZ" and "BNZ"

Sure, that's obviously how it's implemented (and why it works that way). 
Still doesn't help me remember which is which. ;-)

Post a reply to this message

>>> But detecting type errors isn't 100% accurate either.
>>>
>>> int x = 1 ? 5 : "hello";
>>>
>>> That's not legal, but it's not a type violation either.
>>
>> The general problem of determining whether every possible code path is
>> well-typed is undecidable. Type systems insert artificial restrictions to
>> /make/ the problem decidable. Hence, there are expressions and statements
>> which are well-typed, but do not type-check.
>
> Which is the point I'm making.

And I'm agreeing. ;-) [Although I'm not sure I got the technical terms 
right...]

> We put up with saying "that'll never be
> the wrong type, but it's still illegal", so the argument that "whether
> this code is reachable is unsolvable, so we shouldn't even try" is
> equally bogus.)

Well, to be fair, the code you worked is well-typed, but /very stupid/. 
The fact that it gets rejected is no big deal, really.

(OTOH, all the advocates of dynamically-typed languages seem to think 
that this is /the primary reason/ that statically-typed languages suck - 
because you /can't/ just do whatever the hell you want, no matter how 
incoherent.)

Post a reply to this message

> You have no way of knowing how much stack space you have. Nobody writing
> reliable code wants to recurse for each level of a tree without knowing
> how deep the tree is.

Nobody writes recursive code? IN WHICH UNIVERSE??

I'm also loving the way you say "you don't know how big the stack is", 
and immediately follow that with "you should check how deep the tree 
is". But if you don't know how big the stack is, you STILL don't know if 
you can do it. :-P

Besides, it's not like there's an /alternative/ to recursion.

>> Nobody designs hardware like that any more. Haven't done for decades. :-P
>
> So? They're still special areas of memory built into the CPU. Just
> because you can't address them using normal addressing modes any more
> doesn't mean they're not memory.

Well, to be /technical/ about it, the entire concept of "memory" is a 
fiction. It would be more accurate to say that there is a large topology 
of transistors connected together - but that's not a very useful way to 
think about it.

>> So you're telling me that the de facto calling convention that all
>> software
>> always uses is "undefined"?
>
> Implementation-specific, yes. How could you define it in a standard when
> you don't even know what architecture you're compiling for?

Amazing. So the one calling convention that every piece of software 
supports isn't actually defined at all. That's impressive, right there.

Post a reply to this message

> At least on machines designed to be programmed in assembler, one can
> generally put a useful and informative comment on pretty much every line.

I haven't yet seen an assembler where you /can't/ stick comments 
anywhere you want to. That /still/ doesn't mean I want the comments to 
out-number the actual code.

>> You'd expect part of the language's basic syntax to be, you know...
>> part of
>> the language's basic syntax. But it isn't. It's just a regular operator,
>> which means you can use it in places where you shouldn't be putting
>> random
>> commas, and that makes it do strange stuff. (And, being C, this isn't
>> checked in any way.)
>
> Why would you put randomg *anything* in? This isn't a sonnet. It's
> computer code. Why would you put random commas in any more than you put
> random quote marks in?

Ever heard of something called a "mistake"? Perhaps you don't make 
those, but I do sometimes. And it's worrying to know that if I do, the 
compiler isn't going to say "oh, you made a mistake", it's just going to 
generate code that does something bizarre.

> Plus, "void" is a relatively recent development.

This is The Real WTF.

Post a reply to this message