Re: Page 76 of OCaml by John Whitington ???

Well my exploration of LISP will have to wait, otherwise I'll be mediocre
at many languages rather than really good at just a few!  Changing the
topic a bit, I'm really struggling with something here.  If you look at the
99 Problems in Ocaml page, there's a problem that requires you to write a
pack function that basically does this:

pack [1; 1; 1; 1; 2; 2; 2; 2; 3; 3] ;;

[[1; 1; 1; 1]; [2; 2; 2; 2]; [3; 3]];

Just when I thought I was getting good at Ocaml I found a problem that has
truly humbled me.  I've written a few different solutions.  Most compile
but will not produce the desired result.  I looked at the proposed solution
but had a really hard time tracing through it because in some cases the
number of required arguments seems disjoint.  Here's the copy and paste of
the proposed solution:

Okay... confusion here!  First off look at *rec aux current acc* ( why
can't people just call it "accumulator" to make tracing easier?! )  So this
recursive function aux ( or auxiliary ) accepts 2 arguments, "current" and
"acc", right?  But then later on in the code it after the "then" statement,
it appears that aux accepts 3 arguments, *( a :: current ) acc t*.  And
then later on in the code we see aux [ ] [ ] list, which again leads to the
idea that aux accepts 3 arguments, but in the declaration of aux, the aux
function accepts only 2 arguments!  Okay, I am officially confused!  Why is
the number of parameters changing like that.  Does it have something to do
with currying or partial function application?  ( But with partial function
application the number of parameters is less rather than more than the
original number of parameters.... I thought? )

If anyone can enlighten me on how to trace through this mess, I would be
very grateful!

One last question.  With regard to recursive functions that create ref
variables.... are those ref variables reinitialized every time the function
is called?  I imagine they should be and would be, but.... I don't know.
I'll have to experiment with that one and figure it out.


# let pack list =
    let rec aux current acc = function
      | [] -> []    (* Can only be reached if original list is empty *)
      | [x] -> (x :: current) :: acc
      | a :: (b :: _ as t) ->
         if a = b then aux (a :: current) acc t
         else aux [] ((a :: current) :: acc) t  in
    List.rev (aux [] [] list);;
val pack : 'a list -> 'a list list = <fun>


On Thu, Mar 24, 2016 at 4:05 PM, Kenneth Miller [email protected]
[ocaml_beginners] <[email protected]> wrote:

>
>
> LISP is awesome because it allows you to generate code that fits what you
> want.
>
> The way I understand it is, if you're familiar with what ppx is and does,
> imagine having a language that's built around making code that can fit into
> things like that - when you finish a solution, you can annotate it onto
> anything basically. It's like generics or type inference, but with whole
> modules and data structures instead of just a single function.
>
>
> On Thursday, March 24, 2016 5:02 PM, "Douglas Lewit [email protected]
> [ocaml_beginners]" <[email protected]> wrote:
>
>
>
> Thanks Hendrik.  I'll have to find that paper by Peter Landin.  The
> author's name is strongly familiar, but right now I can't quite place it.
> My AI professor said that LISP and other functional programming languages
> are great for AI, but I didn't quite get his explanation.  ( And to be
> fair, his explanation was pretty short and quick. )  Something about how AI
> requires the manipulation of symbolic values ( as in computer algebra ) and
> for that sort of thing functional programming is better suited than other
> programming paradigms.
>
> On Thu, Mar 24, 2016 at 3:07 PM, Hendrik Boom [email protected]
> [ocaml_beginners] <[email protected]> wrote:
>
>
> On Thu, Mar 24, 2016 at 11:49:44AM -0500, Douglas Lewit [email protected]
> [ocaml_beginners] wrote:
>
> >
> > P.S. I almost forgot. Is LISP considered the great granddaddy of all
> > functional programming languages? Is it correct to say that OCaml is
> > descended from LISP? Thanks for the feedback.
>
> I'd say so, yes.
>
> Since you are asking about history, perhaps you'd like some:
>
> One of the important papers, while not explicitly about functional
> programming, that liberated functional programming from LISP was
> "The Next 700 Programming Languages", by Peter Landin.
>
> -- hendrik
>
>
>
>
> 
>