Invisible <voi### [at] devnull> wrote:
> > If I'm not mistaken, for example assignment produces a side-effect.
> > Even I/O causes side-effects.

> Assignment and I/O are both side-effects. Accessing an indexed array 
> does not. There is absolutely no reason why a pure functional language 
> cannot have arrays.

  Are you telling me in Haskell you can't modify the contents of an array
in-place? (By "indexable array" I implied that it can be assigned to,
although I should have perhaps stated it more explicitly.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>>> If I'm not mistaken, for example assignment produces a side-effect.
>>> Even I/O causes side-effects.
> 
>> Assignment and I/O are both side-effects. Accessing an indexed array 
>> does not. There is absolutely no reason why a pure functional language 
>> cannot have arrays.
> 
>   Are you telling me in Haskell you can't modify the contents of an array
> in-place? (By "indexable array" I implied that it can be assigned to,
> although I should have perhaps stated it more explicitly.)

Haskell provides a kind of array that you cannot modify in-place. (It's 
useful e.g. for pre-computed lookup tables.)

Haskell also provides another kind of array which can be modified 
in-place in the same sense that files can be written to - i.e., your 
program returns a set of instructions to the runtime that says "hey, 
create this array and modify its contents like this". Which makes sense 
really. After all, what is a "file"? It's a named array of bytes that 
can be modified [and reised] in-place! :-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Haskell also provides another kind of array which can be modified 
> in-place in the same sense that files can be written to - i.e., your 
> program returns a set of instructions to the runtime that says "hey, 
> create this array and modify its contents like this". Which makes sense 
> really. After all, what is a "file"? It's a named array of bytes that 
> can be modified [and reised] in-place! :-D

  Somehow I get the feeling that means:

  1) If you want to make a program which does some efficient calculations
using arrays, you have to jump through many useless hoops.

  2) Haskell is not pure regardless.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Somehow I get the feeling that means:
> 
>   1) If you want to make a program which does some efficient calculations
> using arrays, you have to jump through many useless hoops.
> 
>   2) Haskell is not pure regardless.

Well, you've seen code that does it, so you can see it's really not that 
hard. And the "hoops" are precisely what *makes* Haskell pure. To my 
mind, that makes them not "useless". Still, it is only to my mind... 
obviously what is or is not useful is in the eye of the beholder.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >   Perhaps a bit surprisingly, Microsoft even has some open-source
> > projects, under OSI-compliant licenses. For example:
> > http://en.wikipedia.org/wiki/Windows_Template_Library

> I know. There's also WiX, a free toolset to make MSI-based installers 
> from XML configuration files. Released under the Common Public License.

> And probably many others.

  I just find this rather surprising, considering that they CEO considers
open source software a cancer and communism.

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
>   I just find this rather surprising, considering that they CEO considers
> open source software a cancer and communism.
> 

"We're open-source friendly!" might be good marketing. Even though they 
really aren't.

Post a reply to this message

On Fri, 15 Feb 2008 16:51:17 -0200, Nicolas Alvarez wrote:

> Warp escribió:
>>   I just find this rather surprising, considering that they CEO
>>   considers
>> open source software a cancer and communism.
>> 
>> 
> "We're open-source friendly!" might be good marketing. Even though they
> really aren't.

Well, arguably they have an interoperability lab that they run with 
Novell (again, that's who I work for, so I'm perhaps biased - though I 
really do dislike Windows and pretty much always have - I preferred 
Desqview when it was around).

They're also working with the SAMBA team now.

So it seems that some things are changing, finally.

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> They're also working with the SAMBA team now.

yeah, they probably want some hints at how to correctly handle their spec.  Not
first time it happened.

But truth be told, M$ only said GPL was a cancer, not general opens-source
software.  It's understandable.  They certainly would feel a lot happier to
just integrate BSD-covered code into their products without much legal fuss.
hey, more people working for free for their glory...

Post a reply to this message

On Fri, 15 Feb 2008 15:59:49 -0500, nemesis wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> They're also working with the SAMBA team now.
> 
> yeah, they probably want some hints at how to correctly handle their
> spec.  Not first time it happened.

Possibly.  But the SAMBA team agreeing to work with them is a significant 
thing as well, because they were so outspoken over the Novell/Microsoft 
agreement.  I mean, Jeremy Allison quit Novell over that deal.

> But truth be told, M$ only said GPL was a cancer, not general
> opens-source software.  It's understandable.  They certainly would feel
> a lot happier to just integrate BSD-covered code into their products
> without much legal fuss. hey, more people working for free for their
> glory...

Well, they've used a fair bit of BSD code already; their TCP/IP stack 
reportedly comes from the BSD implementation.

