headers
Grundy, Jim D | 1 Jul 2009 01:40
Picon
Favicon

Call for Participation: Commercial Users of Functional Programming Workshop 2009

  Commercial Users of Functional Programming Workshop (CUFP) 2009

           Functional Programming As a Means, Not an End

                       Call for Participation

                        Sponsored by SIGPLAN
                     Co-located with ICFP 2009
     _________________________________________________________

                          4 September 2009
                        Edinburgh, Scotland

                      Registration is through
            http://www.regmaster.com/conf/icfp2009.html
     _________________________________________________________

   Functional languages have been under academic development 
   for over 25 years, and remain fertile ground for programming
   language research. Recently, however, developers in industrial, 
   governmental, and open source projects have begun to use 
   functional programming successfully in practical applications. 
   In these settings, functional programming has often provided 
   dramatic leverage, including whole new ways of thinking about 
   the original problem.

   The goal of the CUFP workshop is to act as a voice for these
   users of functional programming. The workshop supports the
   increasing viability of functional programming in the
   commercial, governmental, and open-source space by providing a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Lin | 1 Jul 2009 04:13
Picon

Re: ocamllex and python-style indentation

On Tue, Jun 30, 2009 at 6:06 PM, Andreas Rossberg<rossberg <at> mpi-sws.org> wrote:
> On Jun 30, 2009, at 22.19 h, Mike Lin wrote:
>>
>> More generally, you've got parentheses, comments, and string literals,
>> and you need to know to ignore whitespace within any of those -- and
>> to ignore e.g. an open parenthesis that occurs within a comment, or a
>> close comment that occurs within a string literal. So inevitably
>> you've got to lex and parse at some level to make this work for a
>> practical language.
>
> Comments and string literals are no problem, since the lex wrapper will
> never see anything inside them as separate tokens anyway.

OCaml comments can be nested, and must be nested parenthetically. :)

_______________________________________________
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
Permalink | Reply | 10 comments |
headers
Roland Zumkeller | 1 Jul 2009 05:16
Picon

Re: ignoring toplevel phrases?

On Sat, Jun 27, 2009 at 12:44 AM, Ashish Agarwal<agarwal1975 <at> gmail.com> wrote:
> Just curious, why do you want this?

I would like to save the state of the toplevel to the disk using
serialization. As functions can't be serialized one could check at
every "let" statement if there is a saved serialized value and if yes,
take that, otherwise execute the let-body. Just complinig is not an
option, since the *results* of previous computations should be saved,
i.e. 120 as opposed to "fact 5".

_______________________________________________
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
Permalink | Reply | 0 comments |
headers
Roland Zumkeller | 1 Jul 2009 06:43
Picon

List.combine stack overflow

Hi,

List.combine fails in this example:

# let rec ulist = function 0 -> [] | n -> () :: ulist (n-1);;
...
# let x = ulist 30000;;
...
# List.combine x x;;
Stack overflow during evaluation (looping recursion?).

However, with a *copy* of 'combine' from stdlib/list.ml it suddenly works:

# let rec combine l1 l2 =
  match (l1, l2) with
    ([], []) -> []
  | (a1::l1, a2::l2) -> (a1, a2) :: combine l1 l2
  | (_, _) -> invalid_arg "List.combine";;
...
# combine x x;;
[((), ()); ((), ()); ((), ()); ((), ()); ((), ()); ((), ()); ...]

Why does 'combine' in the standard library behave differently from its
own copy? Is it compiled with different options?

Best,

Roland

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
jlpspi | 1 Jul 2009 07:01

Second Call for Papers: DAMP 2010

                       DAMP 2010: Workshop on
             Declarative Aspects of Multicore Programming
                            Madrid, SPAIN
                      (colocated with POPL 2010)
                          January, 2010
                        damp10.cs.nmsu.edu
		SUBMISSION DEADLINE: SEPTEMBER 21, 2009

The  advent  of multicore architectures  has profoundly  increased the 
importance of research  in parallel  computing. Modern  platforms  are 
becoming more complex and heterogenous and novel solutions  are needed
to account for their peculiarities.
Multicore  architectures will  differ in  significant ways  from their
multisocket  predecessors. For example,  the communication  to compute
bandwidth ratio is  likely to be higher, which  will positively impact
performance. More generally, multicore architectures introduce several
new  dimensions  of variability  in  both  performance guarantees  and
architectural  contracts,  such as  the  memory  model,  that may  not
stabilize for several generations of product.

