Not compiling with version S3.5 #1

Closed
tcard opened this Issue Jun 29, 2011 · 7 comments

Projects

None yet

5 participants

tcard commented Jun 29, 2011

The code, as is, throws at compile the following error:

opa  src/twopenny.opack -o main.exe
In src/msg.opa [30:13-30:13 | global chars=552-552]
Syntax error at line 30, column 13
The error may be in the following citation, usually in the red part (starting at ⚐) or just before:
<<

Msg = {{

  create(author : User.ref, content : string) : Msg.t =
    msg = { ~author ~content created_at=Date.now() }
    @wrap(msg⚐)

  get_creation_date(msg : Msg.t) : Date.date =
    @unwrap(msg).created_at

 >>
Hint: expected " (" or "" or "%" or "&" or "(" or ")" or "," or "->" or ":" or "<" or "<-" or "=" or "?" or "@" or "as" or "|" or "||" or '_' or <function parameters> or <spacing> or <xhtml> or ['0'-'9'] or ['A'-'Z'] or ['a'-'z'] 
(while parsing <function parameters> starting at line 30, column 13)
Error
Syntax error
make: *** [main.exe] Error 1

I didn't find the @unwrap directive anywhere in the docs. Perhaps it is deprecated?

Contributor
Aqua-Ye commented Jun 29, 2011

Hello tcard,

@wrap and @unwrap directives have indeed been removed from Opa.
We now have @private and @abstract to provide abstraction.

Moreover, the stdlib packages have also changed, so the import do not work, i hope akoprow will fix it soon ;)

To conclude, this project does not compile with Opa s3.5 yet :)

Contributor
Aqua-Ye commented Jun 29, 2011

I fixed the compilation. Pushed it.

Hi,

I didn't find the @unwrap directive anywhere in the docs. Perhaps it is deprecated?

Yes it is. What was called "private types", using @wrap and @unwrap totally disapeared.
Instead, take benefits of directives @private and @abstract in type definitions.
For instance:

@abstract type t = int

or

@private type t = int

The meaning, as explained in the user manual is that @private types are only visible
in the scope of the package defining them. Outside, they "do not exist".
Differently, @abstract types are fully (transparently) visible in the package defining
them but are seen as opaque outside. In other word, they are visible outside but not
their internal structure. On the opposite, @private type are not visible at all outside
their package.

Regards,

-- François Pessaux

Contributor
akoprow commented Jun 30, 2011

Hey guys, thanks for fixing the compilation issue. Indeed, it's been a while since I touched twopenny (and unfortunately probably it will be again before I do so), so indeed Opa has gone a long way since then, which resulted in few minor incompatibilities.

@akoprow akoprow closed this Jun 30, 2011
mbarbin commented Jul 7, 2011

for public applications, it would be good to use the option --minimal-version
--minimal-version Ensure that the compiler is newer than the given version

this case shows that an option --maximal-version would be good too ! (as suggested frs)

Contributor
akoprow commented Jul 7, 2011

Yup, agreed on --minimal-version.
The problem with --maximal-version is that one does not know it in advance. When writing an app one would in general hope that the --maximal-version would be infinity ;)

mbarbin commented Jul 7, 2011

about --maximal-version, I guess it is more a way for quickly "fixing" an application, waiting for a real update.

The following scenario could be envisaged:

  1. application is started with a given version, the Makefile uses --minimal-version.
  2. nobody works on the application
  3. somebody sees that the application does not compile anymore at some point.
    if he has no really time (or budget) to update the app, and he knows a specific old version
    which was ok, he can add the --maximal-version option
  4. with more time, somebody update the application, and so remove --maximal-version, and upgrade --minimal-version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment