Darren New wrote:
> Invisible wrote:
>>>> But alas, it's not purely functional,
>>>
>>> Yeah. I don't think you could get a real distributed language with 
>>> everything being truly functional, could you?
>>
>> Um... why?
> 
> Because it's nondeterministic? It's I/O driven? It's asynchronous?
> 
> I mean, to the extent that you think a tail-recursive function accepting 
> asynchronous messages and sending asynchronous messages in return can be 
> "functional," then it looks like Erlang is functional.

Haskell supports random number generators. And I/O. And asynchronous 
exceptions. It just cleanly seperates what *is* deterministic from what 
is *not*, that's all. ;-)

>>> I mean, what's the functional equivalent of "the machine running the 
>>> calculation just burst into flames"? :-)
>>
>> Throwing an exception, as a guess. Like a division by zero error, but 
>> less deterministic. (??!?!) ;-)
> 
> Who throws the exception? The machine running the calculation isn't in 
> any shape to do so.

I would presume the exception is just thrown to whoever is waiting for 
the answer?

>>> What's the functional equivalent of "we've just released a new 
>>> version of this function"?
>>
>> Now that's an interesting question...
> 
> Let me know when you figure it out. ;-)

To be honest, I'm not really seeing a clean way to handle this in *any* 
language, but I haven't thought about it for that long yet.

>> If by "simple and straight forward" you mean "assumes referential 
>> transparency but doesn't actually enforce it or make any attempt to 
>> check that it's there", then sure. Go knock yourself out. ;-)
> 
> Where do you think it doesn't assume referential transparency?

Please reparse my sentence. I said it *does* assume referential 
transparency yet does nothing to *enforce* or even *check* for it.

In other words, if you're not careful, you can easily cause the system 
to massively malfunction with a few incautiously chosen commands.

> By "simple and straightforward" I meant in the sense that there are 
> relatively few types and primitives and interactions between them. More 
> like Tcl or C than Ada or C++.

I consider Haskell to be quite simple in this respect too. Until you 
start digging things up out of the standard libraries, the language 
itself gives you lists, tuples, integers, reals, booleans, characters, 
and that's more or less it. And the language is nearly devoid of 
keywords. (Decide for yourself if that's good or bad.)

>> Gotta love documentation where you can't figure out what order to read 
>> it in...
> 
> It's not unusual. It's how I learned most of the languages I know. But 
> then, most of the languages I learned that way didn't have 1500+ pages 
> of documentation for the libraries. :-)  A two-pass read of the library 
> docs is going to take a while.

I'm looking at you, Oracle. Trying to figure out where to start reading 
to actually comprehend this stuff is *far* too hard!

It's not that Oracle is hard to understand - just that the [multiple] 
manuals explain it quite poorly.

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

Post a reply to this message