Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Wasn't O'Caml a functional language?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-09-21 (23:38)
From: Alessandro Baretta <alex@b...>
Subject: Re: [Caml-list] Wasn't O'Caml a functional language?

John Gerard Malecki wrote:
> I don't see any side effects in Queue.iter?  Here is the code

Neither do I. I probably just need to retire to buddhist 
monastery in Nepal. Here is the quote from the manual:

* iter f q applies f in turn to all elements of q, from the
* least recently entered to the most recently entered. The >
* queue itself is unchanged.

> Can you better describe the problem?  (Maybe what you're saying is
> that if f is side-effecting then iter acts perversely.)

I sure can: it's just a vast degenerative neurological 
disease. Sorry, my mistake, the side-effect is not in 
Queue.iter. It is in Queue.transfer, which I happen to use 
somewhere down the road in the control flux of the function 
I apply to the Queue. The fact that the main data structure 
in my program has type "data_elem Queue.t Queue.t Queue.t" 
adds to the confusion. The iterator giving me trouble is the 
one acting at the central Queue.t level, and the unwanted 
side_effects are situated at the lower level of nesting 
(data_elem Queue.t).

Anyway, my main claim, although misdirected, in not entirely 
faulty. Queue.transfer can be thought of as analogous to 
List.append. When I write let list = list1 @ list2 I do not 
expect side-effects on list1 or list2.

My most sincere apologies for my previous encephalitic post.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: