typelevel / general Goto Github PK

@fthomas and I would like to submit the singleton-ops library for Typelevel incubator membership.
Link to the library

Example of what singleton-ops can do today:

import singleton.ops._

class MyVec[L] {
  def doubleSize = new MyVec[2 * L]
  def nSize[N] = new MyVec[N * L]
}
object MyVec {
  implicit def apply[L](implicit check : Require[L > 0]) : MyVec[L] = new MyVec[L]()
}
val myVec : MyVec[10] = MyVec[4 + 1].doubleSize
val myBadVec = MyVec[-1] //fails compilation, as required

During the organization of the two Typelevel Summits just past it became very clear to the organizers (especially me, approaching potential sponsors, collecting donations, paying out bursaries, handling ticket sales, booking venues, etc., etc.) that a legal entity, preferably with a bank account that can be used to make and receive international payments, was essential. In practice all of this was handled through my company, Underscore Consulting, which was fine as a short term one off (well, twice off) arrangement, but isn't really suitable going forward.

I asked my accountant about this, and her advice is to set up a company limited by guarantee. The salient points are,

• Such a company has no share capital ... it's organized around a common purpose rather than being profit seeking.
• It has members rather than shareholders, and they can be located anywhere in the world.
• Individual members are protected from the liabilities taken on by the company (eg. nobody will be personally liable if an event should fail for some reason).

Other than that, such a company is just like any other UK registered company: it can have a bank account, be registered for sales tax, take payments, issue invoices, etc. etc.

I've discussed this with @non and @larsrh and the three of us are happy to get this set up with us as the three initial members if there's consensus that this is the right thing to do. If that's done, I would go on to set us up with a bank account.

