RE: [Caml-list] a reckless proposal

RE: [Caml-list] a reckless proposal

[Dave Berry]

> From: Miles Egan [mailto:miles@caddr.com]
> Sent: 24 July 2001 19:08
> 
> Records are confusing because they resemble C
> structs and are used in similar ways, but are really quite 
> different.  Objects are confusing because their use is mildly
> discouraged and because their functionality significantly
> overlaps that of the module system.
> 
> The most frustrating feature of records, of course, is that 
> each record field name must be globally unique.  Objects seem
> to provide more struct-like semantics, i.e. field names need
> only be unique within their class definition.

So perhaps Ocaml should adopt the approach used in Dylan and Moby,
where field names in class definitions have module scope.  Then
records and objects would have similar scoping rules, instead of
the current clash, and the distinction between modules and objects
would be clearer.

> For example, if object
> fields were directly accessible by default, one could use:
> 
> class point =
>   object
>     val x = 0
>     val y = 0
>   end
> 
> and access p.x and p.y directly, 

But if you then replace the field with an accessor method, you
have to edit all uses of that field.  It's a common recommendation
that OO languages should only access field by accessor methods (or
at least use the same syntax as accessor methods).  As you point
out, Ruby does it this way.  Dylan and Eiffel are other examples.

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Miles Egan]

On Wed, Jul 25, 2001 at 10:30:09AM +0100, Dave Berry wrote:
> So perhaps Ocaml should adopt the approach used in Dylan and Moby,
> where field names in class definitions have module scope.  Then
> records and objects would have similar scoping rules, instead of
> the current clash, and the distinction between modules and objects
> would be clearer.

I suppose this is also similar to CLOS generics, right?  I suppose this would be
more consistent but perhaps even more confusing to people who've been writing
ClassA.field and ClassB.field since the first day of their first Java class.

> But if you then replace the field with an accessor method, you
> have to edit all uses of that field.  It's a common recommendation
> that OO languages should only access field by accessor methods (or
> at least use the same syntax as accessor methods).  As you point
> out, Ruby does it this way.  Dylan and Eiffel are other examples.

Ocaml could observe this protocol as well.  This is valid code:

class a =
  object
    val x = 1
    method x = x
  end

let _ = new a in
  a#x

So a "macro" like attr_r could transform:

class a =
  object
   attr_r x = 1
  end

into the above class definition.

Of course, you won't be able to assign to x in the way you'd expect:

let _ = new a in
  a#x = 2

Won't work.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Bruce Hoult]

At 8:35 AM -0700 26/7/01, Miles Egan wrote:
>On Wed, Jul 25, 2001 at 10:30:09AM +0100, Dave Berry wrote:
>>  So perhaps Ocaml should adopt the approach used in Dylan and Moby,
>>  where field names in class definitions have module scope.  Then
>>  records and objects would have similar scoping rules, instead of
>>  the current clash, and the distinction between modules and objects
>>  would be clearer.
>
>I suppose this is also similar to CLOS generics, right?  I suppose 
>this would be more consistent but perhaps even more confusing to 
>people who've been writing ClassA.field and ClassB.field since the 
>first day of their first Java class.

Sorry to reply to this a couple of days late, but I was preoccupied 
with a certain programing contest...

Yes, the Dylan object system is extremely similar to CLOS.  But the 
language provides just a little syntactic sugar so that instead of 
"field(object)" (or "(field object) in Lisp") you can also write 
"object.field".  Also, instead of field-setter(newVal, object) you 
can write object.field := newVal.  And a similar syntax 
correspondence for "a[i]" and "a[i] := b" which expand to calls to 
element() and element-setter().

A needless inconsistency compared to the simplicity and power of pure 
S-expressions, for sure, but one that as a Pascal and C/C++ and Java 
programmer I find very comfortable.

-- Bruce
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] a reckless proposal

[Miles Egan]

It seems that two of the things that most confuse or frustrate new users of
ocaml are records and objects.  Records are confusing because they resemble C
structs and are used in similar ways, but are really quite different.  Objects
are confusing because their use is mildly discouraged and because their
functionality significantly overlaps that of the module system.

