Re: "ocaml_beginners":: alternating interactive and compiled modes
- I agree on everything, but there is a strong reason for "global refs" in
ocaml; in a functional-featured language, where lambda calculus takes charge
gently of a number of states, not only refs are strictly speaking a
nonfunctional element, but using refs for *local* scopes is seldom useful.
So in all the code that I've seen so far, except some in the Pcre library,
refs are used for higher scopes and correspond generally to low-dynamics
variables. It looks like there is a kinship between refs and global scope,
1.I use refs for hand modifications (generally imperative) and when I can't
use automatical management of things, and when a small number of states of
the variable are involved.
2.I use global-scoped variables either for inits or for general environmental
infos, that have low dynamics.
That's how comes that -no matter what theories are- in this
functionalimperativobjective language I use *global refs* more often than
local refs and global nonrefs. It's a matter of how do you roll your own mix
of programming styles, I believe. I often consider Ocaml as an imperative
environment with functional functions... it should be time for studying OO!!
Il Friday 06 December 2002 10:55, Gianluca Moro ha scritto:
> --- In ocaml_beginners@y..., Stalkern 2 <stalkern2@t...> wrote:
> > > Anyone know why this is a ref? Why would someone want to change it?
> > IMHO it's normal, nobody could change it at runtime (either you're
> > or not, it depends on how is the program started) so why bother with
> > it as something that could have a local scope (such as non-refs).
> > It has a global scope and ref items are the ultimate choice for
> global scope.
> Just my point of view about scope and ref:
> the (static) scope of a variable is that piece of code
> where a variable is defined and accessible, and obviously
> we can, in general, speak of the scope of every item we
> use, variable, function or what you want.
> This is a very useful way to keep your code clean and ordered.
> A ref item is something I want to change runtime and inplace.
> As a matter of fact in a pure functional language, such a
> thing should not exist.
> A ref, as any other object, have his scope: I can define
> a global ref, a local ref, and so on...
> This is a very useful way to make your code ununderstandable.
> Tipically, my rule of thumb, is that whenever I use a ref
> is to manage some function side-effect, a thing not very
> clean, and that can easily bring to an unmanageable code,
> for this reason I try to use as few as possible refs, and
> to have them the more local possible.
> For this reason I try to avoid global refs, as it is
> easy to get lost in side-effects: and just for fun, we
> can say that refs for global scope, more than "the ultimate choice"
> is "l'ultima scelta" (for not italian speaking "the last choice")
> Anyway, just to conclude seriously, the scope is not connected
> in any way with the fact of having a ref or not ref items.
> And going back to the original question, a variable that
> never change, in my opinion too should not be a ref.
- --- In ocaml_beginners@y..., Stalkern 2 <stalkern2@t...> wrote:
> I agree on everything, but there is a strong reason for "globalrefs" in
> ocaml; in a functional-featured language, where lambda calculustakes charge
> gently of a number of states, not only refs are strictly speaking auseful.
> nonfunctional element, but using refs for *local* scopes is seldom
In italian I will say "se c'e' fantasia, non c'e' limite alle porcate
che ci si puo' inventare", that is, you can find an application
for everything, even for the more unuseful things: yes, the main use
for the ref is as globals, even in my code, but sometimes I use
them to store local states too, anyway, as you say, just a question
An example of local ref can be the following: the idea, for
C-coders, is to have a static variable in a function, that is
a variable whose scope is local to a function, but whose
value is keeped from call to call:
let myFunction =
let lastX = ref 0.0 in
(fun x ->
(* blablablathatisdosomething; *)
Printf.printf "LastX=%f, currentX=%f\n" !lastX x;
lastX := x;
val myFunction : float -> unit = <fun>
In this way, I have a local variable, which can be seen
just in myFunction, but whose life is extended to the
all program life.
By the way, I agree too, that everything is a question of style:
one could implement such a thing with in continuation passing style
with no refs.
> of programming styles, I believe. I often consider Ocaml as animperative
> environment with functional functions... it should be time forstudying OO!!
> ;-))What!?!? you are completely wrong! Ocaml is a functional
language with imperative extensions!!!! :-)
And by the way, I wrote some small application in OO (using C),
but I don't like this style at all: you can always model
your ideas as if everything were an object, but sometime
such a paradigma is good for your application, some others
no: the same when you want to write a completley (pure)
functional program, or a completely continuation passing
style program: in some occcasion the model makes your
programming much easier, sometimes make it much harder.
Models are a good thing, until you adapt the models
to reality and not reality to models.