Programs  written  in  functional  or  (constraint-)logic  programming
languages, or in other highly declarative languages  with a controlled  
use of side effects, can  greatly simplify parallel  programming. Such 
declarative programming  allows  for  a  deterministic semantics  even  
when  the underlying implementation might be highly non-deterministic.  
In addition to simplifying programming this can simplify debugging and
analyzing correctness.

DAMP 2010 is the  fifth in  a series of  one-day  workshops seeking to 
explore  ideas in  declarative  programming  language design that will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Rossberg | 1 Jul 2009 09:31
Favicon

Re: ocamllex and python-style indentation

On Jul 1, 2009, at 04.13 h, Mike Lin wrote:

Comments and string literals are no problem, since the lex wrapper will
never see anything inside them as separate tokens anyway.

OCaml comments can be nested, and must be nested parenthetically. :)

I know. (Haskell has nested comments, too, btw.) That does not make a difference, though - it is all handled by lex already. In fact, my code handled nested comments just f ine.

- Andreas

_______________________________________________
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
Permalink | Reply | 9 comments |
headers
Mike Lin | 1 Jul 2009 16:02
Picon

Re: ocamllex and python-style indentation

On Wed, Jul 1, 2009 at 3:31 AM, Andreas Rossberg<rossberg <at> mpi-sws.org> wrote:
>
> I know. (Haskell has nested comments, too, btw.) That does not make a
> difference, though - it is all handled by lex already. In fact, my code
> handled nested comments just fine.

OK, now I'm curious :) how does your lexer match balanced parentheses,
or in this case comments?

_______________________________________________
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
Permalink | Reply | 8 comments |
headers
Andreas Rossberg | 1 Jul 2009 16:17
Favicon

Re: ocamllex and python-style indentation

Mike Lin wrote:
> OK, now I'm curious :) how does your lexer match balanced parentheses,
> or in this case comments?
>   

Easily, with a bit of side effects (I think that's roughly how all ML 
compilers do it):

------------------------------------------------
let error l s = (* ... *)
let commentDepth = ref 0
let start = ref 0
let loc length = let pos = !start in (pos, pos+length)

rule lex =
    parse eof            { EOF }
    (* | ... *)
    | "{-"            { start := pos lexbuf;
                  lexNestComment lexbuf }

and lexNestComment =
    parse eof            { error (loc 2) "unterminated comment" }
    | "(*"            { incr commentDepth;
                  lexNestComment lexbuf }
    | "*)"            { decr commentDepth;
                  if !commentDepth > 0
                  then lexNestComment lexbuf
                  else lex lexbuf }
    | _            { lexNestComment lexbuf }
------------------------------------------------

If you also want to treat strings in comments specially (like OCaml), 
then you need to do a bit more work, but it's basically the same idea.

- Andreas

_______________________________________________
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
Permalink | Reply | 7 comments |
headers
Andreas Rossberg | 1 Jul 2009 16:21
Favicon

Re: ocamllex and python-style indentation

I wrote:
> ------------------------------------------------
> let error l s = (* ... *)
> let commentDepth = ref 0
> let start = ref 0
> let loc length = let pos = !start in (pos, pos+length)
>
> rule lex =
>    parse eof            { EOF }
>    (* | ... *)
>    | "{-"            { start := pos lexbuf;
>                  lexNestComment lexbuf }

Sorry, the "{-" should be "(*" for ML. And the (* | ... *) is supposed 
to stand for all other tokens in your lexer.

- Andreas

_______________________________________________
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
Permalink | Reply | 1 comment |
headers
Mike Lin | 1 Jul 2009 16:37
Picon

Re: ocamllex and python-style indentation

That's cheating!!!!!! It's clever :) But clearly, you have a little
parser with a stack there. My original contribution to this thread was
just that "you've got to lex and parse at some level" before doing the
whitespace conversion. Not that you were claiming otherwise, but it
seemed like others had alluded to simpler ways which would only work
for toy languages.

On Wed, Jul 1, 2009 at 10:21 AM, Andreas Rossberg<rossberg <at> mpi-sws.org> wrote:
> I wrote:
>>
>> ------------------------------------------------
>> let error l s = (* ... *)
>> let commentDepth = ref 0
>> let start = ref 0
>> let loc length = let pos = !start in (pos, pos+length)
>>
>> rule lex =
>>   parse eof            { EOF }
>>   (* | ... *)
>>   | "{-"            { start := pos lexbuf;
>>                 lexNestComment lexbuf }
>
> Sorry, the "{-" should be "(*" for ML. And the (* | ... *) is supposed to
> stand for all other tokens in your lexer.
>
> - Andreas
>
>

_______________________________________________
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
Permalink | Reply | 0 comments |

Gmane