The most frustrating feature of records, of course, is that each record field
name must be globally unique.  Objects seem to provide more struct-like
semantics, i.e. field names need only be unique within their class definition.
Using objects in place of records is a bit clumsy, however, because object
fields require accessors.  If the rules for object field access were changed,
however, objects would be just as convenient as records and less confusing and
more comfortable to C/C++/Java/Python programmers.  For example, if object
fields were directly accessible by default, one could use:

class point =
  object
    val x = 0
    val y = 0
  end

and access p.x and p.y directly, which would be in almost all ways preferrable
to using a record type which would make it impossible to define another type
with fields named x or y.

Alternatively, ocaml could offer ruby-style accessor macros, where a definition
like:

class example =
  object
    attr_rw x = 0
    attr_r  y = 0
    attr    z = 0
  end

would automatically generate get_x and set_x methods for x, a get_y method for
y, and no methods for z.  I suppose you could implement this in camlp4, but I
think features like this would have to be included in core ocaml before they'd
really be used.  Records could even be deprecated if this were implemented.

This approach has, in my mind, two advantages:
1. The object system becomes more generally useful.
2. A confusing and non-orthogonal feature of ocaml is subsumed into
   another, more generally useful and flexible feature.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Brian Rogoff]

On Tue, 24 Jul 2001, Miles Egan wrote:

> It seems that two of the things that most confuse or frustrate new users of
> ocaml are records and objects.  Records are confusing because they resemble C
> structs and are used in similar ways, but are really quite different.  Objects
> are confusing because their use is mildly discouraged and because their
> functionality significantly overlaps that of the module system.
> 
> The most frustrating feature of records, of course, is that each record field
> name must be globally unique.

Correction/amplification: not globally unique, but unique in a module. 

>  Objects seem to provide more struct-like
> semantics, i.e. field names need only be unique within their class definition.
> Using objects in place of records is a bit clumsy, however, because object
> fields require accessors.  If the rules for object field access were changed,
> however, objects would be just as convenient as records and less

No, they'd still be *much* less convenient than records, since you can't
pattern match on objects. 

Classes and types can't be in a recursive relationship either (though
there are things you can do with row types here to ease this...). 

> confusing and more comfortable to C/C++/Java/Python programmers.  For example, if object
> fields were directly accessible by default, one could use:
> 
> class point =
>   object
>     val x = 0
>     val y = 0
>   end
> 
> and access p.x and p.y directly, which would be in almost all ways preferrable
> to using a record type which would make it impossible to define another type
> with fields named x or y.

I do use classes instead of records sometimes, but you really do lose when
you give up pattern matching!

> Alternatively, ocaml could offer ruby-style accessor macros, where a definition
> like:
> 
> class example =
>   object
>     attr_rw x = 0
>     attr_r  y = 0
>     attr    z = 0
>   end
> 
> would automatically generate get_x and set_x methods for x, a get_y method for
> y, and no methods for z.  I suppose you could implement this in camlp4, but I
> think features like this would have to be included in core ocaml before they'd
> really be used.  Records could even be deprecated if this were implemented.

Deprecate records? No way!

> This approach has, in my mind, two advantages:
> 1. The object system becomes more generally useful.
> 2. A confusing and non-orthogonal feature of ocaml is subsumed into
>    another, more generally useful and flexible feature.

I understand this desire to unify features and remove non-orthogonalities, 
but I don't like this proposal. I think it would be more interesting to
have a language with more polymorphism in records, as well as some more 
flexibility in modules. By enhancing those aspects of the language the 
advantages of classes would be reduced. 

Of course, if you're really into confusing, errr, unifying concepts, I
suppose we could unify modules and records too? No joke, I think a few 
language designs do this.

Anyways, I'd rather beef up records than try to eliminate them. The
research language SML# had pretty expressive records. That may be a more
promising direction. 

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Miles Egan]

