Re: GHC Logo

[John Cotton Ericson]

Yeah I think the old "functional programming is slow" memes died off 
about when the rest of the industry went on its JavaScript bender, so I 
am not really worried about the negative connotations of turtles.


The positive connotations of turtles sounds very good to me. Besides safety,

 *   the longevity of at least giant tortoises also speaks to GHC's
   rare ability to stay at the vanguard of research while still being
   wildly used.
 * Their ability to walk and swim speaks to the diverse backends that
   can be attached to GHC (NCG, LLVM, GHCJS, Asterius, Clash's, etc.).
 * Even the fable, from which the slowness myth comes from I guess,
   goes well with "avoid success at all costs".

Conversely I am not a fan of choosing a Cat. I like Cats fine in real 
life, don't get be wrong, but Cats are so popular on the internet that 
this would be the the unmarked animal choice, with no clear connotations 
or memorability. I think that would be the juvenile choice, per Ben's 
slippery slope.


Foxes are nice, but I think Firefox has that for life.

Octopuses are alright. GitHub's Octocat doesn't doesn't pose nearly as 
much of a problem as Firefox for foxes. Still, while Octopuses are 
smart, they are usually solitary and mischievous. GHC is very much a 
long-term group effort, belying the solitary connotation, and I 
certainly hope any compiler I use isn't mischievous!


A turtle for a compiler is a bold choice that indicates our values, 
confidence that the performance of compiled code is immune to cheap 
derision, and humor.


John

P.S. The funny patterns on turtles' backs could be made of lambdas?...

P.P.S. and yes, if it does compel us to fix rampant list appending just 
so we're fast on all fronts, that would be nice too :).


On 9/2/20 11:47 AM, Ben Gamari wrote:

Richard Eisenberg  writes:


I'm oddly drawn to the idea of a turtle -- except that turtles are
slow. But animals are cute. Maybe something involving a fox, given
that foxes can be clever? Octopuses are also known to be very clever,
but maybe GitHub has octopuses covered.


In general I'm rather neutral on the logo question. There is a fine line
between "juvenile" (which may detract from the project's credibility in
the eyes of some) and "cute" (which I think is universally a Good
Thing); the current rather boring logo was a quick attempt to satisfy
the need for some logo while recognizing that I lack the artistic
ability to walk that line. I don't think it's a bad logo but it's quite
dull and far from being a *good* logo. I do hope someone steps up to do
better.

Logos aside, I do feel the need to correct the record here: you
clearly have not seen how quickly a turtle can move when offered banana
or shrimp. They can be quite quick when suitably incentivized!

Cheers,

- Ben

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Implicit reboxing of unboxed tuple in let-patterns

[John Cotton Ericson]

I haven't used unboxed tuples enough to perhaps feel the pain, but on 
paper the current design makes sense to me. The laziness of the binding 
is suppose to have to do with the runtime rep of the binding itself, not 
any enclosing pattern.


For example take

    {-# LANGUAGE ScopedTypeVariables #-}
    {-# LANGUAGE MagicHash #-}

    import GHC.Base

    data Foo = Foo Int# Int#

    main = pure ()
    where Foo x y = Foo undefined undefined

This program will fail even though x and y are unused.

While this principle may not match how this stuff is used in practice, 
the alternative of making the strictness of the bindings depend on more 
than their runtime reps seems less-local / more ad-hoc to me.


John

On 8/31/20 10:34 AM, Spiwack, Arnaud wrote:


I’ve been pointed to 
https://github.com/ghc-proposals/ghc-proposals/pull/35 where this was 
debated a few years ago. With much of the same arguments as today.


Simon Marlow said

making an unboxed tuple binding lazy by default seems to be
intuitively the wrong choice. I guarantee I would get tripped up
by this! Giving unboxed tuples an implicit bang seems reasonable
to me.

I can share that I got tripped by it. And so were other members of my 
team.


That being said, Richard seemed to feel rather strongly about this 
one. Richard, do you still agree with your then position that |let 
(#x, y#) = …| being a lazy pattern (hence implicitly boxes the pair) 
is the right semantics?



On Fri, Aug 28, 2020 at 8:26 PM chessai > wrote:


Arnaud,

I have dealt with this in the past and find the laziness extremely
counterintuitive and never wanted. Every time I have let-bound an
unboxed tuple, I have never wanted that boxing to occur. Perhaps
there is a good reason this is the case but I wish it would change.

On Fri, Aug 28, 2020, 08:26 Spiwack, Arnaud
mailto:arnaud.spiw...@tweag.io>> wrote:

Hi Carter,

We are using |let !(#x,y#) = …| actually. Having the strict
behaviour is not particularly difficult. You can even use
|case … of (#x, y#) ->…| directly, it’s not too bad. My
complaint, as it were, is solely about the potential for mistakes.


On Fri, Aug 28, 2020 at 3:20 PM Carter Schonwald
mailto:carter.schonw...@gmail.com>> wrote:

Have you tried using do notation for bindings you want to
keep strict, with Eg the identity monad?  That doesn’t
address  the design critique but gives you a path forward ?

I do agree that the semantics / default recursivity Of let
bindings  can be inappropriate for non recursive code ,
but would any other non uniform semantics or optimization
be safe?

On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud
mailto:arnaud.spiw...@tweag.io>>
wrote:

Dear all,



I discovered the hard way, yesterday, that lazy let
pattern
matching is allowed on unboxed tuples. And that it
implicitly reboxes
the pattern.



Here is how the manual describes it, from the relevant
section

:





You can have an unboxed tuple in a pattern
binding, thus



|f x = let (# p,q #) = h x in ..body.. |



If the types of |p| and |q| are not unboxed, the
resulting binding is lazy like any other Haskell
pattern binding. The above example desugars like this:



|f x = let t = case h x of { (# p,q #) -> (p,q) }
p = fst t q = snd t in ..body.. |



Indeed, the bindings can even be recursive.





Notice how |h x| is lazily bound, hence won’t
necessarily be run when
|body| is forced. as opposed to if I had written, for
instance,



|let u = hx in ..body.. |



My question is: are we happy with this? I did find
this extremely
surprising. If I’m using unboxed tuples, it’s because
I want to
guarantee to myself a strict, unboxed behaviour. But a
very subtle
syntactic detail seems to break this expectation for
me. My
expectation would be that I would need to explicitly
rebox things
before they get lazy again.



I find that this behaviour invites trouble. But you
may disagree. Let
me know!





___

ghc-devs mailing list

  

Re: Question about binary distributions

[John Cotton Ericson]

Per https://gitlab.haskell.org/ghc/ghc/issues/17191 I do hope to break 
up our configure script soon.[1] Then the bindist will need not ship the 
"entire" configure script, but just what is necessary to fill in the 
settings file(s) which have that information Ben mentions.


I think that will improve the optics of the situation a bit; for 
example, I don't think the reduced bindist configure script should need 
to worry about directories at all since GHC is relocatable (when built 
by Hadrian).


John

[1]: I will be able to resume work on that once I get to the bottom of 
https://gitlab.haskell.org/ghc/ghc/merge_requests/1102. All help greatly 
appreciated!


On 8/7/20 11:15 AM, Ben Gamari wrote:

"Mathieu Boespflug"  writes:


Hi all,

GHC currently has 3 tier-1 platforms: Linux, macOS and Windows. I'll
focus the dicussion below on these three platforms. The binary
distributions for Linux and macOS are designed to be unpacked, then
the user types ./configure && make install. This is not the case for
Windows.

On all platforms it's possible to create "relocatable" installations,
such that GHC doesn't really care where it's installed, and commands
will still work if the install directory changes location on the
filesystem. So my question is, why do we have a ./configure step on
Linux and macOS? Why could we not have bindists for all platforms that
work like the Windows one? I.e. a binary distribution that you just
unpack, in any directory of your choice, without any configuration or
installation step.

There are a few reasons:

  * Relocatable GHC builds have only been supported for only a few
releases now and only under the Hadrian build system, which is not
currently used to produce our binary distributions (hopefully this
will change for 9.2).

  * On Windows we have the luxury of having a very well-controlled
environment as we rely on essentially nothing from the host
system. We provide our own mingw toolchain, statically link
against libc, and have no additional dynamic dependencies.

By contrast, on Linux we have to deal with a much larger
configuration space:

 * several linkers, each with their own bugs

 * several C compilers, supporting various subsets of functionality
   and quirks (e.g. some distributions enable -pie by default, others
   do not)

 * various LLVM packaging schemes

Since it would be quite expensive to probe the toolchain
characteristics on every compiler invocation, we rather do this once
in the configure script during bindist installation and package the
result in the installed `settings` file.

  * On Linux we may have additional dynamic dependencies (e.g. libdw,
numactl) which we check for during configuration time, lest the user
be faced with an unsightly linker error if they happen to be missing
a library.

In principle we could perhaps avoid the need for many of these checks
by creating one binary distribution per operating system distribution.
However, we will first need to move to Hadrian to build our binary
distributions.

Cheers,

- Ben

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Using a development snapshot of happy

[John Cotton Ericson]

Big +1 on this. There area few experiments I'd like try with Happy that 
I think this will help with, too.


On 8/2/20 4:18 AM, Moritz Angermann wrote:

This dependency on alex and happy to boot ghc has been annoying, but
wasn't  that terrible until a while ago when some
ghc versions needed happy <= 1.19.11 and others happy >= 1.19.12. If
happy was part of ghc, this would not have been an issue.
As such I'd be on board with adding happy *and* alex as submodules
into the `utils` folder. And thereby reducing the external
boot dependencies of ghc!

I believe
- `compiler/ghc.cabal.in` would need to get a `build-tool-depends:`
stanza for happy and alex,
- `utils/genprimopcode/genprimopcode.cabal` same
- `utils/hpc/hpc-bin.cabal` same for happy only.
For `hadrian`, you'd need to make it aware of happy and alex packages
in `hadrian/src/Packages.hs`.
(Just follow other "util"s in there, e.g. unlit or touchy).

In general hadrian should follow cabal dependencies properly.

cheers,
  Moritz

On Sun, Aug 2, 2020 at 3:43 PM Vladislav Zavialov  wrote:

Hi ghc-devs,

I’m working on the unification of parsers for terms and types, and one of the 
things I’d really like to make use of is a feature I implemented in ‘happy’ in 
October 2019 (9 months ago):

   https://github.com/simonmar/happy/pull/153

It’s been merged upstream, but there has been no release of ‘happy’, despite 
repeated requests:

   1. I asked for a release in December: 
https://github.com/simonmar/happy/issues/164
   2. Ben asked for a release a month ago: 
https://github.com/simonmar/happy/issues/168

I see two solutions here:

   a) Find a co-maintainer for ‘happy’ who could make releases more frequently 
(I understand the current maintainers probably don’t have the time to do it).
   b) Use a development snapshot of ‘happy’ in GHC

Maybe we need to do both, but one reason I’d like to see (b) in particular 
happen is that I can imagine introducing more features to ‘happy’ for use in 
GHC, and it’d be nice not to wait for a release every time. For instance, there 
are some changes I’d like to make to happy/alex in order to implement #17750

So here are two questions I have:

   1. Are there any objections to this idea?
   2. If not, could someone more familiar with the build process guide me as to 
how this should be implemented? Do I add ‘happy’ as a submodule and change 
something in the ./configure script, or is there more to it? Do I need to 
modify make/hadrian, and if so, then how?

Thanks,
- Vlad
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How should we treat changes to the GHC API?

[John Cotton Ericson]

On 7/31/20 9:27 AM, Simon Peyton Jones via ghc-devs wrote:


My real question is this:

  * Who “owns” (as in: takes responsibility for) the GHC API?

I guess one thing very important to me is that the architecture of GHC 
and it's public interfaces will always be deeply intertwined; or put a 
different way, efforts to manager the public interface as a thin veneer 
over a big black box will not work.



  * What *is* a good public API?  Where is it written down?

This I agree is important to discuss. I do agree with Moritz that a lot 
of this stuff can be evolved, but the general direction can be still be 
discussed. For example, the basic objects I offered are a *huge* 
departure from what we have today, and any huge change should be 
discussed up front a bit.



  * What should GHC’s extensibility interface be like?   Plugins and
all that.  What is a good design for (say) extensible interface
files?  What “hooks” should the GHC API afford? This is more than
just “what arguments should this function take”… it’s a matter of
fundamental design.   But design questions like this belong in the
GHC-API world (not the core GHC world) because they are all about
extension points.
  * What is a good design for the plugins story more generally?

I've mentioned this before but I think plugins/hooks/etc. are a terrible 
way to reuse GHC for other purposes, and exist as a symptom of the rest 
of the compiler not being at all modular. It's fine that we continue to 
support them in the short term, but in the long term I'd really like to 
have a plan to obviate them completely. (One can search "composition 
over configuration" and variations on that slogan to find much ink has 
been spilled on this general principle.)


John


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Old build system broken

[John Cotton Ericson]

Yeah so what I did is making settings no longer be created directly by 
configure, but by make and hadrian. I did this because I'm moving 
configurations options from Config.hs to there, Config.hs was generated 
by make and hadrian, and the whole thing will become stage-specific.


I tried do mimic what hadrian/make for `Config.hs` and the various 
header files like `ghcplatform.h`, but evidently I missed how those are 
invalidated / cleaned up (unless they change so infrequently that 
cleaning up never worked).


I'm happy to make the fix (especially as I hope to change `settings` 
some more), but I would appreciate some advise from people in the know 
about how the cleaning ought to work. I suspect the cleaning with both 
build systems is broken.


Sorry for the disruption,

John

On 5/8/19 4:33 PM, Richard Eisenberg wrote:

Some discussion on IRC with @Ericson2314 reveals that make maintainer-clean is 
not deleting settings files, which cause this bug. If you do a fresh checkout 
and build, the problem should go away. It's also possible that deleting 
inplace/lib/settings manually (and then running ./configure) may also fix it.

Richard


On May 8, 2019, at 3:51 PM, Richard Eisenberg  wrote:

Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), but I 
don't have the error message any more. It mentioned "Tables next to code" and 
the settings file, so I'm confident that it's related.

Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem for 
me.

Richard


On May 8, 2019, at 3:48 PM, Karel Gardas  wrote:


Sorry to hijack the thread, I get something very similar on ppc64le linux:

Configuring ghc-prim-0.6.1...
ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error:
No entry for "Tables next to code" in "/tmpram/ghc/inplace/lib/settings"

libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/package-data.mk' failed
make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
Makefile:123: recipe for target 'all' failed
make: *** [all] Error 2

this is from today's HEAD.

Thanks,
Karel

On 05/ 8/19 09:28 PM, Phyx wrote:

That looks like stage1 has been improperly configured.

Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info
*
*
*Return anything sensible for target arch? *
*
*
*I still use the make system exclusively and haven't noticed a failure. *
*
*
*But my nightlies haven't kicked off yet today. *
*
*
*Thanks, *
*Tamar
*
Sent from my Mobile

On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs
mailto:ghc-devs@haskell.org>> wrote:

   I know we are supposed to be using Hadrian now, but is the old build
   system supposed to be broken? 

   A clean build fails with

   "inplace/bin/ghc-cabal" check libraries/ghc-prim

   "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
   --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
   --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
   --disable-library-for-ghci --enable-library-vanilla
   --enable-library-for-ghci --disable-library-profiling
   --enable-shared --configure-option=CFLAGS="-Wall
   -Werror=unused-but-set-variable -Wno-error=inline"
   --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
   --gcc-options="-Wall -Werror=unused-but-set-variable
   -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold"
   --with-ar="ar" --with-alex="/usr/bin/alex"
   --with-happy="/usr/bin/happy"

   Configuring ghc-prim-0.6.1...

   ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited
   with an

   error:

   Failed to read "target arch" value ""

   __ __

   libraries/ghc-prim/ghc.mk:4 : recipe for target
   'libraries/ghc-prim/dist-install/package-data.mk
   ' failed

   make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk
   ] Error 1

   Makefile:123: recipe for target 'all' failed

   make: *** [all] Error 2

   simonpj@MSRC-3645512:~/code/HEAD$

   ___
   ghc-devs mailing list
   ghc-devs@haskell.org 
   http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs