[Caml-list] 4th International Conference on Model & Data Engineering (MEDI 2014): Third Call for Papers

*** THIRD CALL FOR PAPERS *** (extended deadlines) 4th INTERNATIONAL CONFERENCE ON MODEL & DATA ENGINEERING (MEDI 2014) Lordos Beach Hotel, Larnaca, Cyprus 24-26 September, 2014 http://medi2014.cs.ucy.ac.cy/ The main objective of the conference is to provide a forum for the dissemination of research accomplishments and to promote the interaction and collaboration of research communities issued from modelling and system modelling on the one hand and data and data modelling on the other hand. MEDI 2014 provides an international infrastructure for the presentation of research results and experimentations on models and data theory, development of advanced technologies related to models and data and their advanced applications and case studies. This international scientific event, initiated by researchers from Euro-Mediterranean countries, aims also at promoting the creation of north-south scientific networks, projects and faculty/student exchanges and of other parts of the world as well. Keynote Speakers Mukesh Mohania, IBM India: Talk on the data side Dominique Mery, Loria, Nancy, France: Talk on the model side Aim and Scope Specific areas of interest to MEDI'2014 include but are not limited to: Modelling and Models Engineering: - Design of General-purpose Modelling Languages and Related Standards - Model Driven Engineering, Modelling Languages, Meta-modelling, Model Transformation, Model Evolution: - Formal Modelling, Verification and Validation, Analysis, Testing - Ontology Based Modelling, Role of Ontologies in Modelling Activities - Model Manipulation and models as first objects - Heterogeneous modelling, model integration and interoperability - Applications and case studies Data Engineering: - Heterogeneous data, data Integration and Interoperability - Distributed, Parallel, Grid, Peer to Peer, Cloud Databases - Data Warehouses and OLAP, Data Mining - Database System Internals, Performance, Self-tuning Benchmarking and Testing - Database Security, Personalization, Recommendation - Web Databases, Ontology Based Databases, PDMS - Applications and case studies Modeling for Data Management: - New Models and Architectures for Databases and Data Warehouses - Modeling and Quality of Data - Modeling for Enhancing Sharing Data - Models for Explicit and Implicit Semantics based Data Optimization - Model Reification, Model Repositories - Modeling Non Functional Properties of Systems - Data as models and Models as Data - Service based data management and service oriented applications - Models for data Monitoring - Urbanization of Database Applications Applications and tooling: - Industry transfer, experiences - Data and Model manipulation and tooling - Modelling tools and experimentation Conference Location Lordos Beach Hotel, Larnaca https://www.lordosbeach.com.cy/en/ Submission Guidelines and Instructions Authors are invited to submit research and application papers representing original, previously unpublished work. Papers should be submitted in PDF or Word format. Submissions must conform to Springer's LNCS format and should not exceed 12 pages (including all text, figures, references and appendices). Authors who want to buy extra pages may submit a paper up to 15 pages with the indication that the authors will purchase extra pages if the paper is accepted. Submissions which do not conform to the LNCS format and/or which do exceed 12 pages (or up to 15 pages with the extra page purchase commitment) will be rejected without reviews. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. All accepted papers will be published in Lecture Notes in Computer Science (LNCS) by Springer-Verlag. Duplicate submissions are not allowed. A submission is considered to be a duplicate submission if it is submitted to other conferences/workshops/journals or it has been already accepted to be published in other conferences/workshops/journals. Duplicate submissions thus will be automatically rejected without reviews. Submissions require explicit consent from all listed authors. Important Dates Abstract submission: April 28, 2014 (extended deadline) Full-paper submission: May 9, 2014 (extended deadline) Acceptance notification: June 16, 2014 Camera Ready: July 7, 2014 Paper Publication All accepted papers will be published in Lecture Notes in Computer Science (LNCS) by Springer-Verlag. Best papers will be invited for submission in a special issue of the Future Generation Computer Systems (Elsevier), the International Journal of Cooperative Information Systems (World Scientific) and Fundamenta Informaticae (IOS Press). Keynotes Speakers Mukesh MOHANIA, IBM, INDIA : Data and Data models Dominique MERY, Loria, Nancy, France: Models and system modelling Conference Organization General Chairs Ladjel Bellatreche, ENSMA, Poitiers University, France George A. Papadopoulos, Department of Computer Science, University of Cyprus Programme Committee Chair Yamine Aït Ameur, ENSEEIHT/IRIT, Toulouse, France Local Organizing Chair Mr. Petros Stratis (EasyConferences, LTD), Finance Chair Program Committee http://medi2014.cs.ucy.ac.cy/committes.html For further inquiries, contact the MEDI 2014 PC Chair: Yamine Aït Ameur (yamine@n7.fr)

-------------------------------------------------------------------- This is not SPAM. If you want to be removed from this list, please send an email to [announce@cs.ucy.ac.cy] with the single word 'remove' in the subject of the email.

[Caml-list] FLOPS 2014 call for participation (June 4-6, Kanazawa, Japan; early registration deadline on May 13)

Dear colleagues,

The registration for FLOPS 2014 (Twelfth International Symposium on
Functional and Logic Programming, June 4-6, Kanazawa, Japan) is now
open: http://www.jaist.ac.jp/flops2014/registration.html

- Early registration deadline on May 13, 2014
- Program http://www.jaist.ac.jp/flops2014/program.html with invited
talks by Ranjit Jhala, Shin-ya Katsumata, and Gabriele Keller
- Sponsored by JSSST SIGPPL; in cooperation with ACM SIGPLAN, AAFS, and ALP
- Proceedings to be published as LNCS 8475
- Hyakuman-goku Matsuri Festival
http://www.kanazawa-tourism.com/eng/event/event2.php on the day after
the symposium (June 7); accommodation can be extended on request basis
via the registration site (use the comments field)
- See http://www.jaist.ac.jp/flops2014/ for more information

Thank you!

FLOPS 2014 Program Co-Chairs
Michael Codish and Eijiro Sumii

--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Ocaml compiler documentation

> 1. What is the difference between an extension and an attribute? From what I
> understand, they are both means of integrating additional metadata into the
> AST that can then be parsed by implementations of the ast-mapper, but why
> are there 2 mechanisms?

Attributes are supposed to be "optional" information attached to
existing AST nodes:
let@shadow x = e1 in e2

If you erase attributes, you get back a valid AST. The implicit
contract that syntax-extension designers that use attributes ought to
respect is that the presence of attributes should not change the
semantics of the underlying code (but it can direct additional code
generation, etc.): at first approximation it should be possible to
read the code without attributes, understand what it means, and then
refine one's understanding with knowledge of the particular attributes
used.

The compiler can ignore unknown attributes.

On the contrary, extensions are AST nodes by themselves: [% foo] is an
expression (when used in an expression position). If you erase the
extension, you get an invalid AST with a missing hole. They are
designed for situations where it makes no sense to forget about the
extended-syntax part.

For more information, see
https://github.com/ocaml/ocaml/blob/trunk/experimental/frisch/extension_points.txt


On Thu, Apr 3, 2014 at 4:48 AM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> Ok I think a good place to start a tour of the compiler is in
> parsing/parsetree.mli. This file is actually very well documented, with
> terse but effective examples of almost every constructor and type.
>
> I had to refer to the OCaml manual for a few of the corner cases. For
> example, I didn't know about the #class type shortcut. I think a few
> comments explaining the more obscure facets of the language could be
> helpful.
>
> Since the file is so well documented, I only have a few questions. I'll
> accept an answer or a hunch from anyone -- don't feel shy because you think
> you're not sure about the answer:
>
> 1. What is the difference between an extension and an attribute? From what I
> understand, they are both means of integrating additional metadata into the
> AST that can then be parsed by implementations of the ast-mapper, but why
> are there 2 mechanisms?
>
> 2. What is demonstrated in lines 114-117 regarding polymorphic variant row
> fields:
>
> | Rtag of label * bool * core_type list
> (* [`A] ( true, [] )
> [`A of T] ( false, [T] )
> [`A of T1 & .. & Tn] ( false, [T1;...Tn] )
> [`A of & T1 & .. & Tn] ( true, [T1;...Tn] )
> *)
>
> What does the bool value represent?
> Why are the type separators in the comments using the & symbol?
> What is the difference between the 3rd and 4th example?
>
> 3. line 684: what is the purpose of the override flag on Pstr_open? It's not
> explained by the comment.
>
> 4. The toplevel phrases are not clear. What is the purpose of Ptop_dir on
> line 721?
>
> Like I said, feel free to jump in and answer any one of these questions.
>
> Thanks in advance for everyone's help
>
> -Yotam
>
>
>
>
> On Tue, Apr 1, 2014 at 6:03 AM, Mark Shinwell <mshinwell@janestreet.com>
> wrote:
>>
>> I would suggest that it's probably better to keep the documentation as
>> comments where possible. However, I think it is important to avoid
>> excessive commentary, especially if it is likely to get out of sync as
>> a result of future modifications to the code. It may be that in some
>> cases making alterations to the code (for example, improving the name
>> of a variable) is a more satisfactory approach than adding a comment.
>>
>> Thanks for working on this.
>>
>> Mark
>>
>> On 31 March 2014 18:51, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
>> > I think it depends on how much feedback I get on any particular
>> > question. By
>> > default, I would like comments to go in the code. Additionally, there's
>> > the
>> > ocaml-internals wiki at https://github.com/ocamllabs/ocaml-internals
>> > which
>> > will be useful for any concepts that span multiple files, or that are
>> > too
>> > beginner-oriented. I'm guessing that for many things, it will just have
>> > to
>> > be decided on a case-by-case basis.
>> >
>> > Of course, the most important ingredient for the success of this
>> > 'project'
>> > is the willing, patient participation of the core team, as well as the
>> > other
>> > experts on this list.
>> >
>> > -Yotam
>> >
>> >
>> > On Mon, Mar 31, 2014 at 1:06 PM, Milan Stanojević <milanst@gmail.com>
>> > wrote:
>> >>
>> >> Thank you for doing this, I'm interested in learning more about how
>> >> compiler works.
>> >>
>> >> Are you creating a separate file(s) to document the compiler or you
>> >> are adding comments to ml files?
>> >>
>> >> On Mon, Mar 31, 2014 at 11:39 AM, Yotam Barnoy <yotambarnoy@gmail.com>
>> >> wrote:
>> >> > Hi everybody
>> >> >
>> >> > It's been mentioned before that the OCaml compiler's documentation is
>> >> > somewhat lacking. I've been going over the compiler code gradually
>> >> > (both
>> >> > the
>> >> > frontend and the backend) and while some parts are understandable
>> >> > enough,
>> >> > others are missing some basic explanations. Some explanations are
>> >> > also
>> >> > spread out throughout the codebase, making it hard to know what
>> >> > something
>> >> > means unless you've read another part of the codebase that relates to
>> >> > it.
>> >> >
>> >> > Since the call to submit documentation commits has gone mostly
>> >> > unanswered,
>> >> > I'd like to suggest a method of making both my own progress through
>> >> > the
>> >> > code
>> >> > easier and hopefully making it easier for others who will follow.
>> >> >
>> >> > What I'm going to do is, focusing on more or less one file at a time,
>> >> > I'll
>> >> > post newbie questions to the list about the code. Once I'm satisfied
>> >> > that I
>> >> > have a good enough understanding, I'll add comments to the
>> >> > aforementioned
>> >> > files and submit pull requests for them. I also encourage others to
>> >> > do
>> >> > the
>> >> > same.
>> >> >
>> >> > What I need from the list, and especially from the more knowledgeable
>> >> > members (who already know the compiler code) is the willingness to
>> >> > explain
>> >> > the concepts and answer my questions, annoying as they may be. I have
>> >> > a
>> >> > pretty decent background in compilers, ASTs, code generation, etc,
>> >> > but
>> >> > not
>> >> > so much in type inference.
>> >> >
>> >> > I'm not suggesting a particular timeframe for this process -- I'm
>> >> > doing
>> >> > this
>> >> > on the side while working on a research project and TAing, but I
>> >> > really
>> >> > would like to get to the point where I can make significant
>> >> > contributions to
>> >> > the toolchain, and if I can help others who follow in my footsteps,
>> >> > then
>> >> > that's a nice bonus.
>> >> >
>> >> > While I could have skipped this introduction and just proceeded with
>> >> > inundating the list with questions, I felt that this (hopefully)
>> >> > gives a
>> >> > purpose and perhaps motivation for those who have the answers to
>> >> > answer
>> >> > my
>> >> > questions even if they get annoying. In particular, I may often miss
>> >> > some
>> >> > parts that may seem obvious because I don't necessarily have the time
>> >> > to
>> >> > read all the connected code in depth. Hopefully you'll bear with me.
>> >> >
>> >> > Does this sound reasonable to the fine folks on the list?
>> >> >
>> >> > Yotam
>> >
>> >
>
>

--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Ocaml compiler documentation

Ok I think a good place to start a tour of the compiler is in parsing/parsetree.mli. This file is actually very well documented, with terse but effective examples of almost every constructor and type.

I had to refer to the OCaml manual for a few of the corner cases. For example, I didn't know about the #class type shortcut. I think a few comments explaining the more obscure facets of the language could be helpful.

Since the file is so well documented, I only have a few questions. I'll accept an answer or a hunch from anyone -- don't feel shy because you think you're not sure about the answer:

1. What is the difference between an extension and an attribute? From what I understand, they are both means of integrating additional metadata into the AST that can then be parsed by implementations of the ast-mapper, but why are there 2 mechanisms?

2. What is demonstrated in lines 114-117 regarding polymorphic variant row fields:

  | Rtag of label * bool * core_type list
        (* [`A]                   ( true,  [] )
           [`A of T]              ( false, [T] )
           [`A of T1 & .. & Tn]   ( false, [T1;...Tn] )
           [`A of & T1 & .. & Tn] ( true,  [T1;...Tn] )
         *)

What does the bool value represent?
Why are the type separators in the comments using the & symbol?
What is the difference between the 3rd and 4th example?

3. line 684: what is the purpose of the override flag on Pstr_open? It's not explained by the comment.

4. The toplevel phrases are not clear. What is the purpose of Ptop_dir on line 721?

Like I said, feel free to jump in and answer any one of these questions.

Thanks in advance for everyone's help

-Yotam

On Tue, Apr 1, 2014 at 6:03 AM, Mark Shinwell <mshinwell@janestreet.com> wrote:

I would suggest that it's probably better to keep the documentation as
comments where possible.  However, I think it is important to avoid
excessive commentary, especially if it is likely to get out of sync as
a result of future modifications to the code.  It may be that in some
cases making alterations to the code (for example, improving the name
of a variable) is a more satisfactory approach than adding a comment.

Thanks for working on this.

Mark

On 31 March 2014 18:51, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> I think it depends on how much feedback I get on any particular question. By
> default, I would like comments to go in the code. Additionally, there's the
> ocaml-internals wiki at https://github.com/ocamllabs/ocaml-internals which
> will be useful for any concepts that span multiple files, or that are too
> beginner-oriented. I'm guessing that for many things, it will just have to
> be decided on a case-by-case basis.
>
> Of course, the most important ingredient for the success of this 'project'
> is the willing, patient participation of the core team, as well as the other
> experts on this list.
>
> -Yotam
>
>
> On Mon, Mar 31, 2014 at 1:06 PM, Milan Stanojević <milanst@gmail.com> wrote:
>>
>> Thank you for doing this, I'm interested in learning more about how
>> compiler works.
>>
>> Are you creating a separate file(s) to document the compiler or you
>> are adding comments to ml files?
>>
>> On Mon, Mar 31, 2014 at 11:39 AM, Yotam Barnoy <yotambarnoy@gmail.com>
>> wrote:
>> > Hi everybody
>> >
>> > It's been mentioned before that the OCaml compiler's documentation is
>> > somewhat lacking. I've been going over the compiler code gradually (both
>> > the
>> > frontend and the backend) and while some parts are understandable
>> > enough,
>> > others are missing some basic explanations. Some explanations are also
>> > spread out throughout the codebase, making it hard to know what
>> > something
>> > means unless you've read another part of the codebase that relates to
>> > it.
>> >
>> > Since the call to submit documentation commits has gone mostly
>> > unanswered,
>> > I'd like to suggest a method of making both my own progress through the
>> > code
>> > easier and hopefully making it easier for others who will follow.
>> >
>> > What I'm going to do is, focusing on more or less one file at a time,
>> > I'll
>> > post newbie questions to the list about the code. Once I'm satisfied
>> > that I
>> > have a good enough understanding, I'll add comments to the
>> > aforementioned
>> > files and submit pull requests for them. I also encourage others to do
>> > the
>> > same.
>> >
>> > What I need from the list, and especially from the more knowledgeable
>> > members (who already know the compiler code) is the willingness to
>> > explain
>> > the concepts and answer my questions, annoying as they may be. I have a
>> > pretty decent background in compilers, ASTs, code generation, etc, but
>> > not
>> > so much in type inference.
>> >
>> > I'm not suggesting a particular timeframe for this process -- I'm doing
>> > this
>> > on the side while working on a research project and TAing, but I really
>> > would like to get to the point where I can make significant
>> > contributions to
>> > the toolchain, and if I can help others who follow in my footsteps, then
>> > that's a nice bonus.
>> >
>> > While I could have skipped this introduction and just proceeded with
>> > inundating the list with questions, I felt that this (hopefully) gives a
>> > purpose and perhaps motivation for those who have the answers to answer
>> > my
>> > questions even if they get annoying. In particular, I may often miss
>> > some
>> > parts that may seem obvious because I don't necessarily have the time to
>> > read all the connected code in depth. Hopefully you'll bear with me.
>> >
>> > Does this sound reasonable to the fine folks on the list?
>> >
>> > Yotam
>
>

[Caml-list] [TFPIE2014] final call for papers

