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