>>> Almost all business logic.
>>
>> I suppose I should consider myself lucky that I'm never going to be
>> writing anything like that.
>
> Why not? Didn't you rewrite the code to compile your danse tournament
> rankings?

I did not "rewrite" anything. I merely wrote a program that downloads 
some web pages and attempts to extract the raw data from them. And that 
is all.

(The organiser's website is obnoxiously difficult to navigate. 
Fortunately I was able to reverse-engineer how the URLs are generated...)

> I know you only did it for yourself, but that was business
> logic, even if you weren't using WebSphere, J2EE, Weblogic or some big
> platform like that.

OK.

>> So... how is it ever possible to statically link software?
>
> You have to take extra steps to make sure it works.

Really?

> For example, back in
> the days of Windows 3.1, you had to use the Pascal calling convention
> for your functions in order to make sure that they could interact with
> other modules. (Maybe it's still that way, I haven't touched a C program
> in 15 years.)

So what you're saying is "the C calling convention is undefined, but the 
OS calling convention is not"?

Post a reply to this message

Le 2012-04-25 09:12, Invisible a écrit :
>>> So... how is it ever possible to statically link software?
>>
>> You have to take extra steps to make sure it works.
>
> Really?
>

Yes.  For example: Miocrsoft dictating that all Windows applications and 
DLLs must use the Pascal calling convention.