3rd International Workshop on Trends in Functional Programming in
Education (TFPIE 2014)
May 25, 2014
Utrecht University
Soesterberg, The Netherlands
(http://www.cs.uwyo.edu/~jlc/tfpie14/)


The 3rd International Workshop on Trends in Functional Programming in
Education, TFPIE 2014, will be co-located with the Symposium on Trends
in Functional Programming (TFP 2014) at Soesterberg, at the "Kontakt der
Kontinenten" hotel in the Netherlands on Sunday, May 25th. TFP will
follow from May 26-28.


The goal of TFPIE is to gather researchers, teachers and professionals
that use, or are interested in the use of, functional programming in
education. TFPIE aims to be a venue where novel ideas, classroom-tested
ideas and work-in-progress on the use of functional programming in
education are discussed. The one-day workshop will foster a spirit of
open discussion by having a review process for publication after the
workshop. The program chair of TFPIE 2014 will screen submissions to
ensure that all presentations are within scope and are of interest to
participants. Potential presenters are invited to submit an extended
abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style.
The authors of accepted presentations will have their preprints and
their slides made available on the workshop's website/wiki. Visitors to
the TFPIE 2014 website/wiki will be able to add comments. This includes
presenters who may respond to comments and questions as well as provide
pointers to improvements and follow-up work. After the workshop,
presenters will be invited to submit (a revised version of) their
article for review. The PC will select the best articles for publication
in the journal Electronic Proceedings in Theoretical Computer Science
(EPTCS). Articles not selected for presentation and extended abstracts
will not be formally reviewed by the PC.

TFPIE workshops have previously been held in St Andrews, Scotland (2012)
and in Provo Utah, USA (2013).


** Invited Speaker **
TFPIE is pleased to announce that professor Johan Jeuring of Utrecht
University and Open University, both in The Netherlands is giving an
invited talk entitled: "Automatic tutoring and assessing functional
programs".


** Program Committee **

James Caldwell, (Program Chair) University of Wyoming
Peter Achten, Radboud University, Nijmgen
Edwin Brady, University of St Andrews, St Andrews
Jurriaan Hage, Universiteit Utrecht
Philip Holzenspies, University of Twente
Daniel R. Licata, Wesleyan University
Marco T Morazan, Seton Hall University
Christian Skalka, University of Vermont
David Van Horn, Northeastern University


** Submission Guidelines **

There will be two types of presentations at TFPIE 2014. Regular papers
and "best lecture" presentations. The best lecture talks are intended to
allow for presentations or short lectures of purely pedagogical
material. Papers and abstracts can be submitted via easychair at the
following link: https://www.easychair.org/conferences/?conf=tfpie2014


** Papers **

TFPIE 2014 welcomes submissions describing techniques used in the
classroom, tools used in and/or developed for the classroom and any
creative use of functional programming (FP) to aid education in or
outside Computer Science. Topics of interest include, but are not
limited to:

* FP and beginning CS students
* FP and Computational Thinking
* FP and Artificial Intelligence
* FP in Robotics
* FP and Music
* Advanced FP for undergraduates
* FP in graduate education
* Engaging students in research using FP
* FP in Programming Languages
* FP in the high school curriculum
* FP as a stepping stone to other CS topics
* FP and Philosophy


** Best Lectures **

In addition to papers, this year we are requesting "best lecture"
presentations. What's your best lecture topic in an FP related course?
Do you have a fun way to present FP concepts to novices or perhaps an
especially interesting presentation of a difficult topic? In either
case, please consider sharing it. Best lecture topics will be selected
for presentation based on a short abstract describing the lecture and
its interest to TFPIE attendees.


** Important Dates **

* 1 February 2014: TFPIE submissions open on easychair.
* 14 April 2014: Early registration for TFP closes
* 21 April 2014: Submission deadline for draft TFPIE papers and abstracts
* 27 April 2014: Notification of acceptance for presentation
* 15 May 2014: Registration for TFPIE closes - as does late registration
for TFP
* 25 May 2014: Presentations in Soesterberg, Netherlands
* 29 June 2014: Full papers for EPTCS proceedings due
* 16 August 2014: Notification of acceptance for proceedings
* 8 September 2014: Camera ready copy due for EPTCS

Submission of an abstract implies no obligation to submit a full paper;
abstracts with no corresponding full versions by the full paper deadline
will be considered as withdrawn. At least one author from each accepted
presentation must attend the workshop.


--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Caml-list] [TFP2014] First Call for Participation

---------------------------------
1ST CALL FOR PARTICIPATION
---------------------------------

======== TFP 2014 ===========

15th Symposium on Trends in Functional Programming
May 26-28, 2014
Utrecht University
Soesterberg, The Netherlands
http://www.cs.uu.nl/wiki/TFP2014/WebHome

Registration is now open for the symposium on Trends in Functional
Programming (TFP). It is an international forum for researchers with
interests
in all aspects of functional programming, taking a broad view of current
and
future trends in the area. It aspires to be a lively environment for
presenting
the latest research results. Submission for TFP is now closed, and the
complete
programme (29 presentations and two invited talks) for TFP can be
perused here:

http://www.cs.uu.nl/wiki/TFP2014/PresentationSchedule

TFP 2014 will be the main event of a pair of functional programming events.
The other is the International Workshop on Trends in Functional Programming
in Education (TFPIE). TFPIE will take place on May 25th. Its website is
located
at http://www.cs.uwyo.edu/~jlc/tfpie14/ . The submission deadline for TFPIE
is April 21, 2014.


INVITED SPEAKERS

TFP is pleased to announce talks by the following two invited speakers:

John Hughes of Chalmers, Goteborg, Sweden, is well-known as author of
Why Functional Programming Matters, and as one of the designers of
QuickCheck
(together with Koen Claessen); the paper on QuickCheck won the
ICFP Most Influential Paper Award in 2010. Currently he divides his time
between
his professorship and Quviq, a company that performs property-based
testing of
software with a tool implemented in Erlang.

Geoffrey Mainland received his PhD from Harvard University where he was
advised by Greg Morrisett and Matt Welsh. After a two year postdoc with the
Programming Principles and Tools group at Microsoft Research Cambridge,
he is
now an assistant professor at Drexel University. His research focuses on
high-level programming language and runtime support for non-general purpose
computation.

