[mercury-users] purpose... ...string__set_char ...

[Nancy Mazur]

* Noel  Pinto <cool4life at rediffmail.com> [2002-11-15 16:34]:
> Hi,
> 
> string__set_char is defined as...
> 
> :- pred string__set_char(char, int, string, string).
> :- mode string__set_char(in, in, in, out) is semidet.
> % XXX This mode is disabled because the compiler puts constant
> % strings into static data even when they might be updated.
> %:- mode string__set_char(in, in, di, uo) is semidet.
> %	string__set_char(Char, Index, String0, String):
> %	`String' is `String0' with the (`Index' + 1)-th character
> %	set to `Char'.
> %	Fails if `Index' is out of range (negative, or greater than or
> %	equal to the length of `String0').
> 
> 1) Why has the character be set for String with refernce to 
> String0??
> 2) Shouldn't it be possible to just separate them in two 
> substrings and use them??
> 3) Is it not just wasting memory, when a string is set to a 
> particular index and the string still had the value before the 
> index??

I don't understand what you are writing here,... where do you see that a
string is set to a particular index? 

Anyway, the purpose of set_char(Char, Index, S0, S) is to generate a new
string S from an old string S0, where the only difference between these two
strings is that the character at position "Index" is now the character
"Char".

Wasting memory? Don't forget that you're learning a "declarative"
language here. And that you cannot simply "change" values as you're 
(perhaps) used to in imperative languages (such as C, Java or others). 
This means that set_char cannot change the old string (it is not allowed
to in a declarative context). It can only return you a new string with
some changes with respect to the original string. 
As a programmer in imperative languages this might seem indeed as a
waste of memory if you know that you don't need the old situation of the
string anymore. Have faith in the compiler and the runtime system, and
leave the memory issues to them... don't bother with memory yourself...
focus on your problem domain, not on memory issues... 

Nancy

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------