This commit modifies the parser to use the newly defined .() and .[] operators. It also moves the definition of the standard .() and .[] operator for String/Bytes and Array to the pervasives module.
Before this commit, expressions of the form array.(index) and string.(index) where desugared to Array.get[_unsafe] array index and Strinf.get[_unsafe] string index. The unsafe or unsafe version were chosen depending on the presence of the "-unsafe" compiler option. Such expression are now desugared to ( .() ) array index and ( .[] ) string index respectively. The same desugar operation is applied to array.(index) <- value which becomes ( .()<- ) array index value.
In order to keep the standard semantic for the string and array index operations, these new index operators are defined in the pervasives module using new compiler primitives, e.g.
let .() = "%array_opt_get".
These new primitives are then mapped to safe or unsafe version depending on the
the "-unsafe" compiler option. Consequently, these modifications should have no impact on existing code.
With these modifications, defining custom .() and .[] operators should be easier, at the cost of losing access to the standard index operator for either array or string.
From: octachron <octa@polychoron.fr>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15661 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
It is important not to assume that String.t and Bytes.t will always
share the same representation. Using Obj.magic to convert between
functions would give a very bad example to users considering
a migration, which are very quick to imitate any moral turpitude found
in the standard library.
An unfortunate consequence of the change is the duplication of
String.concat code; other designs would be possible to share more
implementation details between Bytes and String (eg. defined
factorized operations on both in a shared internal module), but if we
consider that String representation may evolve in the future this
coincidence of implementation is really a temporary coindence rather
than an definitive duplication.
I checked that all the small functions introduced are marked as
inlinable. In the case of coercions like this, we could even have the
compiler recognize eta-expansions of the identity function and turn
them into simple rebindings.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15060 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
See the long comment in pervasives.ml for an explanation of the
change. The short summary is that we need to prove more elaborate
properties between the format types involved in the typing of %(...%),
and that proving things by writing GADT functions in OCaml reveals
that Coq's Ltac is a miracle of usability.
Proofs on OCaml GADTs are runtime functions that do have a runtime
semantics: it is legitimate to hope that those proof computations are
as simple as possible, but the current implementation was optimized
for feasability, not simplicity. François Bobot has some interesting
suggestions to simplify the reasoning part (with more equality
reasoning where I used transitivity and symmetry of the
relation profusely), which may make the code simpler in the future
(and possibly more efficient: the hope is that only %(...%) users will
pay a proof-related cost).
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14897 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This should make the type-checking of formats simpler and more robust:
instead of trying to find a pair as previously, we can now use the
path of the format6 type directly.
A nice side-effect of the change is that the internal definition of
formats (as a pair) is not printed in error messages anymore.
Because format6 is in fact defined in the CamlinternalFormatBasics
submodule of Pervasives, and has an alias at the toplevel of
Pervasives, error messages still expand the definition:
> Error: This expression has type
> ('a, 'b, 'c, 'd, 'd, 'a) format6 =
> ('a, 'b, 'c, 'd, 'd, 'a) CamlinternalFormatBasics.format6
> but an expression was expected of type ...
Passing the option `-short-paths` does avoid this expansion and
returns exactly the same error message as 4.01:
> Error: This expression has type ('a, 'b, 'c, 'd, 'd, 'a) format6
> but an expression was expected of type ...
(To get this error message without -short-paths, one would need to
define format6 directly in Pervasives; but this type is mutually
recursive with several GADT types that we don't want to add in the
Pervasives namespace unqualified. This is why I'll keep the alias
for now.)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14868 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Given that there still remains a small incompatibility (typing of
%(..%)), I decided to keep the legacy mode enabled for now. This means
that any failure related to format can be traced to this
incompatiblity (or unknown regressions), which will simplify the
monitoring and handling of changes considerably. As soon as the %(..%)
typing is generalized, we can turn the legacy mode off (or maybe
simply add warnings for ignored formats).
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14841 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(printf {%foo%} bar) will print the string representation of the
format type of both `foo` and `bar`, instead of printing `bar`
(for this purpose one can just use %s). `bar` content is ignored, but
the typer should check that its type is compatible with the one of
`foo`.
This semantics allows to use (printf %{..%}) for testing/debugging the
use of %(...%): put in the brackets what you believe to be the format
type you want to use, and as argument the format you wish to pass, and
you'll get type-checking confidence and the "canonical" representation
of the format string which you can use in the %(...%) -- note that
using the canonical format type is not mandatory.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14840 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This simplifies the charset-handling code, as camlinternalFormat is
allowed to depend on Bytes and String instead of re-importing the
needed primitives.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14837 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The legacy implementation doesn't support "%+_", "%-_" etc. which were
accepted by Benoît's patches. This creates a discrepancy (though not
a regression) that is not necessarily desirable (and in any case makes
fuzz-testing for difference return non-bugs). Long-term, I think that
we're good with the previous, simpler structure where "_" must always
be the first flag.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14827 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
When the OCAML_LEGACY_FORMAT environment variable is set, the compiler
will try to emulate the behaviour of the previous implementation of
format.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14813 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
To finish the bootstrap cycle, run:
make library-cross
make promote
make partialclean
make core
make library-cross
make promote-cross
make partialclean
make ocamlc ocamllex ocamltools
make library-cross
make promote
make partialclean
make core
make compare
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14810 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
After applying this patch, you should run:
make library-cross
make promote-cross
make partialclean
make ocamlc ocamllex ocamltools
and then immediately apply the following patches until the "second
part of Benoît Vaugon's format+gadts patch"; the bootstrap cycle is
not finished yet.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14806 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
- The internal [backtrace_slot] type is not exposed anymore, instead
accessors function return orthogonal information
(is_raise, location). This is both more extensible and more
user-friendly.
- The [raw_backtrace_slot] is exposed separately as a low-level type
that most users should never use. The unsafety of marshalling is
documented. Instead of defining
[raw_backtrace = raw_backtrace_slot array], I kept [raw_backtrace]
an abstract type with [length] and [get] functions for
random-access. This should allow us to change the implementation in
the future to be more robust wrt. marshalling (boxing the trace in
a Custom block, or even possibly the raw slots at access time).
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14784 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Patch by Jacques-Henri Jourdan)
There are several changes:
- `raw_backtrace` is no longer an abstract type, but rather an
`raw_backtrace_slot array`, where `raw_backtrace_slot` is a new
abstract type. `raw_backtrace_slot` elements are hashable and
comparable. At runtime, values of this type contain either
a bytecode pointer or a frame_descr pointer. In order to prevent the
GC from walking through this pointer, the low-order bit is set to
1 when stored in the array.
- The old `loc_info` type is know public, renamed into `backtrace_slot`:
type backtrace_slot =
| Known_location of bool (* is_raise *)
* string (* filename *)
* int (* line number *)
* int (* start char *)
* int (* end char *)
| Unknown_location of bool (*is_raise*)
- new primitive :
val convert_raw_backtrace_slot: raw_backtrace_slot -> backtrace_slot
Rather than returning an option, it raises Failure when it is not
possible to get the debugging information. It seems more idiomatic,
especially because the exceptional case cannot appear only for a part
of the executable.
- the caml_convert_raw_backtrace primitive is removed; it is more
difficult to implement in the C side because of the new exception
interface described above.
- In the bytecode runtime, the events are no longer deserialized once
for each conversion, but once and for all at the first conversion,
and stored in a global array (*outside* the OCaml heap), sorted by
program counter value. I believe this information should not take
much memory in practice (it uses the same order of magnitude memory
as the bytecode executable). It also makes location lookup much more
efficient, as a dichomoty is used instead of linear search as
previously.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14776 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Also removes __FILE_OF__ and __MODULE_OF__, since they are not more precise
than __FILE__ and __MODULE__
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14715 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Noticed that I had to bootstrap to test on ARM, so I commit a new bootstrap
compiler.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14479 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Patch by Jérôme Vouillon)
Js_of_ocaml has 32 bit integers. Currently, it patches the bytecode,
just to get the correct values for [min_int] and [max_int]. It would be
simpler if this was not necessary.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14477 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
14278
14277
14276
14176
14175
14173
14172
14171
14169
14168
14167
These changes need to mature on their own branch.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14329 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
of size 2, with tag = Object_tag, the first field being the pointer to the string, and second one being a unique id, generated
from the same sequence as for object values. Special case for predefined exceptions, represented with a negative id.
The unique id generator is moved from camlinternalOO to the C runtime system.
Also fix some bugs.
git-svn-id: http://caml.inria.fr/svn/ocaml/branches/raise_variants@14239 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This script was built from ocamlcomp.sh.in through sed and is called
instead of "ocamlc" (for instance).
It makes it possible to switch from "ocamlc" to "ocamlc.opt" without
changing anything in the Makefiles, only calling sed.
I couldn't cleanly make it handle both a compiler for the target and for
the build. Instead I'm replacing it and doing as much as possible
directly in the Makefiles.
I hoped it would reduce the number of shell invocations, which would
speed things up quite a lot on Windows but I still had to have at least
one since it's not possible to update a make variable from inside a make
rule: i.e. it's not possible to do X=a, build a.opt and update X to be
a.opt.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14168 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
As I learned the hard way, it is essentially impossible to get
a satisfying behavior in presence of a mix of updates, concatenations
and counts. The best thing to do is thus to not change anything
(a good way to preserve compatibility), and only fix the
Stream.of_string function to assume nothing of the count passed to the
[from] function.
I also modified the mli documentation of [Stream.from] to warn other
users of this potential pitfall.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13915 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
According to the reporter 'sliquister', type-specialized comparison
can nearly halve compilation time in some cases. This patch applies
type-specialization throughout the OCaml distribution sources, so not
all changes will have performance utility, but in this case I think
it's best to be consistent, as I see no downside to the change.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13410 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Gabriel Scherer
Jérémie Dimino
Damien Doligez
Alain Frisch
Mark Shinwell
Xavier Leroy
Jacques Garrigue
Fabrice Le Fessant
Luc Maranget
Wojciech Meyer
Hongbo Zhang
Pierre Weis