Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #24448 > unrolled thread

ANN: Ramda, a new functional programming library

Back to article view | Back to comp.lang.javascript

Contents

  ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-27 20:13 -0700
    Re: ANN: Ramda, a new functional programming library John C <rescattered@gmail.com> - 2014-05-27 21:00 -0700
      Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-28 04:37 -0700
    Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-28 04:36 -0700
    Re: ANN: Ramda, a new functional programming library "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-05-28 08:49 -0700
      Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-28 15:59 -0700
        Re: ANN: Ramda, a new functional programming library "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-05-28 16:15 -0700
          Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-28 17:05 -0700
            Re: ANN: Ramda, a new functional programming library Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-30 14:53 +0200
              Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-30 11:14 -0700
    Re: ANN: Ramda, a new functional programming library Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-05-29 19:40 +0100
      Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-29 17:55 -0700
        Re: ANN: Ramda, a new functional programming library Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-30 14:05 +0200
          Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-30 11:10 -0700
    Re: ANN: Ramda, a new functional programming library John C <rescattered@gmail.com> - 2014-05-30 06:25 -0700
      Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-30 11:23 -0700
        Re: ANN: Ramda, a new functional programming library John C <rescattered@gmail.com> - 2014-05-30 12:44 -0700
          Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-30 13:39 -0700
            Re: ANN: Ramda, a new functional programming library John C <rescattered@gmail.com> - 2014-05-30 19:17 -0700
              Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-05-31 09:52 -0700
                Re: ANN: Ramda, a new functional programming library Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-31 22:24 +0200
                  Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-06-01 06:55 -0700
        Re: ANN: Ramda, a new functional programming library Christoph Michael Becker <cmbecker69@arcor.de> - 2014-05-31 21:00 +0200
          Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-06-01 06:54 -0700
    Re: ANN: Ramda, a new functional programming library Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-06-01 19:05 +0100
      Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-06-01 19:28 -0700
        Re: ANN: Ramda, a new functional programming library Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-06-03 22:01 +0100
          Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-06-03 19:15 -0700
            Re: ANN: Ramda, a new functional programming library Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-06-05 23:41 +0100
              Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2014-06-06 11:36 -0700
            Re: ANN: Ramda, a new functional programming library Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-06-07 23:13 +0100
    Re: ANN: Ramda, a new functional programming library billyroberts111@gmail.com - 2016-03-06 10:22 -0800
      Re: ANN: Ramda, a new functional programming library Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-06 17:52 -0800
        Re: ANN: Ramda, a new functional programming library "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-07 10:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#24511

Scott Sauyet wrote:

> John C wrote:
>> Scott Sauyet wrote:
> 
>>> [ ... re: when foldl1/foldr1 is called with no accumulator ...]
> 
>>> The original implementation, following Haskell, raised an exception in 
>>> this case. My coauthor didn't like this, thinking that we should return 
>>> `undefined`. I, in turn, didn't like returning anything that might make 
>>> the user have to type-check her results. 
> 
>> I guess I was thinking in terms of the Principle of Least 
>> Astonishment (POLA). JavaScript already has some functional 
>> features, so I would think that a library for functional programming 
>> in JavaScript should extend what is already there rather than 
>> rewriting it. 
> 
> I'm afraid that we might then be disappointing you.  For the most 
> part, the array processing functions are all hand-written.  
> (Christoph Becker notes some exceptions earlier in this thread.)  We 
> do this for various reasons, but the biggest one is to be in control 
> of the API. [...]

Addtionally it should be noted, that several of the ECMAScript Array
methods are destructive, which is not desirable in the functional
programming paradigm, unless for performance reasons.  It might be
interesting to have some benchmarks available, comparing e.g.
Array.prototype.reverse() and ramda.reverse().

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24525

Christoph Michael Becker wrote:
> Scott Sauyet wrote:
>> John C wrote:
>>> Scott Sauyet wrote:
>> 
>>>> [ ... re: when foldl1/foldr1 is called with no accumulator ...]
>> 
>>>> The original implementation, following Haskell, raised an exception in 
>>>> this case. My coauthor didn't like this, thinking that we should return 
>>>> `undefined`. I, in turn, didn't like returning anything that might make 
>>>> the user have to type-check her results. 
>> 
>>> I guess I was thinking in terms of the Principle of Least 
>>> Astonishment (POLA). JavaScript already has some functional 
>>> features, so I would think that a library for functional programming 
>>> in JavaScript should extend what is already there rather than 
>>> rewriting it. 
>>
>> I'm afraid that we might then be disappointing you.  For the most 
>> part, the array processing functions are all hand-written.  
>> (Christoph Becker notes some exceptions earlier in this thread.)  We 
>> do this for various reasons, but the biggest one is to be in control 
>> of the API. [...]
> 
> Addtionally it should be noted, that several of the ECMAScript Array
> methods are destructive, which is not desirable in the functional
> programming paradigm, unless for performance reasons.  It might be
> interesting to have some benchmarks available, comparing e.g.
> Array.prototype.reverse() and ramda.reverse().

It might be interesting.  In the case of `reverse`, Ramda would of 
necessity be slower than the native version, as it depends upon that 
version and also uses a `clone` function (which is just a native 
`concat` call and should be reasonably quick, but still...)  In some
others, I'm guessing that Ramda's versions would be faster than their
native counterparts, and in many cases, there would probably not be
enough of a difference for me to care about.  I do know that we
reimplemented `slice` internally, because our internal version was
much faster than the native counterpart.

But I haven't had any reason to worry about this since we stopped 
the predeccesor project, Eweda, which used more LISP-like 
techniques, heavy on the recursion, and ended up too slow for 
practical work.  It would probably be worth knowing the results of 
such performance analysis, and might help us find places ripe for 
some optimizations, but it's not particularly high on my priority 
list right now.

But the broader point, that ramda's functions are not destructive, 
is spot on.  That is fundamental.  Javascript is a multi-paradigm 
language.  It's easy to combine Object-Oriented techniques with 
functional ones.  There have been plenty of tools to help with the 
OO-side of things.  Ramda is designed to help the user work 
functionally.  This means that it should never mutate arguments to 
its functions.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#24509

Scott Sauyet wrote:

> John C wrote:
> 
>> As far as your name for foldl1 goes -- how about selfFoldl since in
>>  that case it folds in on itself (as opposed to folding on an
>> externally given item)? Another idea is something like "rollUp"
> 
> Those both sound quite good.  Thank you for the suggestions.
> 
> The funny thing is that I'd forgotten we'd taken these out of the
> library in response to a disagreement over how to handle the case
> where the user supplied an empty list.  At some point we'll probably
> put them back, but they're not there now.  When they do come back,
> maybe we'll use `selfFoldl`.

Um, foldl1() and foldr1() are in current master[1], though. :)

BTW: there is a mistake in the documentation of deepClone, where it says:

| Create a shallow copy of an array.

[1] <https://github.com/CrossEye/ramda/blob/master/ramda.js#L562>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#24524

Christoph Michael Becker wrote:
> Scott Sauyet wrote:
>> John C wrote:
>> 
>>> As far as your name for foldl1 goes -- how about selfFoldl since in
>>>  that case it folds in on itself (as opposed to folding on an
>>> externally given item)? Another idea is something like "rollUp"
>> 
>> Those both sound quite good.  Thank you for the suggestions.
>> 
>> The funny thing is that I'd forgotten we'd taken these out of the
>> library in response to a disagreement over how to handle the case
>> where the user supplied an empty list.  At some point we'll probably
>> put them back, but they're not there now.  When they do come back,
>> maybe we'll use `selfFoldl`.
> 
> Um, foldl1() and foldr1() are in current master[1], though. :)

Yeah, I noticed that yesterday.  I did take them out, I swear it!  
We must have had a bad merge that put them back in, which neither of 
us noticed.  When I talk to the co-author, we'll work out whether 
they should stay, and if so, how to handle the issue of whether to
throw or return undefined when an empty list is supplied.


> BTW: there is a mistake in the documentation of deepClone, where it says:
> 
> | Create a shallow copy of an array.
> 
> [1] <https://github.com/CrossEye/ramda/blob/master/ramda.js#L562>

Thanks.  That's been fixed.  This turns out to be another place where
the code depends on something not available in the older browsers: a
native JSON implementation.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#24532

In comp.lang.javascript message <da2909bd-58cc-4183-8b3c-167039985491@go
oglegroups.com>, Tue, 27 May 2014 20:13:11, Scott Sauyet
<scott.sauyet@gmail.com> posted:

>I'm looking for feedback on a new functional programming library for
>Javascript that I've been developing with a friend.  This may seem
>very familiar to those who saw a similar request a year ago.  That was
>for a different library, which turned out to be more of academic
>interest.  This one was originally based on that project, eweda, but
>with a more practical bent.

If the library is not being written IN JavaScript (or even if it is),
you could consider implementing (maybe more efficiently) the improved
date object in <http://www.merlyn.demon.co.uk/js-dobj2.htm>.

Note that for the Russian market one should add a routine for Julian
Easter, carefully considering the consequences of the differing lengths
of the Julian & Gregorian Years.

-- 
 (c) John Stockton, nr London, UK.   E-mail, see Home Page.    Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[toc] | [prev] | [next] | [standalone]

#24533

Dr J R Stockton wrote:
> Scott Sauyet posted:
> 
>> I'm looking for feedback on a new functional programming library for
>> Javascript that I've been developing with a friend.  [ ... ]
> 
> If the library is not being written IN JavaScript (or even if it is),
> you could consider implementing (maybe more efficiently) the improved
> date object in <http://www.merlyn.demon.co.uk/js-dobj2.htm>. [ ... ]

Although that looks to be interesting code, and an improvement on 
the existing Date constructor function in several important ways, I 
don't think it would be a good fit for Ramda.  

Ramda is about offering functional programming (FP) tools to the 
user.  Javascript, with heritage from both Self and Scheme has both 
object-oriented and functional roots.  There are plenty of tools to 
help with the OO side, but far fewer for the FP paradigm.  That's 
where Ramda fits in.  It offers things like improved `map`, 
`reduce`, `filter`, and similar list-handling features, functional 
composition and currying, the reification of numerous functions from 
the String, Array, and Object prototypes, some SQL-like functions to 
query lists of objects, and various other techniques to work with
immutable objects.

DATE2 is an OO construct, a constructor function with a beefy 
prototype object.  It creates mutable objects, usually a no-no in FP 
code, and it carries a great deal of inaccessible internal state.  
These features are fine for OO, but not for FP.

I have a talk I've given several times discussing the ideas involved 
in functional programming as applied to Javascript. [1]  In this I 
work through an example of some of the common functional programming 
tools in Javascript, developing this fairly simple FP function of 
the parameter `memberName`:

    fetchData()
      .then(get('tasks'))
      .then(filter(propEq('member', memberName)))
      .then(reject(propEq('complete', true)))
      .then(map(pick(['id', 'dueDate', 'title', 'priority'])))
      .then(sortBy(get('dueDate')));

out of this much more lengthy procedural version:

    fetchData()
      .then(function(data) {
        return data.tasks;
      })
      .then(function(tasks) {
        var results = [];
        for (var i = 0, len = tasks.length; i < len; i++) {
          if (tasks[i].member == memberName) {
            results.push(tasks[i]);
          }
        }
        return results;
      })
      .then(function(tasks) {
        var results = [];
        for (var i = 0, len = tasks.length; i < len; i++) {
          if (!tasks[i].complete) {
            results.push(tasks[i]);
          }
        }
        return results;
      })
      .then(function(tasks) {
        var results = [], task;
        for (var i = 0, len = tasks.length; i < len; i++) {
          task = tasks[i];
          results.push({
            id: task.id,
            dueDate: task.dueDate,
            title: task.title,
            priority: task.priority
          })
        }
        return results;
      })
      .then(function(tasks) {
        tasks.sort(function(first, second) {
          return first.dueDate - second.dueDate;
        });
        return tasks;
      });

The first block is the kind of code we're trying to promote through 
Ramda.

So thank you for your offer.  And if you have other tools that you 
think might fit, do please let us know.

  -- Scott

[1] <http://scott.sauyet.com/Javascript/Talk/FunctionalProgramming>

[toc] | [prev] | [next] | [standalone]

#24593

In comp.lang.javascript message <586acd4a-249d-4a91-a71a-9cd6187634dd@go
oglegroups.com>, Sun, 1 Jun 2014 19:28:38, Scott Sauyet
<scott.sauyet@gmail.com> posted:

>Dr J R Stockton wrote:
>> Scott Sauyet posted:
>>
>>> I'm looking for feedback on a new functional programming library for
>>> Javascript that I've been developing with a friend.  [ ... ]
>>
>> If the library is not being written IN JavaScript (or even if it is),
>> you could consider implementing (maybe more efficiently) the improved
>> date object in <http://www.merlyn.demon.co.uk/js-dobj2.htm>. [ ... ]
>
>Although that looks to be interesting code, and an improvement on
>the existing Date constructor function in several important ways, I
>don't think it would be a good fit for Ramda.
>
>Ramda is about offering functional programming (FP) tools to the
>user.
> ...

