Re: vectorisation code?

[Ben Gamari]

Ben Gamari  writes:

> Geoffrey Mainland  writes:
>
>> Hi Ben,
>>
Hi Geoff,

>> Progress is stalled on a rewrite of DPH's use of TH since TH is no
>> longer available in stage1. There is no reason this can't be worked
>> around, just that it's more work than I initially expected.
>>
> Alright, thanks for the update Geoff!
>
Any news on this front? 8.2 isn't imminent but it's certainly on the horizon
so it would be good to get this taken care of in the next month or so.

Cheers,

- Ben


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

Re: ghc command line arguments parsing

[Harendra Kumar]

On 19 August 2016 at 14:42, Sven Panne  wrote:

>
> Hmmm, do we need '--ghc-args=' at all when we have '--' as the border
> between the 2 "argument worlds"? Without thinking too much about it, :-} I
> guess we don't. This would be consistent with how e.g. "stack exec" or
> "gdb" work. An explicit option --pass-this-to-some-progXY is only needed
> when there are more than 2 "argument worlds" involved, otherwise '--' is
> enough, and also easier to type/remember.
>

Hmm, I have been there :-) There is a slight gotcha here. This is how the
runghc command looks like:

runghc [runghc flags] [--] [GHC flags] progname [prog args]

The regular '--' separation works well when we have only two worlds; we
consume upto '--' and give the rest opaquely to the other one. Here we have
three  scopes, we need to separate runghc flags, GHC flags, program and its
args. In the above command we cannot distinguish a GHC arg from progname.

One way to solve that is to put another mandatory '--' after the GHC flags
so that GHC flags are always delimited. With that here are the valid forms
of the command:

1) runghc [runghc flags] progname [prog args]

2) runghc [runghc flags] -- progname [prog args]
3) runghc [runghc flags] -- [GHC flags] -- progname [prog args]

For simplicity we will only pass GHC args using the 3rd form of the command
even if they are not conflicting with runghc flags. Note that these changes
will be incompatible with the previous implementation. Does this sound ok?
Or we keep the good old '--ghc-arg='?

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

RE: Landing Backpack in HEAD

[Simon Peyton Jones via ghc-devs]

I'm supportive of doing this, and am working with Edward on it. Yell if you 
object.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Edward Z. Yang
|  Sent: 11 August 2016 20:07
|  To: ghc-devs 
|  Subject: Landing Backpack in HEAD
|  
|  Hello friends,
|  
|  I'm hoping to land Backpack (the patch is two years in the making
|  now!) for GHC 8.2, even though 8.2 is intended to be a stabilization
|  and performance release.  In this email, I will make the case that the
|  Backpack patch is relatively self-contained and will not affect non-
|  Backpack users, and explain how you might be affected by the patch.
|  The most recent patchset can be found at
|  https://github.com/ezyang/ghc/tree/ghc-backpack ; look for "The
|  Backpack patch" in the commit log, since I plan on squashing these
|  commits before committing.
|  
|  OK, here is what is in the patchset that affects non-Backpack users:
|  
|  - The primary, overarching change is that there is now
|a distinction between "semantic" and "identity" modules.
|This solves a problem with hsig files:  suppose
|you have A.hsig which defines data T in package p.
|The resulting A.hi is most accurately identified
|as p[A=]:A; however, the Name for T should be .T,
|not p[A=]:A.T.  The former is an identity module
|(it *identifies* interfaces), whereas the latter is a semantic
|module (it is what is used in names).  Without Backpack,
|these two identities are always the same.  There are a number
|of places in the existing codepaths where we have to
|distinguish between the two concepts (sometimes you
|want semantic, sometimes you want identity); we DEFAULT
|to the identity module but I fix a few cases where
|semantic modules were desired instead.
|  
|  - UnitId is generalized to also record how a component
|is instantiated (a mapping from module names to modules.)
|Without Backpack this is blank and equivalent to the
|existing UnitId.
|  
|  - Packages has been refactored to also handle Backpack `-unit-id`
|flags, since we have to do some extra work to determine
|what inherited signatures merge where.
|  
|  - The patch REVERTS all of the old support we had for hsig
|files; -sig-of is no more.  spinda had mentioned that
|Liquid Haskell used this in some cases, and I'm looking
|at supporting *just* their particular use-case.
|  
|  - A new driver mode --backpack, which process test.bkp files.
|This mode is used PURELY for testing, and end users
|are not supposed to use it.  These all live in their own
|modules (BkpSyn, DriverBkp) except for some modest,
|convenient extensions to the lexer and parser to parse
|multiple modules at once.
|  
|  The patch also comes with rewritten typechecking support for hsig
|  files, and instantiating indefinite packages on the fly, but these are
|  all standalone pieces of functionality which are not tied to any
|  existing compiler infrastructure.
|  
|  Thanks,
|  Edward
|  ___
|  ghc-devs mailing list
|  ghc-devs@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs=02%7c01%7csimonpj%40microsoft.com%7c53ecc3a967e94989c6ea08d3
|  c21aba4a%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c6360653924505858
|  34=M9gGg0DYYyLgiETs8bYGuxLlU7uVDJweyo5NeJB2bDM%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghc command line arguments parsing