There are plans to consider this in Ensime (ensime/ensime.github.io#171), but this actually makes sense as a central Typelevel "service" too.

Clarification: This is a ticket for discussion. It's not a done deal.

The project is here. It aims at bringing extensible effects to Scala projects.

I still need to work on the tutorial (using tut which I haven't used before) and publish a 1.0.

Project description

libisabelle is a library that talks to Isabelle. It offers a typed, RPC-style API to invoke operations on the Isabelle side, e.g. parsing formal terms, loading theories, and proving propositions. It also comes with a command-line interface to manage Isabelle installations and launch the theory editor with zero installation. It integrates with coursier as a light-weight package manager for Isabelle theories.

Membership criteria

1. I'm the only author.
2. See the README.
3. I'm depending on coursier, monix, and cats to provide a nice functional API. Future work: use circe for serialization and iteratee for iteratees.
4. There is a lot of Scaladoc. Not complete, but decent. Also, an example project and a tut-checked quickstart guide are available.

The IRC channels #typelevel, #spire-math and #shapeless are virtually unused, but appear to be still around. Same goes for the mailing list.

I think we should close these channels and encourage people to go to:

• Stack Overflow for long-form questions
• Gitter for (ephemeral?) discussions
• GitHub issues/pull requests for technical and governance discussions

(The above list is open for debate.)

NB, I'm not saying that Gitter is an optimal way to organize our communities around. But de-facto we're doing it. We should also figure out a way to make the chat logs persistent in some way, in case they cease operation.

TwoTails is a compiler plugin to add support for mutual tail recursion within the same object/function scope. The goal of this project is twofold:

1. Get people to use it, discover any more bugs and fix those bugs before...
2. Opening a PR to Scala itself

Addressing the 4 point criteria:

1. I'm the only person working on this. So I verify there is consensus between me, myself and I.
2. I support your CoC.
3. I swear this does not add side-effects! It's all about recursion. If that ain't functional, I've been learning the wrong things.
4. I have docs in the README and, quite honestly, I probably need to add a few more examples.

simplifies creation of Java FX - based user interfaces in Scala.

ScalaFX is a UI DSL written within the Scala Language that sits on top of Java FX 2 and Java FX 8. Every ScalaFX application is also a valid Scala application. It supports full interoperability with Java and can run anywhere the Java Virtual Machine (JVM) and Java FX 2 or Java FX 8 are supported.

Organization | Core Repo | Website | Documentation | Issue Tracker | Team: Core , Committers | News: Release News , General | Forum: Dev , User | Gitter |

RelatedProjects: scalafx.g8, scalafx-ensemble, ScalaFXML

TypeLevel core goal complaint

• Open Source : Yes
• Functional: Open for improvement
• Shared: Yes
• Resources: Yes
• Friendly: Yes
• Modular: Open for improvement

CC/@jpsacha

We're discussing having a Typelevel unconference day attached to Scala World.

We're currently in early planning stages for a possible Typelevel Summit in Copenhagen, happening before or after Scala Days. According to Trifork, the dates for Scala Days will be as follows:

• Training: Tue 30th, Wed 31st May
• Conference: Wed 31st – Fri 2nd

That leaves us with two sensible dates for the Summit: Mon 29st and Sat 3rd. Here are the trade-offs for Monday:

• easier to find a venue
• possible "gap" for attendees who don't wish to participate in the training sessions
• possibility for an unconference day the day after for interested participants

(Opposite for Saturday.)

Opinions?

• Frameless is a library to provide a more typeful experience when working with Spark (SparkSQL specifically) with potential future plans to work with Algebra and Cats
• Frameless supports the Typelevel Code of Conduct

See: https://github.com/adelbertc/frameless

We are discussing having a Typelevel event associated with Scalapolis. This would be some time in October, dates TBC.

There will be a Typelevel track at Scala by the Bay in October, date TBC.

• http4s is a typeful, purely functional HTTP library for client and server applications written in Scala.
• It has a Typelevel-derived Code of Conduct.
• The stakeholders are in favor: http4s/http4s#588
• Improved documentation is incubating.

https://github.com/slamdata/matryoshka

This is a recursion scheme library, strongly FP. It supports the Contributor Covenant code of conduct.

/cc @jdegoes, @tpolecat

I would like to submit Extruder for consideration as a Typelevel incubator project. This arose from my playing around with shapeless, it aims to do a similar thing as Pureconfig, with a few differences which are listed in the readme.

With regard to membership criteria:

1. I am the only contributor
2. The Typelevel code of conduct is present in the readme
3. Uses Cats and Shapless extensively, all returned types are wrapped in ValidationNel
4. See the associated readme

We are discussing having a Typelevel hack day at Skillsmatter's CodeNode the day after Scala eXchange, Saturday 10th December.

Some suggested on Gitter that we should periodically export/archive discussions, because Gitter's own archive only goes back one year. Gitter has an API, so we could implement this ourselves.

• Squants is the Scala API for Quantities, Units of Measure and Dimensional Analysis.
• Squants provides an API and DSL that supports type safe dimensional analysis.
• All types are immutable
• The roadmap includes support for generic numerics (work in progress) to be followed by a spire-squants binding project to support high-precision dimensional analysis.
• Squants supports the Typelevel Code of Conduct.

See: http://squants.org

We recently a did some of work on documentation (this is what we have do far), and are currently discussing setting up a gh-pages website to publish it. This might a good time to apply for full typelevel project membership; move the repo to typelevel/frameless and publish the documentation under http://typelevel.org/frameless/

This issue is for tracking activity around the Typelevel hack days at Hack the Tower in London.

I propose the following criteria and process for a project to join Typelevel,

1. There must be a consensus amongst the project's stakeholders that they want to join Typelevel.
2. The project must be willing to support the Typelevel code of conduct or something equivalent.
3. The project should be aiming to promote pure, typeful, idiomatic functional programming in Scala.
4. If the primary output of the project is software artefacts then it should aim to complement them with accessible, idiomatic documentation.

Things which are not requirements are,

• The project does not need to be nominated by an existing Typelevel member.
• At the time of joining, the project does not have to fully exemplify pure, typeful, idiomatic functional programming. There is, however an expectation that it will aim to move in that direction during an incubation period. Typelevel members are expected to encourage and help with that development.

The process for joining is as follows,

1. An issue must be created in this issue tracker proposing Typelevel membership for the project.
2. Criteria (1) and (2) should be verified.
3. Suitability of the project for joining Typelevel, and the suitability of Typelevel membership for the project, should be discussed constructively.
4. If there are no unaddressed objections to the projects joining Typelevel after a period of one week, then it will move into the incubator stage.
5. TBD: criteria for moving from incubation to full membership.

Note that the term "incubator" is chosen carefully ... incubators protect developing newborns from a challenging world, not vice versa.

The authors of pureconfig would like to submit the library for Typelevel incubator membership.

The goal of the project is to provide "a boilerplate-free library for loading configuration files", which means (semi-)automatic derivation of writers and readers to/from configuration values. This is achieved by providing a layer on top of existing configuration libraries, like typesafe config.

Addressing the 4 point criteria:

1. there is consensus amongst the project's authors (@leifwickland, @jcazevedo, @ruippeixotog and I) about joining Typelevel.
2. we added the typelevel code of conduct with the PR 107 that has been accepted by all the members (@leifwickland and @jcazevedo approved the PR and @ruippeixotog wrote it on gitter). The code of conduct can be read by anybody via the contribute section of the project.
3. we are moving toward a more functional interface. Currently most of the internal methods have no side-effects but the fact that we use Try[A] as return type of loading a configuration is not great. This will change with issue 103 that is schedules with high priority for the next release of pureconfig. After that, we plan to add a nice functional API on top of Readers and Writers allowing to combine and transform them with issue 93
4. pureconfig has a comprehensive README covering most of the functionalities but there is much work to do. Specifically, with issue 102 we want to move away from monolithic README to simplify its navigation and with issue 96 we will move to tut to be sure that the examples in the doc really work.

@ShaneDelmore and I would like to propose sbt-tls-crossproject and catz-cradle for both Typelevel github hosting and for the Typelevel incubator. Both are new projects, but the underlying work with scalafix has been ongoing for some months.

• sbt-tls-crossproject adds TLS as a platform to scala-native sbt-cross
• catz-cradle uses sbt-tls-crossproject and is the basis of an example project to rewrite cats based code, initially to scalaz. This is currently achieved by a fork of scalafix, the code there will be migrated to catz-cradle and eventually a new project, catz

We, the only two maintainers, would like to move the repos to TL ASAP, before we do the first releases.

Both projects and maintainers support the Typelevel CoC.

• Monifu is a high-performance Scala / Scala.js library for composing asynchronous and event-based programs using observable sequences
• Monifu supports the Typelevel code of conduct.

See https://github.com/alexandru/monifu.

I am considering submit some libraries for Typelevel incubator membership.

stateless-future is an open-source library I created three years ago when I was working for Shenzhen QiFun Network Corp., LTD.

Recently, I planned to pick the library up and keep maintaining it.
I wonder if it possible to rebrand it under typelevel organization.

• Scoverage is a code coverage tool for scala projects
• We want to move into a pure functional approach (as far as is possible when writing a compiler plugin)
• Scoverage seeks to aid pure functional programming
• It has a typelevel derived code of conduct
• We have a quorum in favour

• Delta provides type safe differences for ADTs.
• Delta supports the Typelevel code of conduct.

See https://github.com/stacycurl/delta

Following the success of the first two Typelevel Summits we have had a few invitations to hold more Typelevel days as satellites of other conferences. This is really good news and I think we should try and meet as much of that demand as we can.

So far we have held the following kinds of event in roughly decreasing order of how much time, effort and cost is involved,

• Conference with peer-reviewed presentations and on the day organization, refreshments, swag.
• Unconference with on the day organization, refreshments, swag.
• Hack day with minimal organization, snacks, no swag.

Organizer time is probably our scarcest resource, and it would be great if we could get together a list of people, with locations, who would be willing to help out with the organization of future events.

Please comment on this ticket if you would like to be involved.

Mouse is a small companion library to cats providing enrichments to std lib classes to ease functional programming and/or ease source compatibility with scalaz

Mouse supports the Typelevel code of conduct.

https://github.com/benhutchison/mouse

What is the Scala Center Advisory Board

To quote @propensive,

The Advisory Board is a separate body from the Scala Center, much as many governments have separate legislative and executive branches: the Advisory Board makes recommendations to the Scala Center on the work we should do, but it’s the Scala Center’s job to execute those recommendations.

It currently has seven voting members: representatives from each of our six sponsors, plus Bill Venners, the community representative. Additionally the Executive Director of the Scala Center, Heather Miller, sits on the board to report on the Scala Center’s activities, and provide advice on the feasibility of the proposals under consideration, and Martin Odersky is the technical advisor to the board.

(from http://www.scala-lang.org/blog/2016/05/30/scala-center-advisory-board.html)

Proposal

The Advisory Board has invited us to nominate a member of the Typelevel community to serve as a community representative, alongside Bill Venners. After some brief private discussions, @milessabin and I decided that whether or not we should accept this offer and who we pick should be decided in the open. Initial feedback from the Board supports this.

Obligations

To quote @propensive again,

The time commitment would be approximately two hours of meeting time per quarter, plus the commitment to being visible as a representative of the community (which would be shared with Bill). Meetings would be mostly done over Google Hangouts (though we aim for one physical meeting a year, colocated with a conference), and the next meeting is planned for some time in second half of November.

Questions

1. Should we accept this offer?
2. If yes, who should we pick?

Provisions

@milessabin and me think that it would be a good idea for the Typelevel representative to rotate every once in a while. @odersky has confirmed that this would be acceptable under two conditions:

1. The tenure should be at least one year to avoid having someone else at every other meeting.
2. The Advisory Board needs to confirm each successor.

Note that both points also apply to the initial candidate.

Nominees

Feel free to nominate people in this thread, except for

• @non
• @milessabin

who have privately expressed their preference not to be nominated (which is not a judgement on the proposal itself).

This will be sometime in October, date TBC.

• banana-rdf is a library for RDF, SPARQL and Linked Data technologies in Scala.
• banana-rdf supports the Code of Ethics and Professional Conduct.

See https://github.com/banana-rdf/banana-rdf

I would like to propose Hammock, a purely functional HTTP client for Scala, to the Typelevel incubator.

Regarding the criteria for submitting to the incubator:

1. I'm the only stakeholder of the project. Other people that was partially involved in it agreed and encouraged me to propose it.
2. There is a section in the README that states that people is expected to follow Typelevel CoC in this repository.
3. The project is currently based on Cats (also I'm planning cross compilation to Scalaz as well), and tries to be as functional as possible. For JSON encoding and decoding, provides hammock-circe packages, that make easy to use Circe encoders & decoders for HTTP. It also uses Monocle's optics for the high level API, Scalacheck & Discipline for law checking.
4. There is already a documentation site. All the docs are machine checked via tut.

Yesterday in the Cats Gitter channel some of us started talking about topics not strictly related to the Cats project, but still about functional programming in general (e.g. algebraic effects, Free, derivative parsers). There were some concerns around this perhaps being too off-putting for a channel like typelevel/cats and after brief discussion typelevel/oleg was created.

That created another concern which is that the naming of the channel might seem too clique-y and in general can come off as unwelcoming - a sort of typelevel/cool-kids.

This issue is to discuss if such an alternate room needs to be created at all, and if so what to name it. Potential names that have come up:

• general-fp
  • Has naming overlap with existing typelevel/general room
• theory
  • Has unfortunate implication of the (arguably false) theory/practicum dichotomy
• fp

• Finch is a thin layer of purely functional basic blocks atop of Finagle for building composable REST APIs.
• Finch supports the Typelevel code of conduct.

See https://github.com/finagle/finch.

I was chatting on the the scala/community-builds gitter about community builds and the scala center(SC). This particular link was regarding a scala.js community build.

So this issue it about getting more SC participation in this area. Right now, I'm not totally sure what that should be specifically - but I think there is a natural fit here.

But I'll make a start by saying that the scala community build is really for the benefit of scalac - fair enough, it is theirs. I can see why scala.js would want one too.

But many others projects could benefit from their own, too (eg typelevel) . So perhaps a goal of the SC could be to promote the development and use of community builds in general - and this would also nicely tie in with their scaladex.

cc/ @sjrd and @SethTisue as they were on the chat

At the last advisory board meeting, Heather has presented the draft of the new Scala Code of Conduct. It applies to the following domains:

The enforcement policies listed above apply to all official Scala channels: mailing lists, GitHub repositories and Gitter channels under scala and scalacenter, Discourse, and Scala Center venues and hackathons.

I suggest an official endorsement of this CoC from our side. This does not mean that we will adopt this CoC – that is a different discussion. (NB: I think that different discussion should happen soon-ish.)

I'm hoping that we can get out a message of support for official Scala channels adopting this CoC.

What I like in particular about the new draft is that it explicitly lists encouraged behaviour.

Does Typelevel need a permanent financial entity?

Can it get away with temporary financial entities for each conference?

So far, Typelevel has governed itself by general agreement. This has worked with little acrimony on issues like incubator applications, where two meritorious alternatives can both be accepted. It was discussed in Philadelphia that more difficult decisions will come. With #42, that day may be here.

1. Is it time to adopt a formal voting system?
2. What voting system do we use?
3. Who gets to vote? Is it always the same set when we vote?

This time the summit is planned to collocate with NEScala again. Shall we have a one day of talks and one day of unconference like last time? For talks do we want to continue do curated talks right? (NEScala is going to have community voting on talk proposals).
@larsrh will be overseeing the CFP process. Anyone else wants get involved in the review process?

docs.typelevel.org hosts some Scaladocs of current or ex-member projects. However:

• they're outdated; because
• docs are also served by Sonatype directly (via javadoc-badge).

Removing the domain altogether would probably be beneficial. Potential risk: Breaking links.

Hello,

Opening this ticket to request full membership for the Monix project.

It's been a year since Monix has entered the Typelevel Incubator.

About the criteria:

• the project evolved to exemplify functional programming and to protect users against using "hot" data source that are stateful - naturally some parts of the project are not FP (e.g. monix-execution), however those parts are separated and necessary, because Monix went ahead in expanding the standard library with the necessary low level primitives needed for concurrency handling; we also have Cats integration, along with Scalaz, because the goal has always been to interact well with others within the ecosystem
• we have documentation type checked with tut at monix.io/docs/2x/; more documentation is needed of course, will come in time, because it's highly technical and difficult to write; the last document I wrote for example has been on MVar
• we always had very complete ScalaDocs as well
• versioning is semantic and recently I integrated MiMa to help with that
• Monix has been my love child and I never stopped developing or maintaining it ever since its inception; it has one other part time maintainer as well and my pride is that the code in Monix is high-quality enough that people understand even highly challenging pieces, see this recent bug report for example

Cheers,

• Scala Exercises it's a platform and framework for Scala devs to learn about Scala libs.
• It follows the Typelevel Code of Conduct.
• it follows a typeful, purely functional approach where possible.
• It features many Typelevel libs exercises and more to come.
• It backlinks to Typelevel as reference for learning FP in Scala.
  Thanks for your consideration :)

https://www.scala-exercises.org/
https://github.com/scala-exercises/scala-exercises

We are discussing having a Typelevel track at Scala.IO in Lyon, 27/28th October.

Currently this is,

• @milessabin
• @larsrh
• @non (aka @d6 on Twitter)
• @tixxit

• Fetch is a library built on top of Cats that provides efficient data access from heterogeneous datasources.
• it follows a typeful, purely functional approach.
• it follows the Typelevel Code of Conduct

https://github.com/47deg/fetch/blob/master/CONTRIBUTING.md
https://github.com/47deg/fetch
http://47deg.github.io/fetch/docs

As discussed at the Philadelphia summit we expect most decision making to be by consensus and to happen publicly on this github project, via the gitter channel, issues (such as this one) and pull requests.

We also recognized that there will be (hopefully rare) circumstances where it will be necessary for Typelevel to be contactable and to come to a decision privately and maybe very quickly, before going to a wider forum. Examples of this might relate to a code of conduct violation at a Typelevel event, or on a gitter channel, mailing list etc.; the status of a project as a member of Typelevel in case of a dispute which can't be resolved by consensus; responses to public announcement (eg. the launch of the Scala Center) which we can't discuss publicly because we've been asked to respect confidentiality; discussions with potential sponsors of Typelevel events before they're finalized; and so on.

That being so, we need a somewhat formal list of people who can constitute a group who can be contacted and make an initial judgement on how to proceed. The feeling at the Philadelphia summit is that there is already a de facto list, and that we should make it explicit ... that's the purpose of this issue.

The consensus at the meeting was that the list should initially include the four people named as contacts on the Typelevel code of conduct, plus the Cats maintainers plus @larsrh (who should really be on the CoC contact list). That makes the list,

• @adelbertc
• @ceedubs
• @fthomas
• @julien-truffaut
• @larsrh
• @milessabin
• @mpilquist
• @non
• @rossabaker
• @stew
• @tpolecat
• @travisbrown

Please note that this is an initial list, and can/will/should change over time. It's pretty clearly not a diverse list, and it's important that we fix that ASAP.

I have been using the following bullet points as a summary of the Typelevel mission in the talks I've given on Typelevel recently,

Typelevel is a community of projects and individuals organized around ...

• Pure, typeful, functional programming in Scala
• Independent, free/libre and open source software
• A desire to share ideas and code
• Accessible and idiomatic learning resources
• An inclusive, welcoming and safe environment

I've also been pointing people at Erik's talk at Scala World in 2015 for elaboration on the community aspect.

I believe that both the bullets and Erik's talk are consistent with what we've discussed and our tacit understanding, but it would be good to have this endorsed (or not) a little more formally.

I'm the author of cats-scalatest. It seems silly that I haven't added it as a typelevel project so that people can find it when they start using cats.

I'm committed to the CoC and have been active in the typelevel community.

Is there anything else I need to do to get it added?