Hello
Here is the latest Caml Weekly News, for the week of January 18 to 25, 2011.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-01/msg00184.html
Jeffrey Scofield announced:
I needed an OCaml interface to OpenGL ES for a project. After looking
around, I decided to create my own interface, as a set of patches to
LablGL.
I've made the patches publicly available, along with instructions on how
to build the interface. You can find them here:
http://psellos.com/ocaml/lablgles-build.html
What the patches do, roughly, is remove stuff that isn't supported by
OpenGL ES, adjust names that are different from standard OpenGL, and add
support for two OpenGL ES extensions: framebuffer objects[1] and PVRTC
compressed textures[2].
The patches are known to work on iPhone (part of a shipping product).
Regards,
Jeffrey Scofield
[1]:
http://khronos.org/registry/gles/extensions/OES/OES_framebuffer_object.txt
[2]:
http://khronos.org/registry/gles/extensions/IMG/IMG_texture_compression_pvrtc.txt
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-01/msg00175.html
Lauri Alanko asked and Jacques Garrigue replied:
> When first-class modules were announced for OCaml 3.12, I cheered them
> as a sorely needed extension, and I have now begun to make heavy use
> of them. I certainly prefer them over objects, even if I do find the
> syntax of first-class modules a bit awkward. I would much prefer to
> see a completely unified object-module system a la Scala, but I guess
> such drastic changes are beyond the scope of OCaml's development
> nowadays.
>
> Anyway, I'm now beginning to stumble into the limitations of the
> extension, and I'm a bit curious about their rationale.
>
> In a type (module S), S must be a path to a named module type, and if
> A and B are two different paths, (module A) and (module B) are
> distinct even if A and B are transparent definitions for exactly the
> same module types. This nominalism is quite surprising since one is
> used to transparent definitions being just shorthands for signatures
> that are compared structurally. In particular, this means that it is
> no longer harmless to include a signature definition to compose a
> convenience module from several submodules:
>
> module A = struct
> module type S = sig end
> type t = (module S)
> module M : S = struct end
> let v = (module M : S)
> end
>
> module B = struct
> include A
> end
>
> # module X : A.S = B.M;;
> module X : A.S
>
> # let x : A.t = B.v;;
> Error: This expression has type (module B.S)
> but an expression was expected of type A.t = (module A.S)
I think there are two reasons for this limitation:
* avoiding having to run a full module type comparison during unification
(potentially costly)
* in case the first-class module has type variables in its parameters,
the original algorithm for module type comparison cannot be applied
directly
I'm not sure the first reason matters that much.
The second one is more problematic, but clearly does not apply to your case.
So it should at least be possible to check module type equality structurally
for
parameter-less first-class module types.
Note that if you use the trunk version (3.13), you need less annotations, so
you could write:
let x : A.t = (module (val B.v))
A bit verbose, but no extra type annotations.
> Also, the limitations of package type constraints were also somewhat
> surprising.
The main goal of package type constraints is to allow connecting
types in the signature with type variables in the context.
Since type variables cannot have higher-order kinds in ocaml,
allowing to specify parameterized types in with constraints would
not make sense from that point of view.
It may still be useful, but there may be difficulties in connection with
the new implicit pack/unpack mecanism.
Alain Frisch also replied:
> When first-class modules were announced for OCaml 3.12, I cheered them
> as a sorely needed extension, and I have now begun to make heavy use
> of them. I certainly prefer them over objects, even if I do find the
> syntax of first-class modules a bit awkward.
As Jacques mentioned, OCaml 3.13 will allow a lighter syntax, with a
lot less explicit type annotations. Hopefully, this will make it less
awkward.
> I would much prefer to
> see a completely unified object-module system a la Scala, but I guess
> such drastic changes are beyond the scope of OCaml's development
> nowadays.
Indeed.
> Anyway, I'm now beginning to stumble into the limitations of the
> extension, and I'm a bit curious about their rationale.
>
> In a type (module S), S must be a path to a named module type, and if
> A and B are two different paths, (module A) and (module B) are
> distinct even if A and B are transparent definitions for exactly the
> same module types.
One could indeed declare that (module A) and (module B) are equal as
soon as A and B refer to equal module types (that is, two module types
subtype of each other without any coercion). I don't think there is
any deep obstacle in doing that. One would need to be a little bit
careful with mutually recursive types and module types (introduced
with a recursive module). As for the implementation strategy, I'm a
little bit concerned of having a low-level module in the type-checker
(Ctype), in charge of things like type equality check or unification,
calling a function in a higher-level module (Includemod), but I don't
see immediately any concrete problem in doing that.
What would be much more difficult is to declare that general package
type (with constraints, like (module A with type t1 = T1)) are equal
if the module types obtained by "applying the constraints" are
equal. Indeed, the type T1 above can contain type variables, and a
constraint "with type t1 = T1" is then not supported by the module
system (there is no module type with free type variables).
There is a branch fstclassmod_parametrized in the SVN which allows
more kinds of constraints; in particular, it allows constraints on
parametrized types (module A with type 'a t1 = T1). See e.g.
http://caml.inria.fr/mantis/view.php?id=5078
This extension does not seem very useful to me in practice (because
there is no polymorphism on type constructors in OCaml). Moreover, it
isn't trivially combined with Jacques' work mentioned above. So it's
probably not going to be integrated upstream.
Feel free to open entries in the bug tracker with specific examples of
things you'd like to do but which are not possible or difficult with
the current design. My initial work on first-class modules was driven
by our internal use at LexiFi (for which the nominal aspect has never
been a problem) and also by the constraint of keeping the patch small
enough (to increase the odds of being accepted upstream).
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-01/msg00212.html
Richard Jones announced:
OCaml 3.12 has been accepted as a feature for Fedora 15. That work
has now been finished and you can use the same packages in Fedora 14
if you like:
http://fedoraproject.org/wiki/Features/OCaml3.12
Also OCaml 3.11.2 and a small selection of libraries shipped with
RHEL 6.0 last November as an unsupported component. If you're a RHEL
subscriber you can get it from the 'Optional' channel in RHN.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-01/msg00218.html
Don Syme announced:
The F# team in Seattle/Redmond have an opening for a Senior Program
Manager. A demonstrated love for OCaml/F# programming would be highly
regarded background experience :)
We also have positions open for software development engineers
specializing in compilers and tools (see
https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=3&jid=34078&jlang=EN)
Kind regards & best wishes,
Don
The F# Team are Hiring!!!
- Do you have a love for modern, industry-leading programming technologies?
- Can you help us take the F# language to the next level?
- Do you have the vision to combine functional programming with
technologies for data, cloud, web, finance and technical computing?
- Do you have a passion for delivering great visual tools and a
simple, clear end-to-end experience for F# programmers?
- And do you want to work on a talented agile team that releases
compiler sources on codeplex.com and has originated major innovations
for C# and Visual Basic?
If so, we have a great opportunity for you!
The Visual Studio Pro team is looking for an experienced Program
Manager to drive the F# area. Partnering with your engineering team in
Redmond and Microsoft Research in Cambridge, you will define the F#
developer experience for Visual Studio and out of band releases such
as the F# PowerPack. As a strong customer advocate, you will drive
changes into the F# language, libraries and tools. You will develop
and update community programs that drive increased awareness and
adoption of F#. Being responsible for delivering integrated solutions,
you have experience in building strong cross-group partnerships,
ensuring alignment of schedules and business goals, and the natural
skill of getting things done.
Specific responsibilities include:
- Travelling to major conferences, user group meetings, and
enterprises to get people excited about solving problems using F#
- Defining the strategy for marketing F# to the developer community
- Owning our content strategy and community engagement programs
- Driving multiple concurrent projects for the F# team including
Visual Studio and out of band releases
- Working closely with groups within Microsoft such as Technical
Computing, .NET Framework, SQL and Azure to deliver great experiences
for F# developers
- Contributing to the design of all aspects of F# from language &
libraries to the tools that integrate with Visual Studio
Basic Qualifications:
- 3-5 years experience in Program Management or related experience,
including a proven track record of delivering on challenging projects
- A BS or equivalent degree in Computer Science, Electrical
Engineering, or a related field.
- Passionate for language and user experience design
- Knowledge of Visual Studio, .NET & functional programming languages,
and the ability to dig deep into technical challenges
- Strong sense of teamwork, personal integrity, responsibility and
accountability
- Excellent verbal and written communication skills
- Strong customer advocate, self-starter and problem solver
- Strong knowledge of F# or language design on managed platforms is
preferred
If you'd would like more details, please either contact me (dsyme AT
microsoft.com), or Sean Laberee (seanla AT microsoft.com) directly. To
apply immediately, please fill in the online forms and drop us a note
that you're applying.
https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=1&jid=33994&jlang=EN
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-01/msg00224.html
Matthias Puech announced:
Motivated by a recent discussion on the list, I wrote a small camlp5
syntax extension that allows to avoid the duplication of type
definitions between ml and mli. I thought it might be helpful to
someone one day. It adds two very simple constructions to the module
system:
* [mli] is a module type. If the current file has a .mli, [mli] is
expanded to the .mli's content.
* [types of S] is a module expression if S is a module type. It is
expanded to the structure containing all type declarations and module
types of S recursively (skipping [val]s etc.).
Restriction: S has to be a [sig ... end] or a [S with ...] construct
(because it is done within camlp5)
These two allow to include the contents of a mli into a ml and perform
instantiations of abstract types (see examples below). You can find
the extension (70 lines of code) together with tests at:
git clone http://helm.cs.unibo.it/~puech/repos/typdef.git
Hope it helps! Cheers,
-m
<simple.mli>
type t = A
val x : t
<simple.ml>
include types of mli
let x = A
<test.mli>
type t
module M : sig
type u
end
val x : M.u
<test.ml>
include types of mli with
type t = int
type M.u = string
let x = "hello"
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/.
Canonical Effective Subalgebras of Classical Algebras as Constructive Metric Completions:
http://math.andrej.com/2011/01/24/canonical-effective-subalgebras-of-classical-algebras-as-constructive-metric-completions/
Surikata:
https://forge.ocamlcore.org/projects/surikata/
Alg:
http://math.andrej.com/2011/01/22/alg/
Caml Foreign dynamic interface to C/C++:
https://forge.ocamlcore.org/projects/caml-foreign/
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.