Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Class definition syntax restrictions #7529

Closed
vicuna opened this issue May 5, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link

commented May 5, 2017

Original bug ID: 7529
Reporter: mookid
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2017-07-20T07:25:44Z)
Resolution: fixed
Priority: normal
Severity: feature
Category: language features
Duplicate of: #6271

Bug description

Compared to value definitions, class definitions have several restrictions. They have to be in the form

[value definitions]
in
object
  [values and methods and initializers]
end

In particular, the following two are not valid syntactic expressions:

class c = let r = ref [] in r := [1]; object end  ;;
Characters 31-33:
  class c = let r = ref [] in r := [1]; object end;;
                                ^^
Error: Syntax error
# class c = let open List in object end;;
Characters 14-18:
  class c = let open List in object end;;
                ^^^^
Error: Syntax error

Is there any rationale behind these two restrictions, besides making the class sub-language less usable?

@vicuna

This comment has been minimized.

Copy link
Author

commented May 7, 2017

Comment author: @dra27

I think it is fair to say that no decision in the language was taken with a view to making any part of the language less usable.

In the first instance, there are already two ways of writing what you want:

class c =
  let r = ref [] in
  let () = r := [1] in
  object
  end

and (admittedly only for your specific example):

  class c =
    let r = {contents = [1]} in
    object
    end

There are also initializer, though the semantics are of course different (evaluate at object creation rather than class definition):

class c =
  let r = ref [] in
  object
    initializer r := [1]
  end

Does generalising class definition to be a sequence ending in a object really add much-needed expressive power?

@vicuna

This comment has been minimized.

Copy link
Author

commented May 7, 2017

Comment author: @dra27

For the second case, I expect the class sub-language was simply not considered when let open was added to the language - perhaps Alain has thoughts on this? It seems like a reasonable thing to add to me.

@vicuna

This comment has been minimized.

Copy link
Author

commented May 7, 2017

Comment author: mookid

I am aware of this workaround.

My point is that in most cases (recursive definition aside), changing an object definition to a class definition should be a matter of changing one "let" to "class". I consider any additional required change as a failure.

And contrary to some other dubious syntactic characteristics (in particular,"f -1" not being "f (-1)", for instance), fixing it would probably not break existing code.

@vicuna

This comment has been minimized.

Copy link
Author

commented May 9, 2017

Comment author: @yallop

There's some discussion of "let open" for classes here:

#6271

@vicuna

This comment has been minimized.

Copy link
Author

commented Jul 18, 2017

Comment author: @alainfrisch

#1249

@vicuna

This comment has been minimized.

Copy link
Author

commented Jul 20, 2017

Comment author: @alainfrisch

"let open" as been added.

For sequencing, there exists a trivial and local syntactic rewriting ("e; ce" => "let () = e in ce"). I don't think this deserves any particular treatment at the language level.

A local module binding (and module patterns) would seem be more useful, but Jacques mentions in #6271 that this would be quite difficult (presumably to ensure that types from the module don't escape).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.