(I know DLLs are not statically linked... but you get my drift.  If you 
want to use library XYZ, you need to use the same calling convention as 
library X uses.

>> For example, back in
>> the days of Windows 3.1, you had to use the Pascal calling convention
>> for your functions in order to make sure that they could interact with
>> other modules. (Maybe it's still that way, I haven't touched a C program
>> in 15 years.)
>
> So what you're saying is "the C calling convention is undefined, but the
> OS calling convention is not"?

No.  I'm saying - as Darren pointed out - that the C calling convention 
is not undefined, but implementation-defined.  There's a difference.

Division by zero = undefined.
Number of bits in an integer = implementation-defined.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 4/25/2012 1:22, Invisible wrote:
> Really? That's surprising. No recursive sorting algorithms for balancing the
> B*-trees that the directory nodes use, or for sorting the ready thread list
> by priority?

If you can limit the recursion a priori, then sure. If you know you'll only 
have at most 4 levels of tree, or only 128 entries in the list to sort, or 
something like that, recursion is fine. I wouldn't write production code to 
manipulate an arbitrary data structure with actual machine-stack-based 
recursion in C.

> SQL is a rather special-purpose language. I'm not sure it even /supports/
> recursion...

That's kind of my point.

> In other words, you manually implement the stack.

Yes.

> Tell me, in what way does this prevent you running out of stack?

It doesn't. It just keeps you from running out of stack without knowing it.

If your language runtime already supplies that service (e.g., C# throwing an 
exception when it runs out of stack or something) then recursive algorithms 
are fine.

>> Unless you have a CPU that actually enforces calling conventions.
> So... how is it ever possible to statically link software?

You appear to be having a hard time distinguishing "it's 
implemention-defined and not specified in the standard' from "we don't know 
what it is, ever."

> I mean, if every compiler uses its own random calling convention,

It doesn't.

> then how
> /the hell/ is it possible to write some C, link it against GMP, wxWidgets
> and the OS header files, and get a usable binary? You know, given that you
> have no idea which compiler these libraries are compiled with...

Because sometimes the OS defines the calling convention to be used.

> I would, however, expect that on any given architecture, the C calling
> convention is always the same.

In spite of the page I pointed you to showing all the different calling 
conventions used by the x86 line, right?

-- 
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/25/2012 1:12, Invisible wrote:
> You do all of that stuff from /outside/ your transactions, that's all.

Except that .NET is about components, so that doesn't work out too well.

And if you're talking about putting Haskell on .NET, then your entire 
program becomes one "transaction". (Note we've moved to talking about STM 
from talking about Haskell, which was not my intention. It was an analogy.)

> Remember, transactions are only for thread communication. You start a
> transaction, fetch the next work item from the shared work queue, and the
> transaction. Then you process the work item, calling whatever libraries you
> need. Simples.

And if the work item is in a class written that does I/O to obtain it, or to 
log a message, or etc etc etc?

-- 
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 26/04/2012 04:36 AM, Darren New wrote:
> On 4/25/2012 1:12, Invisible wrote:
>> You do all of that stuff from /outside/ your transactions, that's all.
>
> Except that .NET is about components, so that doesn't work out too well.
>
> And if you're talking about putting Haskell on .NET, then your entire
> program becomes one "transaction".

How so?

> (Note we've moved to talking about
> STM from talking about Haskell, which was not my intention. It was an
> analogy.)

OK. And I was just saying that Haskell /already/ lets you use libraries 
written in C, which aren't functional at all. I don't see why using the 
.NET libraries would be any harder. [Assuming you solve the problem of 
how to make your program run on the CLR in the first place, obviously.]

>> Remember, transactions are only for thread communication. You start a
>> transaction, fetch the next work item from the shared work queue, and the
>> transaction. Then you process the work item, calling whatever
>> libraries you need.
>
> And if the work item is in a class written that does I/O to obtain it,
> or to log a message, or etc etc etc?

I am really bad at typing, aren't I? :-S

What I /meant/ to write was that you start a transaction, fetch the next 
work item, and then end the transaction. Once the transaction is over, 
you can do as much I/O as you like.

The problem (I assume) that you're talking about is that all the 
existing .NET stuff is structured under the assumption that you can do 
I/O whenever you feel like it. I can see a few ways to approach that. 
(Perhaps the simplest possibility being "only Haskell is allows to use 
STM". :-P )

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> If you can limit the recursion a priori, then sure. If you know you'll only 
> have at most 4 levels of tree, or only 128 entries in the list to sort, or 
> something like that, recursion is fine. I wouldn't write production code to 
> manipulate an arbitrary data structure with actual machine-stack-based 
> recursion in C.

  Very usually the recursion depth of a typical recursive algorithm is
O(log n). This means that the computer wouldn't be able to hold as much
data as to make you run out of stack space when running the recursive
algorithm on it. (For example, if the recursion depth is 50, that means
that there's about 10^15 elements of data. Even if each element took just
one single byte, that would be like 1024 terabytes of RAM.)

-- 
                                                          - Warp

Post a reply to this message

On 4/26/2012 5:09, Warp wrote:
>    Very usually the recursion depth of a typical recursive algorithm is
> O(log n). This means that the computer wouldn't be able to hold as much
> data as to make you run out of stack space when running the recursive
> algorithm on it.

Assuming that you're not writing a library that might invoke you 40 levels down.

That said, I've found I rarely need it, and that the undefined behavior 
isn't worth the risks. YMMV. If you can handle the program crashing when you 
give it too much data in a way that generates bogus results, then sure, feel 
free. :-)  (I'm not being sarcastic - there are lots of programs like that.)

-- 
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/26/2012 1:13, Invisible wrote:
> OK. And I was just saying that Haskell /already/ lets you use libraries
> written in C, which aren't functional at all.

And can the C call back into the Haskell? And if so, are all the Haskell 
invariants and such maintained? And can you do that without telling the 
caller whether they're calling C or compiled Haskell?

> What I /meant/ to write was that you start a transaction, fetch the next
> work item, and then end the transaction. Once the transaction is over, you
> can do as much I/O as you like.

Right. But if "fetch the transaction" means "obtain it from the server over 
there using TCP/IP", then you're kind of screwed, aren't you?

Heck, even a regular expression match isn't functional in .NET.

> The problem (I assume) that you're talking about is that all the existing
> .NET stuff is structured under the assumption that you can do I/O whenever
> you feel like it. I can see a few ways to approach that. (Perhaps the
> simplest possibility being "only Haskell is allows to use STM". :-P )

And that's the kind of incompatibility I'm saying makes .NET much less useful.

-- 
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

Darren New <dne### [at] sanrrcom> wrote:
> That said, I've found I rarely need it

  It's not usual to need it, but sometimes it can be quite useful.
Almost anything involving things like permutations and combinations
are significantly easier to express recursively than iteratively.

> If you can handle the program crashing when you 
> give it too much data in a way that generates bogus results, then sure, feel 
> free. :-)

  As I said, if the recursion depth is O(log n), then you *can't* give it
so much data as for the stack space to run out. It's physically impossible.

  If your recursion level is O(n), then it sounds a lot like an iterative
algorithm that has been expressed recursively for no good reason. (Of
course exceptions probably exist, but are rare.)

-- 
                                                          - Warp

Post a reply to this message

>> OK. And I was just saying that Haskell /already/ lets you use libraries
>> written in C, which aren't functional at all.
>
> And can the C call back into the Haskell?

Yes. I demonstrated using the C sort() function to sort Haskell data, 
remember?

> And if so, are all the Haskell invariants and such maintained?

You have to tell the compiler whether or not you consider the C function 
to be "pure" or not. Obviously, you can lie. Don't do that.

> And can you do that without telling the
> caller whether they're calling C or compiled Haskell?

Does sort() know what it's calling?

>> What I /meant/ to write was that you start a transaction, fetch the next
>> work item, and then end the transaction. Once the transaction is over,
>> you can do as much I/O as you like.
>
> Right. But if "fetch the transaction" means "obtain it from the server
> over there using TCP/IP", then you're kind of screwed, aren't you?

Yeah. STM only works for stuff local to one machine.

Or rather, the implementations I've seen only work local to one machine. 
It's quite plausible you could extend it so that the transactional data 
you're mutating might be remote - but them it would be the STM engine 
sending network traffic, not you.

> Heck, even a regular expression match isn't functional in .NET.

Probably. In fact, I doubt much of the .NET libraries are. So you would 
probably end up using existing Haskell libraries for anything except 
actual I/O - the thing that .NET is good at.

>> The problem (I assume) that you're talking about is that all the existing
>> .NET stuff is structured under the assumption that you can do I/O
>> whenever
>> you feel like it. I can see a few ways to approach that. (Perhaps the
>> simplest possibility being "only Haskell is allows to use STM". :-P )
>
> And that's the kind of incompatibility I'm saying makes .NET much less
> useful.

Certainly it makes it less useful, yes. Whether it makes it "not worth 
it at all" is more open to debate.

Post a reply to this message