On Tue, Jul 24, 2001 at 12:44:52PM -0700, Brian Rogoff wrote:
> >  Objects seem to provide more struct-like
> > semantics, i.e. field names need only be unique within their class definition.
> > Using objects in place of records is a bit clumsy, however, because object
> > fields require accessors.  If the rules for object field access were changed,
> > however, objects would be just as convenient as records and less
> 
> No, they'd still be *much* less convenient than records, since you can't
> pattern match on objects. 

That's a big disadvantage, I agree.
 
> > This approach has, in my mind, two advantages:
> > 1. The object system becomes more generally useful.
> > 2. A confusing and non-orthogonal feature of ocaml is subsumed into
> >    another, more generally useful and flexible feature.
> 
> I understand this desire to unify features and remove non-orthogonalities, 
> but I don't like this proposal. I think it would be more interesting to
> have a language with more polymorphism in records, as well as some more 
> flexibility in modules. By enhancing those aspects of the language the 
> advantages of classes would be reduced. 

Overall I agree.  I wonder if the inria folks are interested in making changes
in this area or if they're focusing on other things at the moment?  I'll take a
look at the SML# stuff.
 
> Of course, if you're really into confusing, errr, unifying concepts, I
> suppose we could unify modules and records too? No joke, I think a few 
> language designs do this.

As much as unifying concepts, I'm interested in identifying the "false friends"
new programmers encounter in Ocaml.  Records are such "false friends" I believe.
They resemble, even in syntax, C structs and are used in some fairly similar
ways, but functionally  they are quite different.  I think this fact would be
more obvious and less confusing if they weren't so enticingly but superficially
familiar.  Object syntax and behavior, on the other hand, is very similar to
that found in more mainstream languages and causes less confusion, I think.

Modules are another of these "false friends", I think.  In most commonly-used
languages, a module is rougly equivalent to a compilation unit and corresponds
to a source file.  In these languages, a module is essentially a collection of
related types and functions.  Ocaml top-level modules are very analagous, but
"modules" in ML are actually a very different beast with as much in common with
C++ templates as java packages.  This convolution of function wasn't clear to me
until I'd been programming in Ocaml for a while and I still find it fairly
dissonant psychologically.  In this case, I might even advocate ADDING new
terminology to Ocaml and explicitly distinguishing compilation units from
parametric polymorphs.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Brian Rogoff]

On Tue, 24 Jul 2001, Miles Egan wrote:
> On Tue, Jul 24, 2001 at 12:44:52PM -0700, Brian Rogoff wrote:
> > I understand this desire to unify features and remove non-orthogonalities, 
> > but I don't like this proposal. I think it would be more interesting to
> > have a language with more polymorphism in records, as well as some more 
> > flexibility in modules. By enhancing those aspects of the language the 
> > advantages of classes would be reduced. 
> 
> Overall I agree.  I wonder if the inria folks are interested in making changes
> in this area or if they're focusing on other things at the moment?  I'll take a
> look at the SML# stuff.

I don't know about records, but it appears that there is work on mixin
modules. While I agree that the record field problem is annoying, and
definitely not a feature, it's not on my top 3 list of fixes or new 
features desired. Probably somewhere between a petty complaint and a 
nuisance. I do work with programmers who hate Caml for this very reason
though!

> > Of course, if you're really into confusing, errr, unifying concepts, I
> > suppose we could unify modules and records too? No joke, I think a few 
> > language designs do this.
> 
> As much as unifying concepts, I'm interested in identifying the "false friends"
> new programmers encounter in Ocaml.  Records are such "false friends" I believe.
> They resemble, even in syntax, C structs and are used in some fairly similar
> ways, but functionally  they are quite different.  I think this fact would be
> more obvious and less confusing if they weren't so enticingly but superficially
> familiar.  Object syntax and behavior, on the other hand, is very similar to
> that found in more mainstream languages and causes less confusion, I think.

It also seems that you'd like to eliminate these false friends (good phrase, 
especially for a bilingual French-English mailing list!) by subsuming them
into features that mainstream programmers know well. That would be a
mistake, since you'd end up with a mainstream language. 

I don't think records are really such a false friend, it's just that if
you want type inference the whole issue of what the type of a record field 
access is is a bit more complex. 

> Modules are another of these "false friends", I think.  In most commonly-used
> languages, a module is rougly equivalent to a compilation unit and corresponds
> to a source file. 

I spent a fair bit of time learning and using Ada 95 before I hit OCaml,
since at the time C++ was achieving popularity I was doing numerics and I 
wanted templates (which were very poorly supported in the early to mid
90s). Ada packages correspond very closely to ML modules, and there are
even crude approximations to functors and signatures in Ada 95 (generic 
formal package parameters in Ada parlance). 

If you are only used to C/C++/Java and Perl/Tcl then OCaml is very different. 

> In these languages, a module is essentially a collection of
> related types and functions. 

In OCaml, a structure is essentially a collection of definitions (of
types, functions, classes, modules..). So it's not too different. 

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Miles Egan]

On Wed, Jul 25, 2001 at 08:15:49AM -0700, Brian Rogoff wrote:
> I don't know about records, but it appears that there is work on mixin
> modules. While I agree that the record field problem is annoying, and
> definitely not a feature, it's not on my top 3 list of fixes or new 
> features desired. Probably somewhere between a petty complaint and a 
> nuisance. I do work with programmers who hate Caml for this very reason
> though!

Rejecting ocaml over this is a tragic mistake! :)  It can be very jarring to
people with the wrong expectations, as you've seen.  The two situations in which
I find it most jarring:

1. The work-around usually suggested, to wrap the record definitions in local
module definitions, is actually worse.  It results in code that looks like
var.Type.field, rather than Type.var.field.  This gives C++/Java programmers
fits.  The more cumbersome, but familiar method of prefixing field names with
the record type, a la var.type_field, is even preferrable.

This syntax appears even in common uses of the standard library.  For example,
if I use the Unix stat functions, I have to access the fields of the returned
record as res.Unix.st_perm, not just res.st_perm or even Unix.res.st_perm.  Once
the difference is clear, this isn't too annoying, but it's a big speedbump for
newbies.

> It also seems that you'd like to eliminate these false friends (good phrase, 
> especially for a bilingual French-English mailing list!) by subsuming them
> into features that mainstream programmers know well. That would be a
> mistake, since you'd end up with a mainstream language. 

I certainly wouldn't generally characterize my intentions that way.  I'm more
interested in re-evaluating gratuitous differences.  At any rate, I agree that
the loss of pattern-matching more than outweighs the benefits in this case.
Ocaml is stylistically quite comfortably out of the mainstream in many ways and
I'm sure it will remain so.

> 90s). Ada packages correspond very closely to ML modules, and there are
> even crude approximations to functors and signatures in Ada 95 (generic 
> formal package parameters in Ada parlance). 

It's not the combination of packaging and polymorphism in Ocaml that I think is
confusing.  In fact, I think it's one of it's most compelling features.  It's
the fact that compilation units are implicit top-level modules with special
properties.  A few paragraphs in the documentation explaining top-level modules
and the relationship between source files and implicit top-level modules might
clarify this a bit better for new users.

Perhaps some kind of "Ocaml for Java Programmers" FAQ might be useful?

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Brian Rogoff]

On Thu, 26 Jul 2001, Miles Egan wrote:
> On Wed, Jul 25, 2001 at 08:15:49AM -0700, Brian Rogoff wrote:
> > It also seems that you'd like to eliminate these false friends (good phrase, 
> > especially for a bilingual French-English mailing list!) by subsuming them
> > into features that mainstream programmers know well. That would be a
> > mistake, since you'd end up with a mainstream language. 
> 
> I certainly wouldn't generally characterize my intentions that way.  I'm more
> interested in re-evaluating gratuitous differences.  At any rate, I agree that
> the loss of pattern-matching more than outweighs the benefits in this case.
> Ocaml is stylistically quite comfortably out of the mainstream in many ways and
> I'm sure it will remain so.