[Sven Panne]

2016-08-19 10:58 GMT+02:00 Harendra Kumar :

> Funnily consistency was my point too and not convenience. I totally agree
> that consistency is more important. The end objective is less referring to
> manuals and rely more on intuition and consistency. Its all about making it
> easier to remember and not about typing less or more. [...]
>

OK, then I probably misunderstood you and we're actually in the same
boat... :-)


> [...] As you said I would be happier with an inconvenient to type but
> consistent alternative where we use '--ghc-arg=' for everything and get rid
> of the other ways. [...]
>

Hmmm, do we need '--ghc-args=' at all when we have '--' as the border
between the 2 "argument worlds"? Without thinking too much about it, :-} I
guess we don't. This would be consistent with how e.g. "stack exec" or
"gdb" work. An explicit option --pass-this-to-some-progXY is only needed
when there are more than 2 "argument worlds" involved, otherwise '--' is
enough, and also easier to type/remember.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghc command line arguments parsing

[Harendra Kumar]

On 19 August 2016 at 12:31, Sven Panne  wrote:

> 2016-08-18 19:59 GMT+02:00 Harendra Kumar :
>
>> [...]  It only parses a flag which takes an argument. [...]
>>
>
> o_O AFAICT, this is even more non-standard and quite surprising...
>
>
>> As I explained above, I would prefer to keep this bug :-) and document it
>> especially for runghc as a better alternative to --ghc-arg=foo . [...]
>>
>
> While I partly understand your motivation, convenience is often the worst
> reason for doing something. Consistency is IMHO infinitely more valuable
> than having various inconsistent ad-hoc "convenient" shortcuts here and
> there. If you look around the tool landscape, commandline argument parsing
> is already less consistent than it should be (try e.g.
> ps/tar/unzip/df/java/git/...), and I don't think we should make this
> situation worse by adding yet another variation.
>
> As long as we have a way to pass arguments down the pipeline (as we
> obviously have), thing are fine IMHO. This situation is not much different
> from the common -Wl,foo option for GCC and friends to pass arguments to the
> linker. And to be honest: How often do you really *type* long commandlines
> compared to putting them into some kind of script?
>

Funnily consistency was my point too and not convenience. I totally agree
that consistency is more important. The end objective is less referring to
manuals and rely more on intuition and consistency. Its all about making it
easier to remember and not about typing less or more. But what I find
consistent you find it inconsistent :-) Maybe I am squinting too much to
see it that way. Let me explain it a bit.

I see each flag as a single unit including its argument. In fact command
line tools often combine the flag and value e.g. -f/path/to/ghc and -f
/path/to/ghc mean the same thing to runghc. This is usually done for a
single character flag only because it is unambiguous to parse even with
using a space separator. If we generalize this we can also allow a space in
the combined value if escaped e.g. -package foo and "-package foo" can be
considered the same thing. If we look at flags in this way they in fact
look more consistent - everything i.e. all flags start with a dash.

In fact I discovered that it works this way because I intuitively guessed
it, runghc CLI help did not have any mention of how to pass such args to
ghc. I discovered '--ghc-arg=' only later in users guide.

I would be happier with a gcc style -Wl,foo or -Xlinker way because it is
more consistent compared to how runghc passes options to ghc. runghc has
two ways of handling ghc options. Options starting with a dash are passed
even without having to use '--ghc-arg=' and if they conflict with runghc
options then we use '--' to separate the two. If a ghc option does not
start with a dash then we use '--ghc-arg'. Three different ways! too
complicated to remember or think about. As you said I would be happier with
an inconvenient to type but consistent alternative where we use
'--ghc-arg=' for everything and get rid of the other ways. Originally I was
trying to do it the other way round by getting rid of '--ghc-arg' instead.
But this perhaps sounds easier to think about. Let me know what you think.

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

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

(Sorry if anybody receives this twice, I think I flubbed my 'send'.)

On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote:
> Yet my vote is with "bespoke". Short, informative, recognizable, and a
> nice balance of quirky and reasonable, just like so much else here.
> 

... oh, and might I submit the opinion that quirky is not a quality that
to be desired of a programming language, even if it's only a keyword?

(Anyway, I think I'll stop here. This is too much opinion for any
further discussion to be useful.)

Regards,


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

Re: Request for feedback: deriving strategies syntax

[Bardur Arantsson]

On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote:
>> Honestly, I don't care particularly much which exact word it becomes
>> just as long at isn't some 'cute' or obscurse[1] word.
>>
>> 'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in
>> the latter.
> I'm native German. I never was in any English-speaking country in my
> life. Almost all my English media is from the USA. I'm not a tailor. Yet
> "bespoke" was familiar and instantly tells me what's important.
> So I may just be one point on the map, but I am not sure your argument
> that it is "obscure" is valid, sorry.
> 
> That being said, let me add a package of "a"s for all the times an
> English native complains that he has to learn a new word to program.
> Take a portion and pass it along, would you? ;)
> 
> Apropos learning words: while searching for information if "bespoke" is
> really obscure (I found none in either direction) I stumbled upon some
> (I think) not-yet-mentioned possible options
> 

I said it was *needlessly* obscure. There's absolutely no reason to
choose such a word in this case.

> * custom(i[zs]ed)?

This seems to convey the exact opposite when used in the programming
domain. When I 'customize' something or specify a 'custom' $something, I
expect that I, the programmer, am going to provide the
logic/behavior/whatever.

> * tailored

Just as 'bad' as bespoke -- and still has a sort of feeling of
'customized'. Bespoke at least has the very strong connotation of
"getting someone else to do it for you" whereas tailored doesn't *quite*
have that. (All, IMO, of course.)

Regards,

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

Re: Request for feedback: deriving strategies syntax

[Phil Ruffwind]

I would prefer "custom" simply because the word is used often enough in
computing that there is no chance of someone having to pull out a
dictionary for it.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghc command line arguments parsing

[Sven Panne]

2016-08-18 19:59 GMT+02:00 Harendra Kumar :

> [...]  It only parses a flag which takes an argument. [...]
>

o_O AFAICT, this is even more non-standard and quite surprising...


> As I explained above, I would prefer to keep this bug :-) and document it
> especially for runghc as a better alternative to --ghc-arg=foo . [...]
>

While I partly understand your motivation, convenience is often the worst
reason for doing something. Consistency is IMHO infinitely more valuable
than having various inconsistent ad-hoc "convenient" shortcuts here and
there. If you look around the tool landscape, commandline argument parsing
is already less consistent than it should be (try e.g.
ps/tar/unzip/df/java/git/...), and I don't think we should make this
situation worse by adding yet another variation.

As long as we have a way to pass arguments down the pipeline (as we
obviously have), thing are fine IMHO. This situation is not much different
from the common -Wl,foo option for GCC and friends to pass arguments to the
linker. And to be honest: How often do you really *type* long commandlines
compared to putting them into some kind of script?

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