IFL 2009 | 2 Aug 2009 15:30
Favicon

IFL 2009: Call for Papers and Participation

Call for Papers and Participation
IFL 2009
Seton Hall University
SOUTH ORANGE, NJ, USA
http://tltc.shu.edu/blogs/projects/IFL2009/

Register at: http://tltc.shu.edu/blogs/projects/IFL2009/registration.html


***** NEW *****

Registration and talk submission extended to August 23, 2009!


***************


The 21st International Symposium on Implementation and Application of Functional Languages, IFL 2009, will be held
for the first time in the USA. The hosting institution is Seton Hall University in South Orange, NJ, USA and the
symposium dates are September 23-25, 2009. It is our goal to make IFL a regular event held in the USA and in
Europe. The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and
application of functional and function-based programming languages. IFL 2009 will be a venue for researchers to
present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the
implementation and application of functional languages and function-based programming.

Following the IFL tradition, IFL 2009 will use a post-symposium review process to produce a formal proceedings which
will be published by Springer in the Lecture Notes in Computer Science series. All participants in IFL 2009 are
invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium.
These submissions will be screened by the program committee chair to make sure they are within the scope of IFL and will
appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not
peer-reviewed publications. After the symposium, authors will be given the opportunity to incorporate the feedback from
discussions at the symposium and will be invited to submit a revised full arcticle for the formal review process. These
revised submissions will be reviewed by the program committee using prevailing academic standards to select the best
articles that will appear in the formal proceedings.


Invited Speaker:

    Benjamin C. Pierce
    University of Pennsylvania
    Talk Title: How To Build Your Own Bidirectional Programming Language


TOPICS

IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools.
If you are not sure if your work is appropriate for IFL 2009, please contact the PC chair at ifl2009 <at> shu.edu. Topics of
interest include, but are not limited to:

 language concepts
 type checking
 contracts
 compilation techniques
 staged compilation
 runtime function specialization
 runtime code generation
 partial evaluation 
 (abstract) interpretation
 generic programming techniques
 automatic program generation
 array processing
 concurrent/parallel programming
 concurrent/parallel program execution
 functional programming and embedded systems
 functional programming and web applications
 functional programming and security
 novel memory management techniques
 runtime profiling and performance measurements
 debugging and tracing
 virtual/abstract machine architectures
 validation and verification of functional programs  
 tools and programming techniques
 FP in Education


PAPER SUBMISSIONS

Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to
present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series
format and not exceed 16 pages. The draft proceedings will appear as a technical report of the Department of Mathematics
and Computer Science of Seton Hall University.


IMPORTANT DATES

Registration deadline                   August 15, 2009
Presentation submission deadline        August 15, 2009
IFL 2009 Symposium                      September 23-25, 2009
Submission for review process deadline  November 1, 2009
Notification Accept/Reject              December 22, 2009
Camera ready version                    February 1, 2010


PROGRAM COMMITTEE

Peter Achten              University of Nijmegen, The Netherlands
Jost Berthold             Philipps-Universität Marburg, Germany
Andrew Butterfield        University of Dublin, Ireland
Robby Findler             Northwestern University, USA
Kathleen Fisher           AT&T Research, USA
Cormac Flanagan           University of California at Santa Cruz, USA
Matthew Flatt             University of Utah, USA
Matthew Fluet             Toyota Technological Institute at Chicago, USA
Daniel Friedman           Indiana University, USA
Andy Gill                 University of Kansas, USA
Clemens Grelck            University of Amsterdam/Hertfordshire, The Netherlands/UK
Jurriaan Hage             Utrecht University, The Netherlands
Ralf Hinze                Oxford University, UK
Paul Hudak                Yale University, USA
John Hughes               Chalmers University of Technology, Sweden
Patricia Johann           University of Strathclyde, UK
Yukiyoshi Kameyama        University of Tsukuba, Japan
Marco T. Morazán (Chair)  Seton Hall University, USA
Rex Page                  University of Oklahoma, USA
Fernando Rubio            Universidad Complutense de Madrid, Spain
Sven-Bodo Scholz          University of Hertfordshire, UK
Manuel Serrano            INRIA Sophia-Antipolis, France
Chung-chieh Shan          Rutgers University, USA
David Walker              Princeton University, USA
Viktória Zsók             Eötvös Loránd University, Hungary