IMPORTANT DATES

Early registration: April 14, 2014
Late registration: May 15, 2014
TFPIE Workshop: May 25, 2014
TFP Symposium: May 26-28, 2014

Registrations can be made at the following URL:

http://www.cs.uu.nl/wiki/TFP2014/Register

This page will also point you to the web page of the venue where you can
arrange
for your stay.

hoping to see you there.
Jurriaan Hage (General Chair)


--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Ocaml compiler documentation

I would suggest that it's probably better to keep the documentation as
comments where possible. However, I think it is important to avoid
excessive commentary, especially if it is likely to get out of sync as
a result of future modifications to the code. It may be that in some
cases making alterations to the code (for example, improving the name
of a variable) is a more satisfactory approach than adding a comment.

Thanks for working on this.

Mark

On 31 March 2014 18:51, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
> I think it depends on how much feedback I get on any particular question. By
> default, I would like comments to go in the code. Additionally, there's the
> ocaml-internals wiki at https://github.com/ocamllabs/ocaml-internals which
> will be useful for any concepts that span multiple files, or that are too
> beginner-oriented. I'm guessing that for many things, it will just have to
> be decided on a case-by-case basis.
>
> Of course, the most important ingredient for the success of this 'project'
> is the willing, patient participation of the core team, as well as the other
> experts on this list.
>
> -Yotam
>
>
> On Mon, Mar 31, 2014 at 1:06 PM, Milan Stanojević <milanst@gmail.com> wrote:
>>
>> Thank you for doing this, I'm interested in learning more about how
>> compiler works.
>>
>> Are you creating a separate file(s) to document the compiler or you
>> are adding comments to ml files?
>>
>> On Mon, Mar 31, 2014 at 11:39 AM, Yotam Barnoy <yotambarnoy@gmail.com>
>> wrote:
>> > Hi everybody
>> >
>> > It's been mentioned before that the OCaml compiler's documentation is
>> > somewhat lacking. I've been going over the compiler code gradually (both
>> > the
>> > frontend and the backend) and while some parts are understandable
>> > enough,
>> > others are missing some basic explanations. Some explanations are also
>> > spread out throughout the codebase, making it hard to know what
>> > something
>> > means unless you've read another part of the codebase that relates to
>> > it.
>> >
>> > Since the call to submit documentation commits has gone mostly
>> > unanswered,
>> > I'd like to suggest a method of making both my own progress through the
>> > code
>> > easier and hopefully making it easier for others who will follow.
>> >
>> > What I'm going to do is, focusing on more or less one file at a time,
>> > I'll
>> > post newbie questions to the list about the code. Once I'm satisfied
>> > that I
>> > have a good enough understanding, I'll add comments to the
>> > aforementioned
>> > files and submit pull requests for them. I also encourage others to do
>> > the
>> > same.
>> >
>> > What I need from the list, and especially from the more knowledgeable
>> > members (who already know the compiler code) is the willingness to
>> > explain
>> > the concepts and answer my questions, annoying as they may be. I have a
>> > pretty decent background in compilers, ASTs, code generation, etc, but
>> > not
>> > so much in type inference.
>> >
>> > I'm not suggesting a particular timeframe for this process -- I'm doing
>> > this
>> > on the side while working on a research project and TAing, but I really
>> > would like to get to the point where I can make significant
>> > contributions to
>> > the toolchain, and if I can help others who follow in my footsteps, then
>> > that's a nice bonus.
>> >
>> > While I could have skipped this introduction and just proceeded with
>> > inundating the list with questions, I felt that this (hopefully) gives a
>> > purpose and perhaps motivation for those who have the answers to answer
>> > my
>> > questions even if they get annoying. In particular, I may often miss
>> > some
>> > parts that may seem obvious because I don't necessarily have the time to
>> > read all the connected code in depth. Hopefully you'll bear with me.
>> >
>> > Does this sound reasonable to the fine folks on the list?
>> >
>> > Yotam
>
>

--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs