[Caml-list] Parser/lexer for block indented code
Would anyone happen to have lying around parser/lexer for block indented code (a la Python and Haskell)? I am using ocamlyacc or menhir, whichever. It seems to be the best way to do deal with this is to put a filter between lexer and parser that inserts appropriate hints. I would like to avoid reinventing the wheel, hints and advice are appreciated. With kind regards, Andrej ___ 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
Re: [Caml-list] New to Ocaml
>let sorted_list = List.sort unsorted_list in You should also provide to List.sort a function to compare the elements of the list, the function should have type: 'a -> 'a -> int For basic types, like ints or chars the Pervasives.compare function would serve: # let l = ['g';'b';'f';'c';'a'];; val l : char list = ['g'; 'b'; 'f'; 'c'; 'a'] # let sortedl = List.sort compare l;; val sortedl : char list = ['a'; 'b'; 'c'; 'f'; 'g'] For user-defined types (or if you want to write your own comparison criteria) you should provide the comparison function. For example; # let sortedl = List.sort (fun x y -> if x > y then 1 else 0) [5;3;7;1];; val sortedl : int list = [1; 3; 5; 7] Hope this helps, M; Erik de Castro Lopo wrote: chaithanya kr wrote: Hi all. I am new to Ocaml. Just started learning recently. I was studying lists in ocaml. In that, suppose there is a list by name singly_list, then by saying "List.length singly_list;;" I will get the length of the linked list. Similarly can anyone tell me as to how to sort a linked list using the 'sort' function? Please give me an example of using List.sort. In Ocaml, lists are immutable (cannot be changed) and hence, sorting a list results in a new list: let sorted_list = List.sort unsorted_list in Erik ___ 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
Re: [Caml-list] New to Ocaml
chaithanya kr wrote: > Hi all. I am new to Ocaml. Just started learning recently. > > I was studying lists in ocaml. In that, suppose there is a list by name > singly_list, then by saying "List.length singly_list;;" I will get the > length of the linked list. > > Similarly can anyone tell me as to how to sort a linked list using the > 'sort' function? Please give me an example of using List.sort. In Ocaml, lists are immutable (cannot be changed) and hence, sorting a list results in a new list: let sorted_list = List.sort unsorted_list in 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
[Caml-list] New to Ocaml
Hi all. I am new to Ocaml. Just started learning recently. I was studying lists in ocaml. In that, suppose there is a list by name singly_list, then by saying "List.length singly_list;;" I will get the length of the linked list. Similarly can anyone tell me as to how to sort a linked list using the 'sort' function? Please give me an example of using List.sort. Thank you Bye Chaitanya ___ 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
Re: [Caml-list] Problem correlating input and output type
Goswin von Brederlow a écrit : > Tiphaine Turpin writes: > > >> Goswin von Brederlow a écrit : >> >>> [...] >>> >>> Can anyone think of a way to express this so that the type system keeps >>> track of which callbacks are already connected? >>> >> Runtime checking would be much easier (but still a bit hackish). >> > > But runtime checks will only show the error when the GUI object is > instantiated. Some obscure dialog might not pop up in month. [...] > But how do you translate that into ocaml objects? > > I see two requirements in your problem that are difficult to combine: - static checking by an "ordinary" type system - dynamic connection of objects. First, I believe that it prevents anything imperative (because such typing ignores the execution flow). A functional approach may succeed in some sense, but I don't think that it would be practical. As for the combination with objects, In my (humble) experience with objects in Ocaml, I found that typing even reasonably simple designs is not a trivial task. So, combining that with the earlier hack would quickly become a nightmare. My personal opinion would be to drop the second condition, and make the connection of your objects static. I would try to define the objects as functors, with one module parameter per connection, and connect all that using (possibly recursive) module definitions. I'm curious to know what solutions object-oriented people could propose, in particular with dependency injection. Tiphaine ___ 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
Re: [Caml-list] Problem correlating input and output type
Tiphaine Turpin writes:
> Goswin von Brederlow a écrit :
>> Hi,
>>
>> last night I had a crazy idea
> Definitely :-).
>
>> [...]
>>
>>
>> Can anyone think of a way to express this so that the type system keeps
>> track of which callbacks are already connected?
>>
> Here is an attempt (with only two "events"). Note that :
> - the imperative version cannot prevent connecting a signal more than once
> - such types can only represent sets of "parallel" edges of a lattice,
> i.e., this doesn't generalises to arbitrary "typestate" properties
> - this is just a curiosity, and not a reasonable way of doing such
> things. Runtime checking would be much easier (but still a bit hackish).
But runtime checks will only show the error when the GUI object is
instantiated. Some obscure dialog might not pop up in month.
> Tiphaine
>
> module LatticeFun : sig
>
> type ('foo, 'bar) r
> type t and f
>
> val make : unit -> (f, f) r
> val set_foo : (f, 'bar) r -> (t, 'bar) r
> val set_bar : ('foo, f) r -> ('foo, t) r
> val use : (t, t) r -> unit
>
> end = struct
>
> type ('foo, 'bar) r = {foo : bool ; bar : bool}
>
> type t
> type f = t
>
> let make () = {foo = false ; bar = false}
> let set_foo x = {x with foo = true}
> let set_bar x = {x with bar = true}
> let use _ = ()
>
> end
>
> module LatticeImp : sig
>
> type ('foo, 'bar) r
> type t and f
>
> val make : unit -> (f, f) r
> val set_foo : ('foo, 'bar) r -> (t, 'bar) r
> val set_bar : ('foo, 'bar) r -> ('foo, t) r
> val use : (t, t) r -> unit
>
> end = struct
>
> (* for some reason, the direct declaration causes a module type error *)
> type r1 = {mutable foo : bool ; mutable bar : bool}
> type ('foo, 'bar) r = r1
>
> type t
> type f = t
>
> let make () = {foo = false ; bar = false}
> let set_foo x = x.foo <- true ; x
> let set_bar x = x.bar <- true ; x
> let use _ = ()
>
> end
Thanks. That solves the first problem. But how do you translate that
into ocaml objects?
type need_click
type have_click
class type ['click] clickable_type = object
method set_click : ...?
method use : ...?
end
I believe a method can not change the type of a class nor can it require
the parametereized class to be of a certain type. And if I write helper
function outside the class like
let set_foo x = x#foo <- true ; x
then I can't use inheritance for them. Maybe I can use inheritance
for the class objects and module inclusion for the set_* helpers. But
how do I write the use function so that one can not use of an inherited
class?
Or how do I specify
method add_connected_obj : () obj
The would need to be specific to the exact type of object
being added. I do believe I need something that simplifies the type with
each aplication of a callback so that all fully connected objects will
have the same basic type, e.g.
unit need_click need_drag obj => unit need_click obj => unit obj
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
[Caml-list] Format syntax extension
Dear list, I'm pleased to announce the first release of the Format syntax extension for Ocaml: https://forge.ocamlcore.org/frs/download.php/360/format-1.0.tar.bz2. Format is basically a quotation-style printf, i.e., it defines quotations for building strings and writing to buffers, channels, and formatters, with data being inserted through antiquotations rather than subsequent arguments. Here is a list of features: - Format can be used to write to strings, buffers, channels, and (with a limited efficiency) formatters. - Format expressions are (mostly) compiled rather than interpreted (less overhead). - All Printf formatting instructions are supported, except %a (but %t seems more natural in this setting anyway). - Conditionals and iteration are available. - Type errors are more readable than with printf. - Errors should be correctly located (both in formats and inside anti-quotations). - Also works with Ocaml Batteries with out_channel -> 'a IO.output (no integration with the "prefixes" of batteries). Tiphaine Turpin ___ 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] 2nd CfP: LOPSTR 2010
= Call for papers 20th International Symposium on Logic-Based Program Synthesis and Transformation LOPSTR 2010 http://www.risc.uni-linz.ac.at/conferences/lopstr2010/ Hagenberg, Austria, July 23-25, 2010 (co-located with PPDP 2010) = Objectives: The aim of the LOPSTR series is to stimulate and promote international research and collaboration on logic-based program development. LOPSTR is open to contributions in logic-based program development in any language paradigm. LOPSTR has a reputation for being a lively, friendly forum for presenting and discussing work in progress. Formal proceedings are produced only after the symposium, so authors can incorporate the feedback in the published papers. The 20th International Symposium on Logic-based Program Synthesis and Transformation (LOPSTR 2010) will be held in Hagenberg, Austria; previous symposia were held in Coimbra, Valencia, Lyngby, Venice, London, Verona, Uppsala, Madrid, Paphos, London, Venice, Manchester, Leuven, Stockholm, Arnhem, Pisa, Louvain-la-Neuve, and Manchester. LOPSTR 2010 will be co- located with PPDP 2010 (12th International ACM SIGPLAN Symposium on Principles and Practice of Declarative Programming). Topics: Topics of interest cover all aspects of logic-based program development, all stages of the software life cycle, and issues of both programming-in- the-small and programming-in-the-large. Papers describing applications in these areas are especially welcome. Contributions are welcome on all aspects of logic-based program development, including, but not limited to: specification synthesis verification transformation analysis optimisation specializationinversion composition program/model manipulation certification security transformational techniques in SE applications and tools Survey papers that present some aspect of the above topics from a new perspective. Application papers, that describe experience with industrial applications, are also welcome. Papers must describe original work, be written and presented in English, and must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with refereed proceedings. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. Following past editions, publication of the formal post-conference proceedings in the Springer series Lecture Notes in Computer Science (LNCS) is envisaged. IMPORTANT DATES AND SUBMISSION GUIDELINES: Paper/extended abstract submission: March 25, 2010 Notification (for pre-proceedings): May 15, 2010 Camera-ready (for pre-proceedings): June 15, 2010 Symposium:July 23-25, 2010 Submissions can either be (short) extended abstracts or (full) papers whose length should not exceed 9 and 15 pages, respectively. Submissions must be formatted in the Springer LNCS style (excluding well-marked appendices not intended for publication). Referees are not required to read the appendices, and thus papers should be intelligible without them. Short papers may describe work-in-progress or tool demonstrations. Both short and full papers can be accepted for presentation at the symposium and will then appear in the LOPSTR 2010 pre-proceedings. Full papers can also be immediately accepted for publication in the formal proceedings published by Springer-Verlag in the LNCS series. In addition, after the symposium, the programme committee will select further short or full papers presented in LOPSTR 2010 to be considered for formal publication. These authors will be invited to revise and/or extend their submissions in the light of the feedback solicited at the symposium. Then after another round of reviewing, these revised papers can also be published in the formal post-proceedings. Papers should be submitted electronically via the submission page http://www.easychair.org/conferences/?conf=lopstr2010 They should be in PDF format and interpretable by Acrobat Reader. Invited Speakers: Bruno Buchberger RISC, Johannes Kepler University Linz, Austria Olivier DanvyUniversity of Aarhus, Denmark Johann Schumann RIACS/NASA Ames Research Center, USA Program Committee: Maria Alpuente Tech. University of Valencia (Chair), Spain Sergio Antoy Portland State University, USA Gilles BartheIMDEA Software, Madrid Manuel Carro Tech. University of Madrid, Spain Marco Comini University of Udi