PETER LANDIN PRIZE

The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected
by the program committee based on the submissions received for the formal review process. The prize carries a cash award
equivalent to 150 euros.

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Björn Pelzer | 4 Aug 2009 15:39
Picon
Favicon

Understanding GC and Alarms

Hello,

I'm new to this list and fairly new to OCaml. First I posted this on the 
beginner's list, but I was recommended to try it here, so here we go. :-)

Right now I'm having some problems with the garbage collector and the 
Gc.alarm - this combination shows some (to me) odd behaviours which are 
not detailed in the reference manual. Maybe someone could shed some 
light on this?

Basically, at the end of a major GC cycle the GC calls the user 
functions defined for any alarms. This I understand, and for the most 
part it works as I expect it.

The first oddity is that I can define an alarm function which starts
another GC cycle (by calling Gc.full_major). This results, quite
understandably, in an infinite loop - GC calls alarm calls GC calls 
alarm....
However, it seems that the GC no longer works quite the same when called 
from within an alarm, as it no longer calls any finalisation functions. 
Normally (outside alarms) the GC will print "Calling finalisation 
functions. Done calling finalisation functions." if I do a Gc.full_major 
and the verbosity is set appropriately. With the alarm loop, the GC will 
only print the first part ("Calling finalisation functions.") once at 
the start of the loop and then begin looping, starting new cycles but no 
new finalisations. If I limit the looping with a counter, the GC will 
behave normally again in future GC cycles outside the alarm. So it seems 
the alarm or the finalising put the GC into a special mode where it no 
longer does everything in a cycle that it would usually do.(?)

The other (and to me more severe) oddity is that if the alarm function 
raises an exception, then the GC seems to remain in its "special mode" 
where it starts no finalisation calling - but now it will also refuse to 
do any alarms.
The latter is a bit of a problem for me right now, as I was using a 
Gc.alarm to implement a check for a memory limit: if the alarm function 
at the end of a GC cycle finds the memory usage to be above the limit, 
an exception is raised which interrupts the normal operation of the 
program, and the program waits for instructions from stdin.

As the first such exception-from-an-alarm effectively breaks future 
alarm handling, this only works once. This was not noticeable in earlier 
versions of the program which were single-use only - the alarm exception 
would halt the program and say sorry, out of memory. The new program 
version is supposed to be user-interactive, though, so it must be able 
to catch multiple memory excesses. Worse, it also uses Unix.ITIMER_REAL 
induced timer exceptions to limit processing time. Potentially such a 
timer exception could also interrupt an alarm check, again breaking the 
alarm handling.

Is there a way to get the GC back to normal after an exception during 
the alarm? Right now it seems I have to drop alarm usage entirely, and 
instead put explicit memory checks into all sorts of strategic places 
throughout the program, which is not all that elegant.

Here is a short program which shows what I mean. I'm probably just 
making some stupid mistake?

exception Ex

let main () =
    let cnt = ref 0
    in
    (Gc.set {(Gc.get()) with Gc.verbose = 0x081});
    let alarm_function () =
       (print_endline "Alarm!";
       cnt := !cnt + 1;
(* do 3 loop iterations *)
       if !cnt < 3 then
          (Gc.full_major ())
(* after the 3rd iteration, exit loop with an exception *)
       else
          (raise Ex))
       in
          ignore (Gc.create_alarm alarm_function);
          try
(* this will call the alarm and start the loop *)
             (Gc.full_major ())
          with
             | Ex ->
                (print_endline "Exception raised!";
(* new GC cycle calls no alarm after the exception :-( *)
                Gc.full_major ())

let () = main ();;

Thank you for your time,
Björn

--

-- 
Björn Pelzer
AGKI - Artificial Intelligence Research Group
University Koblenz-Landau, B 225
http://www.uni-koblenz.de/~bpelzer

Tel.(office): (+49) 261 287 2776
Tel.(home): (+49) 261 942 3908

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Damien Doligez | 5 Aug 2009 16:33
Picon
Picon
Favicon

Re: Understanding GC and Alarms

Hello,

On 2009-08-04, at 15:39, Björn Pelzer wrote:

> With the alarm loop, the GC will only print the first part ("Calling  
> finalisation functions.") once at the start of the loop and then  
> begin looping, starting new cycles but no new finalisations.

Yes, the GC calls the finalisation functions in order, so it waits for  
your
finalisation function to finish before starting the next one.  If your
function doesn't terminate...

> The other (and to me more severe) oddity is that if the alarm  
> function raises an exception, then the GC seems to remain in its  
> "special mode" where it starts no finalisation calling - but now it  
> will also refuse to do any alarms.

Yes, that is the essence of bug report 4742:
< http://caml.inria.fr/mantis/view.php?id=4742 >

> Is there a way to get the GC back to normal after an exception  
> during the alarm?

That is the purpose of the Gc.finalise_release function: tell the GC  
to behave
as if the current finalisation function had finished.  Note that  
finalise_release
is also safe to call from outside a finalisation function, so you can  
call it
from your exception handler.

When bug 4742 is fixed (probably in 3.12.0), you won't need it any more.
Note that I wanted to fix it by ignoring the exception entirely, but
your use case made me change my mind.

-- Damien

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Björn Pelzer | 5 Aug 2009 17:04
Picon
Favicon

Re: Understanding GC and Alarms

Hello Damien!

Damien Doligez wrote:
> Yes, the GC calls the finalisation functions in order, so it waits for your
> finalisation function to finish before starting the next one.  If your
> function doesn't terminate...
> 

Ok, makes sense.

>> Is there a way to get the GC back to normal after an exception during 
>> the alarm?
> 
> That is the purpose of the Gc.finalise_release function: tell the GC to 
> behave
> as if the current finalisation function had finished.  Note that 
> finalise_release
> is also safe to call from outside a finalisation function, so you can 
> call it
> from your exception handler.

Thank you very much! Very helpful, works as you say.
In hindsight I should have figured this out from the manual, but, well, 
I didn't. :-)

> When bug 4742 is fixed (probably in 3.12.0), you won't need it any more.
> Note that I wanted to fix it by ignoring the exception entirely, but
> your use case made me change my mind.

Sounds good, keeping the exception handling would be useful, at least 
for me. Using the release-function as you explained is not much of a 
bother, in particular now that I get how it works, so there is no 
pressing need for a change/bugfix from my side.

Thanks again and best regards,
Björn

--

-- 
Björn Pelzer
AGKI - Artificial Intelligence Research Group
University Koblenz-Landau, B 225
http://www.uni-koblenz.de/~bpelzer

Tel.(office): (+49) 261 287 2776
Tel.(home): (+49) 261 942 3908

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Zorg 421 | 6 Aug 2009 09:42
Picon

Re: book "Le langage Caml"

Great ! I don't need to steel it from my local technical library anymore !

;-)

Thanks.

On Mon, Jul 20, 2009 at 11:06 AM, Xavier Leroy<Xavier.Leroy <at> inria.fr> wrote:
> A few months ago, there was a discussion on this list about
> "Le langage Caml", an early book on Caml (Light) programming written
> by Pierre Weis and I.  The book was out of print, but the publisher,
> Dunod Éditions, graciously agreed to relinquish its rights and give
> them back to the authors.
>
> Pierre and I are therefore happy to announce that the full text of the
> book (2nd edition) is now available freely:
>
>   http://caml.inria.fr/pub/distrib/books/llc.pdf
>
> There was a companion book, "Manuel de référence du langage Caml",
> which is the French translation of the Caml Light 0.7 reference
> manual.  For completeness, we also made it available:
>
>  http://caml.inria.fr/pub/distrib/books/manuel-cl.pdf
>
> Both texts are distributed under the Creative Commons BY-NC-SA
> license.
>
> Enjoy,
>
> - Xavier Leroy
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

ChoJin | 6 Aug 2009 13:16
Picon
Picon
Picon

OCamlMakefile, menhir and its --infer option

Hello,

I have an issue while using OCamlMakefile, menhir and its --infer  
option.

I have something along those lines:

OCAMLYACC = menhir

SOURCES = \
	parser/ir.ml \
	parser/parser.mly \
	parser/lexer.mll \
	main.ml

[...]

like this, everything is fine. But then, if I start using menhir  
features such as %inline or the standard library, menhir advises to  
use the --infer option

hence the added

YFLAGS = --infer

variable in the Makefile

The issue I have is that no matter what, OCamlMakefile runs menhir  
before compiling parser/ir.ml, yielding to a "Unbound module Ir" since  
my parser.mly is trying to "open Ir".
Looking at OCamlMakefile source, it seems to come from the PRE_TARGETS  
variable which always compiles .mly first.

So my question is: what is the proper way of doing it ? Should I just  
drop the --infer menhir's option or is there a better way?

--

-- 
Best Regards,
ChoJin

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Erik de Castro Lopo | 6 Aug 2009 23:17
Favicon

C wrappers and callbacks from Ocaml to C and back to Ocaml

Hi all,

I'm wrapping some C code that requires me to define a struct in Ocaml
like this:

    type xt = { f : xt -> a }

and then pass the struct to C which stores it, and later the C needs
to find function f, call it from C, passing it the Ocaml xt struct.

Anyone have any clues on how to do this? I have most of the rest of
the C wrapper sorted out,  its just this thats causing me any difficulty.

Cheers,
Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Goswin von Brederlow | 7 Aug 2009 01:38
Picon

Re: C wrappers and callbacks from Ocaml to C and back to Ocaml

Erik de Castro Lopo <mle+ocaml <at> mega-nerd.com> writes:

> Hi all,
>
> I'm wrapping some C code that requires me to define a struct in Ocaml
> like this:
>
>     type xt = { f : xt -> a }
>
> and then pass the struct to C which stores it, and later the C needs
> to find function f, call it from C, passing it the Ocaml xt struct.
>
> Anyone have any clues on how to do this? I have most of the rest of
> the C wrapper sorted out,  its just this thats causing me any difficulty.
>
> Cheers,
> Erik

Well, you just do. A structure is a value like anything else.

What you have to wath out for is the GC. If you store the value
somewhere then you have to tell the GC about it by registering it as a
new root. And when you are done with it you need to unregister it.

As for access the docs tell you about how to access fields of a record
and also how to invoke a ocaml closure from C. Just read the relevant
sections from the chapter about interfacing ocaml and C.

MfG
        Goswin

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Erik de Castro Lopo | 7 Aug 2009 06:23
Favicon

Re: C wrappers and callbacks from Ocaml to C and back to Ocaml

Goswin von Brederlow wrote:

> Well, you just do. A structure is a value like anything else.

Yes, with a bit of careful debugging I managed to get a bit further
and even managed to extract (in the C code) the Ocaml function from
the Ocaml struct and I think I can call it, but I haven't test that
yet.

> What you have to watch out for is the GC.

This is what I was worried about :-).

> If you store the value
> somewhere then you have to tell the GC about it by registering it as a
> new root. And when you are done with it you need to unregister it.

Ah yes, the following two functions in <caml/memory.h>:

    CAMLextern void caml_register_global_root (value *);
    CAMLextern void caml_remove_global_root (value *);

Cheers,
Erik
--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Christoph Bauer | 7 Aug 2009 09:43

windows, threads and sockets

Hi,

I'm using OCaml 3.11.0. My question is about my program,
which used to work fine under windows and linux. The program
is a daemon, which waits for socket connections and respondse
to queries.

Now I added an extension with uses threads. Everything is
find on linux, but I have a very strange behaviour on windows.
For the troubles it is sufficient to link agains threads and compile the
main program with -thread. Without it everything is fine again.

I'm not quite sure what is going on, but my best bet is this: the main
loop waits for the sockets with

Unix.select listOfSockets [] [] timeout

One socket is the listener socket on which new connections 
are made. Unix.select returns a list of sockets. Initially
it must be the listener socket. This is checked with a compare

  socket = listenSocket 

and this seems to be suddenly wrong (just in the thread case).

Any ideas?

Thanks,

Christoph Bauer

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


Gmane