I think pattern matching is a compelling feature. I'd like to see
extensions to OCaml's pattern matching, like the SMLish ability to to
distinguish a partial and full record match (yeah I know backwards
compatibility may be an issue). And views, and...

 > 
> > 90s). Ada packages correspond very closely to ML modules, and there are
> > even crude approximations to functors and signatures in Ada 95 (generic 
> > formal package parameters in Ada parlance). 
> 
> It's not the combination of packaging and polymorphism in Ocaml that I think is
> confusing.  In fact, I think it's one of it's most compelling features.  It's
> the fact that compilation units are implicit top-level modules with special
> properties.  A few paragraphs in the documentation explaining top-level modules
> and the relationship between source files and implicit top-level modules might
> clarify this a bit better for new users.

http://caml.inria.fr/ocaml/htmlman/manual005.html section 4.5 explains it. 
Maybe a few more paragraphs showing how to use module types, functors, and
top level modules in a smallish compiled program would help? 

> Perhaps some kind of "Ocaml for Java Programmers" FAQ might be useful?

I don't use Java enough that it's the source of false friends. Are you
volunteering?

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Miles Egan]

On Thu, Jul 26, 2001 at 08:47:51AM -0700, Brian Rogoff wrote:
> http://caml.inria.fr/ocaml/htmlman/manual005.html section 4.5 explains it. 
> Maybe a few more paragraphs showing how to use module types, functors, and
> top level modules in a smallish compiled program would help? 

Right.  A bit more elaboration there might help.
 
> > Perhaps some kind of "Ocaml for Java Programmers" FAQ might be useful?
> 
> I don't use Java enough that it's the source of false friends. Are you
> volunteering?

Thankfully, neither do I anymore.  I think it's an issue for C, C++, and Python
programmers as well, though.  I'd be happy to work on a FAQ if I'm not the only
one that thinks it might be productive.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[John Max Skaller]

Brian Rogoff wrote:

> Classes and types can't be in a recursive relationship either (though
> there are things you can do with row types here to ease this...).

	but there's no good reason for this that I can see.
will this be fixed in 3.02?

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Sven]

On Tue, Jul 24, 2001 at 11:08:17AM -0700, Miles Egan wrote:
> This approach has, in my mind, two advantages:
> 1. The object system becomes more generally useful.
> 2. A confusing and non-orthogonal feature of ocaml is subsumed into
>    another, more generally useful and flexible feature.

But object are more heavyweight than plain record, which are, if i am not wrong,
just named tuples.

Friendly,

Sven Luter
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[Miles Egan]

On Tue, Jul 24, 2001 at 10:26:16PM +0200, Sven wrote:
> On Tue, Jul 24, 2001 at 11:08:17AM -0700, Miles Egan wrote:
> > This approach has, in my mind, two advantages:
> > 1. The object system becomes more generally useful.
> > 2. A confusing and non-orthogonal feature of ocaml is subsumed into
> >    another, more generally useful and flexible feature.
> 
> But object are more heavyweight than plain record, which are, if i am not wrong,
> just named tuples.

I'm not sure about the runtime efficiency of objects, but in terms of memory
usage objects use one more field (word, I think?) of storage than a record with
the same instance members.

-- 
miles

"We in the past evade X, where X is something which we believe to be a
lion, through the act of running." - swiftrain@geocities.com
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] a reckless proposal

[FabienFleutot]

> The most frustrating feature of records, of course, is that each record
field
> name must be globally unique.
> [...]
> less confusing and
> more comfortable to C/C++/Java/Python programmers.

Some old K&R C compilers also need unique struct fields id. (That's probably
why the Un*x struct fields have unique prefixes).

This unique struct field id. in caml allows to easily guess a struct's type
in a pattern-matching; I'll write about GCaml without having read related
papers nor compiler sources, but wouldn't it be possible, with GCaml type
engine, to introduce the required polymorphism in non-unique struct field
name pattern matching?
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr