From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 2C6857EE51 for ; Sat, 25 May 2013 13:05:00 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=pra; client-ip=192.109.42.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=mailfrom; client-ip=192.109.42.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@einhorn.in-berlin.de) identity=helo; client-ip=192.109.42.8; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="postmaster@einhorn.in-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwCAPOZoFHAbSoIlGdsb2JhbABahnO5VIUngQYWDgEBAQEJCwkJFAQkgiMBAQUjVhALCQ8CAgUhAgIPBRgxE4gNBKorkVMWgRCNdweCQTJhA48HiDOUUg X-IPAS-Result: ApwCAPOZoFHAbSoIlGdsb2JhbABahnO5VIUngQYWDgEBAQEJCwkJFAQkgiMBAQUjVhALCQ8CAgUhAgIPBRgxE4gNBKorkVMWgRCNdweCQTJhA48HiDOUUg X-IronPort-AV: E=Sophos;i="4.87,740,1363129200"; d="scan'208";a="18948923" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2013 13:04:59 +0200 X-Envelope-From: oliver@first.in-berlin.de Received: from first (e178019102.adsl.alicedsl.de [85.178.19.102]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id r4PB4vZh016010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 May 2013 13:04:58 +0200 Received: by first (Postfix, from userid 1000) id AB242154066B; Sat, 25 May 2013 13:04:57 +0200 (CEST) Date: Sat, 25 May 2013 13:04:57 +0200 From: oliver To: Wojciech Meyer Cc: Siraaj Khandkar , Arnaud Spiwack , OCaML Mailing List Message-ID: <20130525110457.GA1947@siouxsie> References: <20130523235355.GI6510@siouxsie> <20130524233015.GE1923@siouxsie> <37A1A2D3-5993-4675-9937-ED3965793D1D@khandkar.net> <20130525004045.GH1923@siouxsie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: [Caml-list] OCaml's variables Hello, but the that argument also holds true for other lists. They are finite, but every element of the posisble holds a new value. But the name for a list binds to that list, not to individual values. That they are recursive in the case of page 136 does not change this. Finite lists hold finite number of posisbly different values. Infinite lists hold infinite number of possible different values. I see no reason, why the finite list must be seen as key-value binding, but the infinite list can be seen as variable. Once the name is bound to both these kinds of lists, they don't change. Compared to this, a reference would have more entitlement to be seen as "variable". Ciao, Oliver On Sat, May 25, 2013 at 06:14:11AM +0100, Wojciech Meyer wrote: > Dear Oliver, > > Well, the variable does not mean that the value can vary over the > time, but rather that it means that it and can be defined over the > set of (possibly) infinite different values. > > So the term variable is fully valid and justified. > > oliver writes: > > > On Fri, May 24, 2013 at 07:53:33PM -0400, Siraaj Khandkar wrote: > >> > >> On May 24, 2013, at 7:30 PM, oliver wrote: > >> > >> > On Fri, May 24, 2013 at 11:01:39AM +0200, Arnaud Spiwack wrote: > >> >> Why were you astounded? This is a perfectly legitimate/correct > >> >> use of the > >> >> word "variable". > >> > [...] > >> > > >> > > >> > Do you think so? > >> > > >> > I have thought about making the sentence better, but did not found > >> > a better sentence in short time. > >> > > >> > But name-value-binding is the term that is used in functional languages. > >> > I wonder why the term "variable" pops up there. > >> > And even I understood the sentence, I'm not sure if this might > >> > create confusion > >> > to some readers, because the term "variable" is normally not used > >> > for functional languages. > >> > > >> > People new to FP will be said, there are no "variables", and then > >> > they maybe > >> > will be irritated, if they find that term in a reference-manual. > >> > > >> > Do you see what I mean? > >> > >> If you think of functions as equations, non-constant values are variables. > > [...] > > > > Where do the non-constant values come from? > > I don't see there non-constant values. > > > > Even a referemce, where the value is mutable, is represented > > as a name-binding to the reference (container). > > But in the chapter on page 136 it's about recursive values. > > > > That does not mean the values are mutable. > > > > So I wonder, why the term variables might be ok there. > > > > Why is on the one hand emphasized, that there are name-value bindings, > > on the other hands variables are the right term? > > > > Or am I too picky? > > Or has my mind be infected at the time > > when I looked at Haskell and it's pureness? > > > > > > Ciao, > > Oliver > > -- > Wojciech