Not only do I not understand how to use FP, I don't understand many of
the words used in writing about it.  And I doubt whether I ever will.

>DATE2 is an OO construct, a constructor function with a beefy
>prototype object.  It creates mutable objects, usually a no-no in FP
>code, and it carries a great deal of inaccessible internal state.
>These features are fine for OO, but not for FP.

Inaccessible internal state?  AFAIR, and you'll have noticed the date of
the page, there should not be any.  There is accessible state such as
DATE2.GMT, and there are internal variables in methods, and there is the
accessible date value.  Otherwise, could you name an example?

The beefiness to which you refer is, I think, because DATE2 handles for
I/O many standard date formats, including ISO week numbering and (IIRC)
YMD using a single Roman character for the month, I-XII or i-xii.  Also
it has to work round vexing features of the standard Object, such as
new Date(14, 7, 4)   giving the (UK) start of WWI rather than a date in
the Year of the Consulship of Pompeius and Appuleius (767 AUC).

I think it would look simpler if it were implemented not IN JavaScript
but BY those who have coded the JavaScript Date Object in whatever
language was used.

OTOH, the Object does not do as much as it could about the dates of
Summer Time (I've only recently discovered that the end of Summer Time
can depend on the date of Easter Sunday).



>I have a talk I've given several times discussing the ideas involved
>in functional programming as applied to Javascript. [1]

>[1] <http://scott.sauyet.com/Javascript/Talk/FunctionalProgramming>

Includes "Not available in current versions Javascript" on slide 22.
Trivial - needs an "of".  Important - Web pages persist, so there should
be a "current date" value given at the beginning.

-- 
 (c) John Stockton, nr London, UK.   E-mail, see Home Page.    Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[toc] | [prev] | [next] | [standalone]

#24594

Dr J R Stockton wrote:
> Scott Sauyet posted:
>>Dr J R Stockton wrote:
>>> Scott Sauyet posted:
>>>
>>>> I'm looking for feedback on a new functional programming library for
>>>> Javascript that I've been developing with a friend.  [ ... ]
>>>
>>> If the library is not being written IN JavaScript (or even if it is),
>>> you could consider implementing (maybe more efficiently) the improved
>>> date object in <http://www.merlyn.demon.co.uk/js-dobj2.htm>. [ ... ]
>>
>> Although that looks to be interesting code, and an improvement on
>> the existing Date constructor function in several important ways, I
>> don't think it would be a good fit for Ramda.
>> 
>> Ramda is about offering functional programming (FP) tools to the
>> user.
>>  ...
> 
> Not only do I not understand how to use FP, I don't understand many of
> the words used in writing about it.  And I doubt whether I ever will.

Well, I'm no spring chicken, and I find I'm learning it, probably 
more slowly than I would have thirty years ago, but still reasonable 
well.  I find it a more interesting way and a more powerful way to 
program than some of the other models I've used.


>> DATE2 is an OO construct, a constructor function with a beefy
>> prototype object.  It creates mutable objects, usually a no-no in FP
>> code, and it carries a great deal of inaccessible internal state.
>> These features are fine for OO, but not for FP.
> 
> Inaccessible internal state?  AFAIR, and you'll have noticed the date of
> the page, there should not be any.  There is accessible state such as
> DATE2.GMT, and there are internal variables in methods, and there is the
> accessible date value.  Otherwise, could you name an example?

I probably mispoke.  There is a real difficulty, in fact a near 
impossibility before ES6, in efficiently working with entirely 
encapsulated data that is still avaialable to prototype functions.  
So there is not likely to be totally inaccessible internal data that 
is used by these prototype functions, but the internal Date object, 
`this.Q` looks to me like something one *had better not* manipulate 
for fear of undermining the integrity of the DATE2 object.  Am I 
mistaken about that?


> The beefiness to which you refer is, I think, because DATE2 handles for
> I/O many standard date formats, including ISO week numbering and (IIRC)
> YMD using a single Roman character for the month, I-XII or i-xii.  Also
> it has to work round vexing features of the standard Object, such as
> new Date(14, 7, 4)   giving the (UK) start of WWI rather than a date in
> the Year of the Consulship of Pompeius and Appuleius (767 AUC).

Although I didn't look at every detail, I did see the sorts of 
things that this code did.  While that's a nice chunk of work, 
functional programming is more commonly about exploiting the 
similarites between different sorts of objects, abstracting out 
common patterns of use into shared functions.  That almost necessitates
slim interfaces.


> I think it would look simpler if it were implemented not IN JavaScript
> but BY those who have coded the JavaScript Date Object in whatever
> language was used.

Well Ramda is a library for Javsacript, written in Javascript.  So 
it's probably no help here.


> OTOH, the Object does not do as much as it could about the dates of
> Summer Time (I've only recently discovered that the end of Summer Time
> can depend on the date of Easter Sunday).

Over the years, you've taught me a few surprising things about 
dates, but that one's quite surprising.  What are the circumstances 
in which this occurs?


>> I have a talk I've given several times discussing the ideas involved
>> in functional programming as applied to Javascript. [1]
> 
>> [1] <http://scott.sauyet.com/Javascript/Talk/FunctionalProgramming>
> 
> Includes "Not available in current versions Javascript" on slide 22.
> Trivial - needs an "of".  Important - Web pages persist, so there should
> be a "current date" value given at the beginning.

That's a very good idea.  I will try to fix it next time I'm in 
there editing it.


Thanks,

  -- Scott

[toc] | [prev] | [next] | [standalone]

#24616

In comp.lang.javascript message <d3bc8230-d5ec-4bf6-8cc6-5102cf3a4cc5@go
oglegroups.com>, Tue, 3 Jun 2014 19:15:43, Scott Sauyet
<scott.sauyet@gmail.com> posted:

>Dr J R Stockton wrote:

>> OTOH, the Object does not do as much as it could about the dates of
>> Summer Time (I've only recently discovered that the end of Summer Time
>> can depend on the date of Easter Sunday).
>
>Over the years, you've taught me a few surprising things about
>dates, but that one's quite surprising.  What are the circumstances
>in which this occurs?

In much of Brazil, "Carnaval" is a *major* public festival held on the
weekend before Lent begins.  Lent is of course locked to Easter, and in
Brazil occurs in late Summer or early Autumn, like the end of Summer
Time.  I gather that they do *NOT* want to have a clock change, with a
repeated hour, during Carnaval.  So, if that would happen by the
ordinary rule, TZ = BRT3BRST,M10.3.0/00:00,M2.3.0/00:00, they postpone
the end of Summer Time by a week.

Wikipedia knows about this; start at
<http://en.wikipedia.org/wiki/Daylight_saving_time_in_Brazil>

My js-date5.htm#SLGD has a button which reveals by calculation :-
Postponements in :
 2007 2012 2015 2023 2026 2034 2037 2039 2042 2045 2048
 2050 2053 2061 2064 2066 2072 2075 2077 2080 2091
 2102 2105 2107 2110 2118 2121 2123 2129 2132 2134 2137 2145 2148

I'll have time to consider the rest of your reply tomorrow, I hope.

-- 
 (c) John Stockton, nr London, UK.   E-mail, see Home Page.    Turnpike v6.05.
 Website  <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
 PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

[toc] | [prev] | [next] | [standalone]

#24632

Dr J R Stockton wrote:
> Scott Sauyet posted:
>> Dr J R Stockton wrote:

>>> OTOH, the Object does not do as much as it could about the dates of
>>> Summer Time (I've only recently discovered that the end of Summer Time
>>> can depend on the date of Easter Sunday).
>>
>> Over the years, you've taught me a few surprising things about
>> dates, but that one's quite surprising.  What are the circumstances
>> in which this occurs?
> 
> In much of Brazil, "Carnaval" is a *major* public festival held on the
> weekend before Lent begins.  Lent is of course locked to Easter, and in
> Brazil occurs in late Summer or early Autumn, like the end of Summer
> Time.  I gather that they do *NOT* want to have a clock change, with a
> repeated hour, during Carnaval.  So, if that would happen by the
> ordinary rule, TZ = BRT3BRST,M10.3.0/00:00,M2.3.0/00:00, they postpone
> the end of Summer Time by a week. [ ... ]

Very interesting. Thank you for the information. This stuff is 
tricky -- one more reason not to include it in our should-remain-
simple library. :-) 


> I'll have time to consider the rest of your reply tomorrow, I hope.

I'll look forward to it.


  -- Scott

[toc] | [prev] | [next] | [standalone]

#24675

In comp.lang.javascript message <d3bc8230-d5ec-4bf6-8cc6-5102cf3a4cc5@go
oglegroups.com>, Tue, 3 Jun 2014 19:15:43, Scott Sauyet
<scott.sauyet@gmail.com> posted:

>Dr J R Stockton wrote:
>> Scott Sauyet posted:
>>>Dr J R Stockton wrote:

>>> DATE2 is an OO construct, a constructor function with a beefy
>>> prototype object.  It creates mutable objects, usually a no-no in FP
>>> code, and it carries a great deal of inaccessible internal state.
>>> These features are fine for OO, but not for FP.
>>
>> Inaccessible internal state?  AFAIR, and you'll have noticed the date of
>> the page, there should not be any.  There is accessible state such as
>> DATE2.GMT, and there are internal variables in methods, and there is the
>> accessible date value.  Otherwise, could you name an example?
>
>I probably mispoke.  There is a real difficulty, in fact a near
>impossibility before ES6, in efficiently working with entirely
>encapsulated data that is still avaialable to prototype functions.
>So there is not likely to be totally inaccessible internal data that
>is used by these prototype functions, but the internal Date object,
>`this.Q` looks to me like something one *had better not* manipulate
>for fear of undermining the integrity of the DATE2 object.  Am I
>mistaken about that?

I hope so.  Q should be the only internal state of the Object, and if it
is written to directly in the middle of a piece of code the effect is
the same as writing code with an object D of the built-in Date Object
type and throwing in a D.setTime(x).  The DATE2 object is equally
healthy after that, but represents an altered value.

A degree of protection of Q against simpler minds might be obtained by
replacing it in the code with ?, which this mail system will probably
mung - it is the last letter of the real name of the capital city of
Greece, U+0391 - and in the comment and documentation with U+0410.

Readers can either use the Object with a little care, or take parts from
it; or, if strategically placed in the industry, implement it in the
same manner as the ordinary Object but with some different statements in
the code.

The page was intended mainly to show that a DATE2 Object could have many
more methods than a Date object - useful ones such as ISO Week Numberihg
Dates and Easter Sunday, and less common ones such as single-character
month fields.

Remember that my mind runs on ECMA 262 3rd Edn (& CSS 1), and is
unlikely to be much upgraded.

-- 
 (c) John Stockton, nr London UK        Reply address via Merlyn Home Page.
   news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
   <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
   <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[toc] | [prev] | [next] | [standalone]

#29835

On Tuesday, May 27, 2014 at 11:13:11 PM UTC-4, Scott Sauyet wrote:
> I've been away from this group a while, and probably will not be 
> around for long this time, as I'm pretty buried in several projects 
> that haven't left me much spare time.  But I wanted to announce my 
> current project.  I'll check in regularly for a while to read responses.
> 
> I'm looking for feedback on a new functional programming library for 
> Javascript that I've been developing with a friend.  This may seem 
> very familiar to those who saw a similar request a year ago.  That was 
> for a different library, which turned out to be more of academic 
> interest.  This one was originally based on that project, eweda, but 
> with a more practical bent.
> 
> The library is called "ramda", which is just a silly pun on "lambda".
> 
> My co-author has just published a brief introduction at
> 
>     <http://buzzdecafe.github.io/code/2014/05/16/introducing-ramda/>
> 
> The project is on Github, at 
> 
>     <https://github.com/CrossEye/ramda> 
> 
> and the library is (temporarily, at least) in a single source file: 
> 
>     <https://github.com/CrossEye/ramda/blob/master/ramda.js> 
> 
> You can install it for a Node.js project with
> 
>     npm install ramda
> 
> ------------------------------ 
> 
> The API has a sizable overlap with Underscore [1] and LoDash [2].  But 
> its motivations are closer to allong.es [3] or Lemonad [4] or 
> Functional Javascript [5].  It's an attempt to do in Javascript 
> something more akin to normal functional programming, as would be 
> found in Haskell, ML, Scheme, or LISP. 
> 
> The library's functions are available as properties on the main 
> object, `ramda`: 
> 
>     var square = function(x) {return x * x;}; 
>     var nbrs = ramda.range(1, 5); // => [1, 2, 3, 4] 
>     var squares = ramda.map(square, nbrs); // => [1, 4, 9, 16] 
> 
> But they can be attached to any object, including the global object 
> via `ramda.installTo()`.  This will pollute the global namespace with 
> a number of functions, but is one possible means of using the library. 
> After that, you could just call 
> 
>     var squares2 = map(square, range(1, 5)); // => [1, 4, 9, 16] 
> 
> You might note something surprising here.  Even when it has the same 
> functions as Underscore/LoDash, its parameter order often differs. 
> This is intentional.  Underscore's API was built out of the native, 
> OO- first functions on `Array.prototype` and other similar structures. 
> Ramda's API, on the other hand is designed around composition and 
> partial application (or currying.)  You can create new functions 
> easily by not passing all the arguments to something like `map`: 
> 
>     var squareAll = map(square); 
>     squareAll(range(1, 6)); // => [1, 4, 9, 16, 25] 
> 
> In all cases, functions that take one list as a parameter, have it as 
> their last parameter.  And those that take one function as a parameter 
> have it as their first one.  The API should be internally consistent, 
> even if it's a bit different from other libraries. 
> 
> ------------------------------ 
> 
> There is a fairly large set of tests (using Mocha), but they are by no 
> means comprehensive, serving more as an API guide than as an 
> exhaustive analysis of edge cases.  They are in the folder `tests`, 
> and can be run in a modern browser at 
> 
>     <https://rawgit.com/CrossEye/ramda/master/test/index.html> 
> 
> The only documentation beyond the test suite is a Docco-annotated 
> version of the source, available at 
> 
>     <https://rawgit.com/CrossEye/ramda/master/docs/ramda.html> 
> 
> ------------------------------ 
> 
> The functions we include are mostly standard functional library list 
> functions, ones like `map`, `foldl`, `foldr`, `filter`, `take`, 
> `skip`, some object-based ones like `prop`and `func`, plain function 
> manipulations like `compose`, `flip`, `memoize` and various partials, 
> as well as a few arithmetic and logic functions.  There are over 100 
> functions now, with some dozen aliases. (`reduce` is the same as 
> `foldl`.)  
> 
> I'd love for experienced people to look at the functions and see what 
> is missing, what is totally unnecessary, and what could use a better 
> name or at least an alias.  In the latter category, I really would 
> like to find a better name for `foldl1`, whose name was borrowed from 
> Haskell.  It's the difference between a left fold with an explicit 
> accumulator supplied: 
> 
>     var total = foldl(add, 0, range(1, 11)) // => 55 
> 
> and one where the first value of the (non-empty) list is taken as the 
> accumulator: 
> 
>     var total2 = foldl1(add, range(1, 11)); // => 55 
> 
> With the automatic partial application of functions, there is no good 
> way to allow for dynamic functions signatures, so I can't simply 
> assume that `foldl` with two parameters means something different from 
> `foldl` with one.  So a good name to replace `foldl1` would be very 
> helpful.  Similarly, of course, for `foldr1`. 
> 
> ------------------------------ 
> 
> We also have a few functions that we think are unique to Ramda.  Two 
> examples are:
> 
>   - `when` is similar to functions in other libraries that accept an 
>     object specification and return a predicate that can be used to 
>     test additional objects.  Ramda's `when` takes more than just 
>     individual values for specification, though; it can also take 
>     functions:
> 
>         isTriangular = where({
>           sides: 3,
>           a: function(a, t) {return a < t.b + t.c;},
>           b: function(b, t) {return b < t.a + t.c;},
>           c: function(c, t) {return c < t.a + t.b;}
>         });
> 
>         isTriangular({sides: 5}); //=> false
>         isTriangular({sides: 3, a: 2, b: 1, c: 7}); //=> false
>         isTriangular({sides: 3, a: 3, b: 4, c: 5}); //=> true
> 
>   - `useWith`.  We still haven't decided which of the two APIs 
>     for this function we prefer, and for the moment are including     
>     both.  This function combines a number of configuration functions 
>     with a single gathering function and returns a new function.  When 
>     the resulting function is called, the arguments are supplied, 
>     respectively, to each of the configuration functions, and the 
>     results of these functions are all passed to the gathering 
>     function.  This allows us to define Codd's `project` (similar to 
>     SQL `select`) for lists of objects with quite simple code:
> 
>         project = useWith(map, pickAll, identity); // OR (other API)
>         project = use(map).over(pickAll, identity);
> 
>     This would get used like this:
> 
>         var kids = [
>           {name: 'Abby', age: 7, hair: 'blond'},
>           {name: 'Fred', age: 12, hair: 'brown'},
>           {name: 'Rusty', age: 10, hair: 'brown'},
>           {name: 'Alois', age: 15, disposition: 'surly'}
>         ];
>         filter(propEq("hair", "brown"), kids);
>         //=> Fred and Rusty
> 
> ------------------------------ 
> 
> The library has a facility for creating lazy infinite lists; we're in 
> the process of pulling that out of the core and making it a separate 
> extension.  In fact we want to have a bundle-building mechanism to 
> allow you to create your own package, the way Modernizr and David 
> Mark's MyLibrary (is that still around?) do.
> 
> But that infrastructure work has never really made it to the top of 
> our list of priorities.  We've just picked up a volunteer to help with 
> documentation, so soon the library might be better documented.
> 
> But we're still mostly focused on code.  And perhaps the biggest thing 
> left is to implement some of the standard algebraic types, such as 
> Functor, Applicative, Monoid, and Monad, as well as some standard 
> objects implementing those, such as Maybe, Either, and IO.  This is 
> well underway, and will probably be ready within weeks.
> 
> ------------------------------ 
> 
> In any case, this is a very long post.  I'd love to hear any feedback 
> you have to offer.  I'd especially love to hear suggestions about the 
> API design. 
> 
> Thanks,
> 
>   -- Scott,
> 
> _____ 
> [1] http://underscorejs.org/ 
> [2] http://lodash.com/ 
> [3] https://github.com/raganwald/allong.es 
> [4] http://fogus.github.io/lemonad/ 
> [5] http://osteele.com/posts/2007/07/functional-javascript

Hi Scott,

I'm a front end developer that discovered Ramda by reading 'Dr Frisby's Mostly Adequate Guide to Functional Programming'.  

Toward the end of the book the author starts using Folktale for things like Maybe, Task, IO that you mentioned Ramda might include.  

Is there any plan to add these types of constructs to Ramda?  Are they already there and I just haven't figured out the synonyms yet?

Either way, Ramda is extremely cool and I am very excited about using it!

Best,
Billy

[toc] | [prev] | [next] | [standalone]

#29842

billy roberts wrote:
> Scott Sauyet wrote:

(Please don't top-post on USENET, and also please trim your quotes
to only include what's relevant.)

>> RE: nearly two-year old announcement of Ramda, now found at
>>     <https://github.com/ramda/ramda>

> I'm a front end developer that discovered Ramda by reading 'Dr 
> Frisby's Mostly Adequate Guide to Functional Programming'.  

An excellent book, IMHO!

> Toward the end of the book the author starts using Folktale for 
> things like Maybe, Task, IO that you mentioned Ramda might include.  
> 
> Is there any plan to add these types of constructs to Ramda?  Are 
> they already there and I just haven't figured out the synonyms yet?

We decided not to include them directly in Ramda.  Instead Ramda
delegates a number of functions, including nearly all of those in the
Fantasy Land [1] specification to similar method on the data object if
that exists.  This means that Ramda should interoperate seamlessly with
any implementation of the Fantasy Land spec.  For instance, Folktale's
`Maybe` [2] and `Either` [3] would work perfectly well with Ramda's `map`:

    const square = n => n * n;
    R.map(square, [1, 2, 3, 4]); //=> [1, 4, 9, 16]
    R.map(square, Maybe.Just(7)); //=> Maybe.Just(49)
    R.map(square, Maybe.Nothing()); //=> Maybe.Nothing()
    R.map(square, Either.Left("error msg"); //-=> Either.Left("error msg")
    R.map(square, Either.Right(5)); //=> Either.Right(25)

Ramda also has a side project for building these.  It is not as well 
tested as Folktale's but it seems to be working well.  You can find 
it at

    <https://github.com/ramda/ramda-fantasy>


> Either way, Ramda is extremely cool and I am very excited about 
> using it!

Thank you.  Although I do participate here and am happy to answer
questions when I can, this list mostly frowns on spending too much
energy on library-specific discussions (now that we seem to be done
endlessly criticizing jQuery for its myriad flaws.)  A useful
alternative is Ramda's Gitter discussion list, found at

    <https://gitter.im/ramda/ramda>

Welcome aboard!


  [1]: <https://gitter.im/fantasyland/fantasy-land>
  [2]: <https://github.com/folktale/data.maybe>
  [3]: <https://github.com/folktale/data.either>

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29845

Scott Sauyet <scott.sauyet@gmail.com> wrote on 07 Mar 2016 in 
comp.lang.javascript:

> (Please don't top-post on USENET, and also please trim your quotes
> to only include what's relevant.)

YES! 

Full Definition of relevant:
a :  having significant and demonstrable bearing on the matter at hand
b :  affording evidence tending to prove or disprove the matter at issue
     or under discussion <relevant testimony>
c :  having social relevance


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web