Re: [Caml-list] int32/int64 literals in next release?

Re: [Caml-list] int32/int64 literals in next release?

[Pierre Weis]

Hi,

> Is there any chance some way of inputing int32/int64 literals can be
> added to the compiler for this next release?

AFAIK, this is fairly hight in the todo list.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] int32/int64 literals in next release?

[Chris Hecker]

Is there any chance some way of inputing int32/int64 literals can be
added to the compiler for this next release?  It's a pain in the rear
to convert them from strings and whatnot, and as they become more and
more usable (unboxing optimizations, used in more apis, work in
printf/scanf, etc.) it becomes relatively more of a pain to initialize
the damn things.  And, I'd say it's more likely that you'll use
int32/int64 with constant bit patterns in source because they're
full-width and useful for interfacing with the outside world.  It
would also eliminate the need for the really silly part at the top of
the two interfaces with the "chosen constants":

<<
  val zero : int32
>>
                The 32-bit integer 0.
<<
  val one : int32
>>
                The 32-bit integer 1.
<<
  val minus_one : int32
>>
                The 32-bit integer -1.

There have been a bunch of syntax proposals on this list before.  I'd
be happy with any of them as long as there was some way to do it (in
hex,dec,bin,oct of course, and with the new _ separator :).

Thanks,
Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] int32/int64 literals in next release?

[Shawn Wagner]

On Wed, Nov 13, 2002 at 10:42:36PM +0100, Pierre Weis wrote:
> Hi,
> 
> > Is there any chance some way of inputing int32/int64 literals can be
> > added to the compiler for this next release?
> 
> AFAIK, this is fairly hight in the todo list.
> 

Ask, and ye shall recieve (In other words, I had a few hours to kill and
have been wanting this feature myself).

http://raevnos.pennmush.org/code/litint306-1.diff.gz

or http://raevnos.pennmush.org/code/ocaml.html in case the direct URL
doesn't work, as I might put up newer versions (-2, -3, etc.) if I fix any of
the problems noted below.

Uses a suffix to the number to indicate type, like in C. The actual suffixes
are taken from the printf formats.

With it:
% ./ocaml
        Objective Caml version 3.06

# 0;;
- : int = 0
# 0l;;
- : int32 = <int32 0>
# 0L;;
- : int64 = <int64 0>
# 0n;;
- : nativeint = <nativeint 0>
# Int32.mul 6l 7l;;
- : int32 = <int32 42>

Tested with bytecode and i386 linux native.

Problems I know about already:

* The native compiler doesn't support literal int64's, as I didn't see a place
to crib from for what to emit in cmmgen.ml after a quick look.

* int32's and nativeints on the native compiler aren't heavily tested, though
simple problems using them compile and appear to work right.

* Compiling camlp4 breaks with:
../../boot/ocamlrun ../boot/camlp4 -nolib -I ../boot ./pa_lispr.cmo
pa_extend.cmo q_MLast.cmo pr_dump.cmo -o pa_lisp.ppo pa_lisp.ml
Error while loading "./pa_lispr.cmo": interface mismatch on MLast.

I haven't been able to figure out why. camlp4 is commented out of the
Makefile for now.

* The Foo.of_string functions aren't handling the suffixes, even though I
changed ints.c:parse_long() and ints.c:int64_of_string() to do so, and they
work when called through gdb. Do ocamlrun and the native compiler use
another set of functions for the conversions?


Help with any of the above is appreciated.

-- 
Shawn Wagner
shawnw@speakeasy.org
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] int32/int64 literals in next release?

[Yurii A. Rashkovskii]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

Hi Shawn!

On Wed, 13 Nov 2002, Shawn Wagner wrote:
> Problems I know about already:

[...]

> Help with any of the above is appreciated.

May be something like this will be easier?


open Pcaml;;

let create_int loc v = <:expr< (int_of_string $str:v$) >>;;
let create_int32 loc v = <:expr< (Int32.of_string $str:v$) >>;;
let create_int64 loc v = <:expr< (Int64.of_string $str:v$) >>;;
let create_nativeint loc v = <:expr< (Nativeint.of_string $str:v$) >>;;