Jim

Post a reply to this message

Jim Henderson escribió:
> Well, they've used a fair bit of BSD code already; their TCP/IP stack 
> reportedly comes from the BSD implementation.
> 

And also reportedly, they rewrote the whole TCP/IP stack for Vista. Lots 
of bugs reappeared (like many that had been fixed in Windows 95, ping of 
death anyone?).

Post a reply to this message

On Fri, 15 Feb 2008 19:13:55 -0200, Nicolas Alvarez wrote:

> Jim Henderson escribió:
>> Well, they've used a fair bit of BSD code already; their TCP/IP stack
>> reportedly comes from the BSD implementation.
>> 
>> 
> And also reportedly, they rewrote the whole TCP/IP stack for Vista. 

Huh, I hadn't heard that.

> Lots
> of bugs reappeared (like many that had been fixed in Windows 95, ping of
> death anyone?).

Great....

Jim

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> And also reportedly, they rewrote the whole TCP/IP stack for Vista.

good code is old code.  passed the test of time.

good for them.

Post a reply to this message

Jim Henderson escribió:
>> Lots
>> of bugs reappeared (like many that had been fixed in Windows 95, ping of
>> death anyone?).
> 
> Great....

...bugs that were of course fixed long before the final Vista release! I 
thought I'd better clarify that :)

http://www.grc.com/SecurityNow.htm#51

Post a reply to this message

On Fri, 15 Feb 2008 19:46:10 -0200, Nicolas Alvarez wrote:

> Jim Henderson escribió:
>>> Lots
>>> of bugs reappeared (like many that had been fixed in Windows 95, ping
>>> of death anyone?).
>> 
>> Great....
> 
> ...bugs that were of course fixed long before the final Vista release! I
> thought I'd better clarify that :)
> 
> http://www.grc.com/SecurityNow.htm#51

Yeah, I understood that, but it seems that some didn't. :-)

Jim

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>  Why not disallow diamond inheritance? 
> 
>> Technically, you can't, since there's a common base type for all objects 
>> in those languages.
> 
>   No, there isn't: The so-called "interfaces" are not inherited from the
> common base class.

Interfaces aren't objects. They're types.

The rest snipped, because I agree with you. I'm not saying MI is 
especially hard to get right. I'm just saying you can't disallow diamond 
inheritance in a language where everything inherits from the same base 
class.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> One really has two choices: Run different versions of the runtime and 
>> use up those resources, or have DLL hell where upgrading the runtime 
>> breaks working programs. The "upgrade the runtime and maintain 100% 
>> backward compatibility" eventually turns into a nightmare.
> 
>   Third choice: Design the system so that you don't *have* to upgrade
> ever. ;)

That's really bad for a commercial company. ;-)

Seriously, lots of systems do that. You upgrade by throwing away the 
entire old system and buying a new one.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> It also offered a way to 
>> access Microsoft functionality from within Java.
> 
>   Isn't that precisely breaking standards?

No. Is providing OpenGL breaking the ANSI C standard?

>   If Microsoft's version of Java didn't break any Java specifications,
> how come Sun sued and won?

The same reason Alcoa lost their anti-trust case?

The fact that some company loses an anti-trust case says nothing about 
their behavior, in the USA. One of the first lawsuits under the Sherman 
anti-trust act was against Alcoa Aluminum company. They lost, not 
because they did anything wrong, but because the judge said "if you have 
most of the customers, you must be doing something wrong."

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Invisible wrote:
> Depends. How good are the .NET libraries? [I hope to God they're better 
> than the Java ones!]

They're actually surprisingly good for what they do. Far, far better 
than the Java stuff. Much of the Java stuff was designed to be 
oh-so-flexible, with three or four layers of abstraction between 
"socket" and "network connection", for example, so much so that it's 
almost unusable. It might have been worthwhile if people actually wrote 
code that was as flexible as the specs, but that never happened either.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Invisible wrote:
>>> ....so they implemented Java's flawed MI-but-not-MI model? How is that 
>>> fixing the flaws from other major programming languages?
> 
>> Probably fixing what they saw as flawed MI in C++. :-)
> 
>   They "fixed the problems" by removing multiple inheritance completely?

I just want to clarify the smiley-face means I was being at least 
somewhat sarcastic.

>   Maybe MI in C++ has some problems. I has never stopped me from using
> MI in C++ efficiently and for really useful stuff, though.

Remember that C# also allows reflection, dynamic loading of precompiled 
libraries, and runtime code generation, as well as supporting a couple 
dozen other languages. All of this might have some effect on the decisions.

>   Without this possibility each program would have to be statically linked
> with all the system libraries, and thus the same system libraries would be
> loaded into memory multiple times. If there's eg. a huge library used by all
> programs, it would be loaded to memory as many times as there are programs
> running.)

It depends. Some systems had non-dynamic loadable libraries that were 
indeed shared between programs using them. They just got linked at 
specific addresses. (I think Multics did this, IIRC.) For example, on 
the first mainframe I used, the fortran library was at 0x1FF00 or 
something like that. When you started a program that needed the fortran 
runtime, it got mapped into your address space.

I.e., "linked" but not "dynamically under programmer control".

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Depends. How good are the .NET libraries? [I hope to God they're 
>> better than the Java ones!]
> 
> They're actually surprisingly good for what they do. Far, far better 
> than the Java stuff.

That's not hard. :-S

> Much of the Java stuff was designed to be 
> oh-so-flexible, with three or four layers of abstraction between 
> "socket" and "network connection", for example, so much so that it's 
> almost unusable. It might have been worthwhile if people actually wrote 
> code that was as flexible as the specs, but that never happened either.

Tell me, have *you* ever seen a non-empty catch{} block in Java? ;-)

BTW, I especially love the way Java, an "object oriented language", uses 
lots of procedural techniques in it's class library. Neat...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   Because it's not a feature of the functional programming paradigm,
>> but the imperative programming paradigm.
> 
> Huh?  Since when?  I think you're mistaken here, but I'm happy to learn 
> otherwise.

As posted elsewhere, what Warp *really* means is "arrays with in-place 
update". Which *is* strictly speaking against functional style. (But 
that doesn't stop you using it even in a pure functional language such 
as Haskell...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
>   A purely functional programming language doesn't have side-effects.

The trick is to embed the purely functional programming language into a 
larger system that does the I/O. For example, have a CGI script that 
takes its input and generates output from that functionally, and let the 
web server do the I/O part.  POV-Ray could be purely functional, except 
for a small shell that reads the input file into a buffer (ignoring 
includes and such) and another that takes the calculated pixels and 
outputs them to the destination file.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Orchid XP v7 wrote:
> Tell me, have *you* ever seen a non-empty catch{} block in Java? ;-)

Only in my own code. ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> As posted elsewhere, what Warp *really* means is "arrays with in-place 
> update". Which *is* strictly speaking against functional style. (But 
> that doesn't stop you using it even in a pure functional language such 
> as Haskell...)

  Well, modifying an array in-place means it's a side-effect, which
means Haskell is not pure.

  OTOH, why would that be a bad thing? Just being "pure functional" for
the sake of being pure is counter-productive. There are many situations
where being able to handle arrays in-place is more or less mandatory
for efficiency. Trying to avoid it would sometimes be more awkward than
would be worth.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   Without this possibility each program would have to be statically linked
> > with all the system libraries, and thus the same system libraries would be
> > loaded into memory multiple times. If there's eg. a huge library used by all
> > programs, it would be loaded to memory as many times as there are programs
> > running.)

> It depends. Some systems had non-dynamic loadable libraries that were 
> indeed shared between programs using them. They just got linked at 
> specific addresses. (I think Multics did this, IIRC.) For example, on 
> the first mainframe I used, the fortran library was at 0x1FF00 or 
> something like that. When you started a program that needed the fortran 
> runtime, it got mapped into your address space.

> I.e., "linked" but not "dynamically under programmer control".

  That still doesn't solve the problem of virtual inheritance being
either always-on or always-off for a class in a precompiled library,
without any possibility of changing it on a per-program basis.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   OTOH, why would that be a bad thing? 

You lose a whole bunch of things the compiler can optimize.

If you do
   "let x = replace offset 27 in y with 'hello'"
(i.e., y[27]='hello')
and then use "x", the compiler can often figure out that y isn't used 
any more and update it in place.

Sort of like using tail recursion instead of iteration, but they're both 
equivalent.  Or avoiding loops in APL. Or avoiding cursors in SQL.

And yes, sometimes (often, for me) it gets awkward. You sometimes have 
to spend some time figuring out how to do it functionally, but it gets 
easier with practice.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
>   That still doesn't solve the problem of virtual inheritance being
> either always-on or always-off for a class in a precompiled library,
> without any possibility of changing it on a per-program basis.

I'm not sure what "virtual inheritance" means outside the very narrow 
context of C++. And inside that context, I'm not sure I understand what 
problem it's supposed to be solving.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   That still doesn't solve the problem of virtual inheritance being
> > either always-on or always-off for a class in a precompiled library,
> > without any possibility of changing it on a per-program basis.

> I'm not sure what "virtual inheritance" means outside the very narrow 
> context of C++. And inside that context, I'm not sure I understand what 
> problem it's supposed to be solving.

  Virtual inheritance is related to diamond inheritance.

  Any OOP language which supports multiple inheritance, and consequently
diamond inheritance, must resolve the problem in one way or another.
Virtual inheritance in C++ is one solution.

  When you use virtual inheritance in diamond inheritance situations,
the base class appears in the object only once, and all the derived
objects use that one single instance of the base class object (instead
of each using their own).

  Naturally this requires that all the access to the base class members
be indirect. They cannot be accessed directly but only through a vtable.
Since having to access all member variables indirectly would be a
completely useless overhead in non-diamond-inheritance situations, this
is not done by default.

  The problem is that classes derived from a common base class need to
make the decision of whether they will use virtual inheritance or not.
Using virtual inheritance will allow diamond inheritance with a common
base class. However, if this is not needed, then virtual inheritance
would be completely useless overhead.

  When these derived classes are in a precompiled library which cannot
be changed, the decision cannot be changed either. They either use
virtual inheritance (allowing diamond inheritance with a single base
class) or they don't. If they don't, and you would need it, bad luck.

  That's the reason why precompiled libraries sometimes may introduce
problematic situations.

  Fortunately it's rare to need to use diamond inheritance in the first
place (and in many cases where diamond inheritance is needed, the common
base class isn't). Thus the problem appears quite rarely.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   When you use virtual inheritance in diamond inheritance situations,
> the base class appears in the object only once,

So lacking "virtual inheritance" means there's one copy of the 
superclass for each subclass that has it on its parent chain? OK.

> Since having to access all member variables indirectly would be a
> completely useless overhead in non-diamond-inheritance situations, this
> is not done by default.

It sort of sounds like this would be just the thing for a runtime with 
JIT to deal with, wouldn't it? I.e., it sounds like this is even easier 
to solve in .NET than in C++, because the actual code isn't generated in 
.NET until the thing is actually linked together at runtime?

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> As posted elsewhere, what Warp *really* means is "arrays with in-place 
>> update". Which *is* strictly speaking against functional style. (But 
>> that doesn't stop you using it even in a pure functional language such 
>> as Haskell...)
> 
>   Well, modifying an array in-place means it's a side-effect, which
> means Haskell is not pure.

For the Nth time: All side-effects are technically outside the language 
itself, and hence Haskell is not impure.

For example, in Lisp, if you have a list, usually you update it by 
constructing a modified copy. But, if you feel like it, you can just go 
"ah well, I can't be bothered" and modify a list (or any other data 
structure) in-place. In Haskell, you cannot do this.

[Since you can call C from Haskell, you can tell the compiler "hey, this 
C function has no side effects" when actually it does. But there's not 
really anything the Haskell language spec can do about that... And if 
you try this, Bad Things happen.]

>   OTOH, why would that be a bad thing? Just being "pure functional" for
> the sake of being pure is counter-productive.

Remember how in Haskell code executes in arbitrary order?

Now mix that up with side-effects. Go on. See what kind of a mess you 
end up with. Hint: it won't be pretty. ;-)

Haskell is able to execute things in arbitrary order (and possibly not 
execute things at all, and possibly execute many things in paralle 
transparently, and...) precisely *because* it is a pure language. And 
that's to say nothing about the optimisation possibilities offered to 
the compiler.

You make it sound like purity is just some arcane concept invented by 
mathematicians that serves no practical purpose. ;-)

> Trying to avoid it would sometimes be more awkward than
> would be worth.

Sometimes, yes. And this is partly why Haskell offers you a way to 
indirectly perform various side-effecting operations such as in-place 
array updates (not to mention file I/O etc.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > Since having to access all member variables indirectly would be a
> > completely useless overhead in non-diamond-inheritance situations, this
> > is not done by default.

> It sort of sounds like this would be just the thing for a runtime with 
> JIT to deal with, wouldn't it?

  And then you lose the advantage of shared libraries because each library
would have to be JIT-compiled for each program which uses it. Which was
the whole point.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   And then you lose the advantage of shared libraries because each library
> would have to be JIT-compiled for each program which uses it. Which was
> the whole point.

Well, I think JIT-compiled code is easier to compile than C#, for 
example. But yeah, the actual executable bytes would be different for 
each process running, or at least each program, if that's what you're 
trying to avoid.

I suppose you could also have two copies of the code in each library, 
one with and one without. Doubles the size somewhat of any routine that 
is affected by that. Select the right set of routines when you start up 
the program, or when you link the child class, or some such? I'm not 
sure when you'd pick in this case.

-- 
   Darren New / San Diego, CA, USA (PST)
     On what day did God create the body thetans?

Post a reply to this message