EXTEND

 expr:
  [[
     i = INT; "l" -> create_int32 loc i
   | i = INT; "L" -> create_int64 loc i
   | i = INT; "n" -> create_nativeint loc i   
   | i = INT -> create_int loc i
  ]];

END
;

-- 
Regards,
Yurii.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] int32/int64 literals in next release?

[Shawn Wagner]

On Thu, Nov 14, 2002 at 10:49:43AM +0200, Yurii A. Rashkovskii wrote:
> Hi Shawn!
> 
> On Wed, 13 Nov 2002, Shawn Wagner wrote:
> > Problems I know about already:
> 
> [...]
> 
> > Help with any of the above is appreciated.
> 
> May be something like this will be easier?
> 
> 
> open Pcaml;;
> 
> let create_int loc v = <:expr< (int_of_string $str:v$) >>;;
> let create_int32 loc v = <:expr< (Int32.of_string $str:v$) >>;;
> let create_int64 loc v = <:expr< (Int64.of_string $str:v$) >>;;
> let create_nativeint loc v = <:expr< (Nativeint.of_string $str:v$) >>;;
> 
> EXTEND
> 
>  expr:
>   [[
>      i = INT; "l" -> create_int32 loc i
>    | i = INT; "L" -> create_int64 loc i
>    | i = INT; "n" -> create_nativeint loc i   
>    | i = INT -> create_int loc i
>   ]];
> 
> END
> ;
> 

I'd rather not have to go to the trouble of running every .ml file through
camlp4 for something that the language should be able to handle by default
without resorting to special tricks. Using camlp4 also kind of defeats the
idea of not having to use a conversion function everywhere you'd want to use
a literal large int value, doesn't it? 

Anyways, I /think/ I can get camlp4 at least compiled, if I can figure out
where the constraints in an <:expr< > pattern are checked, and then how to
add more. Trying to make it recognize $int32:_$ and the like.

-- 
Shawn Wagner
shawnw@speakeasy.org
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] int32/int64 literals in next release?

[Daniel de Rauglaudre]

Hi,

On Thu, Nov 14, 2002 at 04:14:52PM -0800, Shawn Wagner wrote:

> Anyways, I /think/ I can get camlp4 at least compiled, if I can figure out
> where the constraints in an <:expr< > pattern are checked, and then how to
> add more. Trying to make it recognize $int32:_$ and the like.

For that, it should be necessary to be able to represent these constants
in the syntax tree, what seems not to be implemented in the ocaml compiler.

For the <:expr< >>: they are evaluated at compile time. But, indeed,
if the contents is a function call, it generates a function call which
is of course applied at run time, which is not satisfactory if you want
to speak of "a constant".

-- 
Daniel de RAUGLAUDRE
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] int32/int64 literals in next release?

[Shawn Wagner]

On Wed, Nov 13, 2002 at 11:44:25PM -0800, Shawn Wagner wrote:
> On Wed, Nov 13, 2002 at 10:42:36PM +0100, Pierre Weis wrote:
> > Hi,
> > 
> > > Is there any chance some way of inputing int32/int64 literals can be
> > > added to the compiler for this next release?
> > 
> > AFAIK, this is fairly hight in the todo list.
> > 
> 
> Ask, and ye shall recieve (In other words, I had a few hours to kill and
> have been wanting this feature myself).
> 
> http://raevnos.pennmush.org/code/litint306-1.diff.gz
> 
> or http://raevnos.pennmush.org/code/ocaml.html in case the direct URL
> doesn't work, as I might put up newer versions (-2, -3, etc.) if I fix any of
> the problems noted below.
> 
> Uses a suffix to the number to indicate type, like in C. The actual suffixes
> are taken from the printf formats.

> 
> Problems I know about already:
> 
> 
> * The Foo.of_string functions aren't handling the suffixes, even though I
> changed ints.c:parse_long() and ints.c:int64_of_string() to do so, and they
> work when called through gdb. Do ocamlrun and the native compiler use
> another set of functions for the conversions?
> 

This, at least, I figured out. Helps to use the right version of ocamlrun.
Silly me.

Going to try poking at getting it to compile camlp4 again when I have the
time, possibly next week, if there's interest. Ocaml developers?


-- 
Shawn Wagner
shawnw@speakeasy.org
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners