port A as M
> x = True
>
> I think that it'd be quite confusing if a single recursive module worked
> differently then a larger recursive group, but it is not at all obvious why
> B should export 'x'. And for those who like this kind of puzzle: what
> should happen i
ne
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskel
the result you pass to the compiler.
John
On Sat, Jul 5, 2014 at 1:09 PM, Luite Stegeman wrote:
> How would you do reification with that approach?
>
>
> On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote:
>>
>> Actually, I was looking into it a little, an
rberos, infrastructure, xmonad http://sinenomine.net
--
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> and got: Error: package file was not signed correctly.
> D
>
> On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote:
>> In case anyone wanted to start writing haskell android code now, jhc
>> fully supports android as a target. here is an app made with it
>>
>>
com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs
>>> [3]
>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js
>>> [4]
>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29
>>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
--
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
t not super/subscripts. I wish we could just abandon things like `a'bc'd`
> altogether...
>
>
> On 06/15/2014 03:58 AM, John Meacham wrote:
>>
>> I have this feature in jhc, where I have a 'trailing' character class
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
--
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
ing 7.9/7.10+ used ′ somewhere. Even using CPP based on
> version of the compiler used is not too great in this scenario because
> it doesn't bring significant practical advantage to justify the CPP
> clutter in code. If the choice is either extra lines due to CPP or using
> ‘'
ious stab at the problem[2].
>
> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion to
> the GHC users list.
>
> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
single lexemes and turned reservedids into
varids for the keywords of unenabled extensions.
John
-- John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
the package
imports in addition to language features, but this may be undesireable
as then it would behave differently when specified in a LANGUAGE
pragma.
John
--
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
G
, Herbert Valerio Riedel wrote:
> On 2014-05-30 at 11:00:38 +0200, John Meacham wrote:
>> JHC has the feature that
>>
>> Graphics.UI.GTK.Button can live in any of:
>>
>> Graphics/UI/GTK/Button.hs
>> Graphics/UI/GTK.Button.hs
>> Graphics/UI.GTK.Bu
simplicity and explicitly.
>
> If a central tool like GHC adds this behaviour, then all other
> tools are forced to follow.
Well, I just proposed it as an alternative to some of the other ideas
floated here. A command line flag like -i would definitely be ghc
specific and inherently non-porta
ages that use this feature without
> also specifying ghc >= 7.10 and some cabal-version too.
> - Are there other tools/libraries that will need changes? Leksah?
>
> Cheers,
> Simon
> ___
> Glasgow-haskell-users mailing list
> Glasgow
a goes to next depends on simple pattern
matching on current symbol and current top of stack and can be listed
as a set of tuples.
in other words, a textbook deterministic push down automaton.
John
On Wed, May 14, 2014 at 7:29 AM, Ian Lynagh wrote:
> On Tue, May 13, 2014 at 11:20
Okay, I believe I have come up with a modified version that accepts many more
programs and doesn't require complicated comma handling, you can make all
decisions based on the top of the context stack. It also allows many useful
layouts that were illegal under the old system.
The main change was to
ule would give a different token
> sequence to the old rule, and warn if so.
Yeah, it would be tricky in jhc to support both front ends, though... maybe
I can revert my current lexer parser back to simpler haskell 98 syntax and
require anything that uses extensions to use the new layout rule.
T
John
--
John Meacham - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
kiwamu has been targeting an arm cortex-m3 succesfully with jhc. this
is a CPU with 40k of RAM running Haskell code very much on bare metal.
:)
John
On Tue, Mar 19, 2013 at 6:07 PM, Jeremy Shaw wrote:
> There have been at least a couple projects, such as hOp and HaLVM
> which attempt to run
On Fri, Jan 25, 2013 at 7:19 AM, Ross Paterson wrote:
> GHC implements data kinds by promoting data declarations of a certain
> restricted form, but I wonder if it would be better to have a special
> syntax for kind definitions, say
>
> data kind Nat = Zero | Succ Nat
>
This is exactly the syn
I support a form of this in jhc by allowing specialization of values,
not just types.
It is actually the same mechanism as type specialization since that is
just value specialization where the value being specialized on is the
type parameter.
foo :: Bool -> Int
{-# SPECIALIZE foo True :: Int #-}
Can you use 'dup' to copy the file descriptor and return that version?
That will keep a reference to the file even if haskell closes the
original descriptor.
John
On Sat, Mar 10, 2012 at 5:31 PM, Volker Wysk wrote:
> Hi
>
> This is an addition to my previous post.
>
>
> This modified versio
Out of curiosity, Is the reason you keep track of mutable vs not
mutable heap allocations in order to optimize the generational garbage
collector? as in, if a non-mutable value is placed in an older
generation you don't need to worry about it being updated with a link
to a newer one or is there ano
On Wed, Mar 7, 2012 at 5:01 PM, Johan Tibell wrote:
> On Wed, Mar 7, 2012 at 4:38 PM, Brandon Allbery wrote:
>> I think the original type signature is needed to figure it out. In the
>> earlier example it indicated ghc drilling down into the type (a tuple) and
>> determining the strictness of th
Ah, looks like it got a bit more complicated since I looked at it
last... time to update jhc :)
Actually. not sure if the Eval/Box split is relevant to my core. hmm
John
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
ht
On Wed, Mar 7, 2012 at 3:26 PM, John Meacham wrote:
> L = lazy
> S = strict
> A = absent
>
> f :: Int -> (Char,Char) -> Int -> Char
>
> LS(S,L)A
>
> means that it is lazy in the first int, strict in the tuple, strict in
> the first argument of the tup
L = lazy
S = strict
A = absent
f :: Int -> (Char,Char) -> Int -> Char
LS(S,L)A
means that it is lazy in the first int, strict in the tuple, strict in
the first argument of the tuple but lazy in the second and the third
argument is not used at all. I have a paper that describes it
somewhere. I mo
On Sun, Feb 19, 2012 at 4:21 PM, AntC wrote:
>>Hi, I'd like to propose an extremely simple extension to ghc's record
>>disambiguation rules,
> I wonder if John is teasing us? Nothing wrt to records is simple (IMHO).
That is rather defeatist. Degree of simplicity is actually something that very
qu
Hi, I'd like to propose an extremely simple extension to ghc's record
disambiguation rules,
my motivation is that I often have record types with multiple constructors
but common fields.
so the handy idiom of
f Rec { .. } = do
blah
return Rec { .. }
won't work, because I don't kn
On Fri, Feb 17, 2012 at 2:12 PM, Simon Marlow wrote:
> On 17/02/12 19:36, John Meacham wrote:
>>
>> It isn't local to a file though because it changes the ABI, for instance
>>
>> void foo(off_t *x);
>>
>> it will blow up if called from a file wit
It isn't local to a file though because it changes the ABI, for instance
void foo(off_t *x);
it will blow up if called from a file with a differently sized off_t.
John
On Fri, Feb 17, 2012 at 4:23 AM, Simon Marlow wrote:
> On 16/02/2012 13:25, Eugene Crosser wrote:
>>
>> Hello Simon, thank
On Thu, Feb 16, 2012 at 4:42 PM, Johan Tibell wrote:
> 1. In theory the user could create a cut-n-paste copy of the data
> structure and specialize it to a particular type, but I think we all
> agree that would be unfortunate (not to say that it cannot be
> justified in extreme cases.)
I thought
FWIW
jhc has always unboxed everything smaller or equal to the size of a pointer
unconditionally. It's all about the cache performance.
John
On Thu, Feb 16, 2012 at 4:25 PM, Johan Tibell wrote:
> Hi all,
>
> I've been thinking about this some more and I think we should
> definitely unpack p
I have similar issues to this in jhc due to its pervasive caching of
compilation results. Basically I must keep track of any potentially
ABI-changing flags and ensure they are consistently passed to every
compilation unit and include them in the signature hash along with the
file contents. I make s
Proxy also has the advantage that it almost exactly mirrors what it
ends up looking
like in core. The application to proxy is the user visible type application.
John
On Tue, Feb 14, 2012 at 8:18 AM, Iavor Diatchki
wrote:
> Hello,
>
> On Mon, Feb 13, 2012 at 5:32 PM, Edward Kmett wrote:
>>
>
typo, I meant
"Proxy :: (exists k . k) -> *" is isomorphic to "Proxy :: forall k . k -> *"
John
On Sat, Feb 11, 2012 at 6:02 PM, John Meacham wrote:
> On Fri, Feb 10, 2012 at 2:24 PM, Ian Lynagh wrote:
>> But it would be better if they could use
On Fri, Feb 10, 2012 at 2:24 PM, Ian Lynagh wrote:
> But it would be better if they could use the new definition. Is
> PolyKinds sufficiently well-defined and simple that it is feasible for
> other Haskell implementations to implement it?
There is actually a much simpler extension I have in jhc c
at 23:30, John Meacham wrote:
>
>> something I have thought about is perhaps a special syntax for Proxy, like
>> {:: Int -> Int } is short for (Proxy :: Proxy (Int -> Int)). not sure whether
>> that is useful enough in practice though, but could be handy if we are
>&g
I hate using things like 'new', 'old', 'unsafe' in module names, the
words are too overloaded and mean different things in different
contexts. you end up with things like 'NewerTypeable'. So why not call
it what it is already known by, 'Data.PolyTypeable'.
John
On Sat, Feb 11, 2012 at 5:05 P
Would it be useful to make 'Proxy' an unboxed type itself? so
Proxy :: forall k . k -> #
This would statically ensure that no one accidentally passes ⊥ as a parameter
or will get anything other than the unit 'Proxy' when trying to evaluate it.
So the compiler can unconditionally elide the paramet
Being in C is very different than being 'portable'. The C code
generated by GHC never looked anything like what you would expect C
code to look like, it was basically a list of pre-proccessor macros
that expanded to STG-machine code sort of.
If you want to know what low-level operations ghc is doi
Hi, I am running into an issue where some code that compiled and
worked under 6.12 is failing under 7.0, the offending code is
class DeNameable a where
deName :: Module -> a -> a
getDeName :: Tc (DeNameable n => n -> n)
getDeName = do
mn <- asks (tcInfoModName . tcInfo)
return (\n ->
Yes, it appears to have been a corrupted 'hi' file. cleaning
everything out and starting
from scratch fixed it. I was seeing it on both compilers because my
two systems are
synchronized via unison so the bad file got bounced back and forth.
I have not tried using 7.2 yet, the separation of haskell
So... I knew that ghc was a memory hog.. but I am suddenly running
into it dying with messages like the following:
ghc: out of memory (requested 5997056753664 bytes)
make[1]: *** [jhc] Error 1
Before I go out and find a machine with 6 terrabytes of RAM, I figured
I'd post here first :)
now the s
Can you use a weak pointer to do what you want?
If you keep a weak pointer to the head of your expensive list then
itwill be reclaimed at the next major GC I believe. I have used
weakpointers for vaugely similar purposes before.
I guess a downside is that they will always be reclaimed on GC even
if
What are you trying to acomplish? A case doesn't necessarily force
evaluation in haskell depending on the binding pattern. for instance
case x of _ -> undefined will parse, but the function is still lazy in
x. it is exactly equivalant to
quodlibet x = undefined
If you want to actually enforce th
Isn't this what data families (as opposed to type families) do?
John
On Mon, Feb 14, 2011 at 1:28 PM, Conal Elliott wrote:
> Is there a way to declare a type family to be injective?
>
> I have
>
>> data Z
>> data S n
>
>> type family n :+: m
>> type instance Z :+: m = m
>> type instance S
Even though the hardware is x86_64, I thought the vast majority of
macs used a 32 bit build of OSX and 32 bit programs?
John
On Tue, Feb 1, 2011 at 3:38 AM, Max Cantor wrote:
> The last 32-bit, Intel Mac was the Mac Mini, discontinued in August 2007. The
> bulk of them were discontinued in
Any chance a cooling fan inside died and you are overheating it?
Can you reproduce the failure with other heavy load programs, can you
run a widget that monitors the internal temperatures and other sensors
during the build?
It does seem odd...
John
On Mon, Jan 31, 2011 at 12:46 AM, Johan Ti
On Wed, Jan 19, 2011 at 6:32 PM, Kazu Yamamoto wrote:
> Hello,
>
> I have been using GHC HEAD for some months and am suffering from the
> breaks of backward compatibility.
>
> 1) MANY packages cannot be complied with GHC HEAD because of lack of
> FlexibleInstances and BangPatterns.
>
> 2) The netw
FWIW, I am forgoing functional dependencies and going straight to type
families/associated types in jhc. They are easier to implement and
much cleaner IMHO.
John
On Mon, Dec 13, 2010 at 12:29 AM, Simon Peyton-Jones
wrote:
> Yes, I think type families are here to stay.
>
> There is no formal
gone)
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
of course, this bug[1] makes it sort of moot in ghc at least.
[1] http://hackage.haskell.org/trac/ghc/ticket/r2917
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-us
PerformIO $ do
alloca w $ \pw -> do
peek (castPtr pw)
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell
Jhc compiles to ANSI C and has been tested with other ARM targets and
works fine. It may be suitable for your needs.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell
fine here, with multiple
> editions of 6.10.x
Yes, you are right. ghc 6.10 appears to be doing the right thing. It was
6.8 that was odd, between the change in exceptions and my old workaround
for 6.8 I got somewhat mixed up.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanum
exit codes).
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ion but their type systems might not be up
> to the full generality of GADTs. (GHC's wasn't even quite up to it for
> quite a long time until around 6.8, when we finally got it right.)
Jhc also supports ExistentialQuantification but not full GADTs.
John
--
John Me
rators), but if ghc implements
something related, then it would be good to be compatible.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.hask
tion in the past actually in the odd place of developing linux/unix
software while sitting at a windows box, and cygwin builds of tools were
more useful in general.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
follow those steps, but then don't override the host in the
./configure step to just let it pick up the cygwin environment will it
work properly?
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haske
I went ahead and implemented --print-hsc-options to jhc, which will spit
out something like '-I/usr/share/jhc-0.5/include' suitable for passing
to the hsc2hs command line. It seemed like the most straightforward
route of the choices mentioned.
John
--
John Meacham - ⑆repeta
nvironment.
[1] http://www.sandroid.org/imcross/
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
gt;
> > touchTS :: TimeStamp -> IO ()
> > touchTS ts = touchForeignPtr (unsafeCoerce# ts)
>
> *blink* that can't possibly work!
It seems to, but that may just be pure accident. I couldn't seem to find
where the data constructor for constructing IO actions from wande
Well, the actual problem I am trying to solve involves properly
reclaiming elements in a circularly linked list (next and prev pointers
are TVars). I have a linked list and I need to be able to remove values
from the list when all references to the node no longer exist, not
counting the linked lis
ng properly.
thanks!
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
d would be generally useful to
standardize independently, the other depends on the specific build
system/configuration manager used.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.o
om up rather than the top down. And it wants to be the _one true_
build system in your project.
I'd like to see a standardized meta-info format for just haskell
libraries, based on the current cabal format without the cabal specific
build information. (this is what jhc uses, and franchise too I think)
Just like the 'lsm' linux software map files. Preferably YAML, we are
pretty darn close already and it will give us parsers in many languages
for free. We already have several tools that can use the meta-info, jhc,
cabal, franchise, hackage (for the web site layout) so it seems like
abstracting it from the build info would be a useful step in the right
direction.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Wed, Aug 27, 2008 at 10:18:59PM +0100, Duncan Coutts wrote:
> On Wed, 2008-08-27 at 06:13 -0700, John Meacham wrote:
> > The problem with the way cabal wants to mix with make/autoconf is that
> > it is the wrong way round. make is very good at managing pre-processors,
> >
id tools. But as long as they are
integrated I don't see cabal's design problems being fixed, meerly
augmented with various work-arounds.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
e job. I would
much rather see cabals functionality split among a variety of different
programs so the pieces can be used when appropriate, not as an all or
nothing thing. (bring back hmake! :) ).
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glas
_ export an instance, and it
wouldn't make explicit the fact that the instances of all modules it
depends on are also exported.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@
he case in C++) so
there is no need to worry about it for the haskell FFI spec.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ot that might already be attached to that function.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
was thinking that you just wouldn't include any extra c headers at all
then, just write out the appropriate c code to call with the conventions
specified in the ffi import specification and you won't need external
headers at all so there isn't anything to conflict with.
ll a jhc library all you need to do is grab a single 'hl' file and
drop it somewhere, but you can optionally re-optimize it specifically
for your platform, (presumably after pulling it down from the web or
hackage or somewhere..)
Joh
c
compiler?
Though, if there were a way to figure that stuff out without a c
compiler in a portable way, that would be cool.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://
les". But in this case no
> monomoprhic variables remain, because by then the type of compress has been
> refined to [Char] -> [Char]
Ah! it all makes sense now. excellent. It has been a persistent
annoyance that jhc gets dinged by the monomorphism restriction more than
ghc, but no
e report) would
cause 'compress' to be typed and generalized before 'main' was even
processed...
Hmm..
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ithout having to install
c2hs on their build machines. hsc2hs is the minimal tool needed to write
portable C interfaces so needs to be installed on target systems anyway.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users m
ily accepts it.
Jhc thinks it is illegal according to my reading of the specification.
Any ideas about what is going on here?
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
h
's job, though of course, specific Haskell
compilers are free to provide extensions. But I'd rather see GHC get
further away from C idiosyncrasies instead of closer.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users
tr :: Ptr CInt
#def inline int * get_COLOR_PAIRS (void) {return &COLOR_PAIRS;}
hsc2hs is needed anyway for portable C bindings so it isn't too onerous
of a requirement.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-u
ll. Everything needed is
inherently in the foreign declaration. If anything, the headers should
just be used as a sanity check, not actually to affect the generated
code. It would be nice if ghc just stopped relying on them and ignored
them altogether.
John
--
John Meacham - ⑆re
rescribe something arbitrary
language-wide for a particular issue with ghc.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
support will likely be added back at
some point)
I think this is a-okay as far as haskell 98 goes. Assuming latin1
without doing an 'openBinaryFile' is certainly not okay in my book.
John
--
John Meacham - ⑆repetae.net⑆john⑈
_
igantly more powerful. perhaps other compilers could do
likewise?
I invoke it with
changequote({{,}})
at the beginning which seems to work well for haskell.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glas
xed tuples can hold both
boxed and unboxed values, so some sort of kind polymorphism would be
needed to type the prefix form properly.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@hask
me wrong :-)
it might be worthwhile to do in a couple specific cases, like a cache of
small Ints or the ascii characters.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hen giving examples of unix command
lines to use a semicolon ';' as the prompt, as it has no effect in
bourne derived shells so you can always cut-n-paste the whole line into
your shell and be good to go.
John
--
John Meacham - ⑆repetae.net⑆john⑈
__
r 3) * (fromInteger 10) ^^ (2 :: Foo)
where Foo is whatever 4 defaults to, probably Integer, but could be a
compile error if defaulting is off or changed.
Though, the current floating point support in haskell is pretty funky as
is...
John
--
John Meacham - ⑆repetae.net⑆john⑈
On Sun, May 20, 2007 at 04:23:58PM +0200, Arie Peterson wrote:
> John Meacham wrote:
>
> | ghc 6.6 and 6.6.1 both go into infinite loops and eventually die with a
> | stackfault when trying to compile the attached file with optimizations
> | turned on.
> |
> | [...]
> |
&
ghc 6.6 and 6.6.1 both go into infinite loops and eventually die with a
stackfault when trying to compile the attached file with optimizations
turned on.
--
John Meacham - ⑆repetae.net⑆john⑈
module C.Op where
{-
Basic operations. These are chosen to be roughly equivalent to c-- operations,
but
(negate (fromInteger 1))
(which requires 2 dictionary lookups for a simple constant! sigh.
we also have the option of removing negate from the 'Num' class if so
desired.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
where. :)
another option would be to only count it as a negative if there is a
non-identifier character preceeding it. A little ugly. but still better
than the current situation IMHO.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-u
mas.
like I will often have a huge complicated module like
module Grin.EvalAnalysis(grinEvalAnalysis) where ...
and if I put a {-# NOINLINE grinEvalAnalysis #-} in there then changes
to the module don't cause other stuff to be recompiled.
John
--
John
the call is unsaturated
and it will end up being let-floated out anyway.
I originally added it so some early flow-insensitive optimizations
wouldn't end up doing silly things like unifying all uses of 'id'
program-wide. The compiler is smarter now, so it is less needed, but i
e.
yes please! odd that I look forward to such a minor change in the big
scheme of things, but the current treatment of negation has annoyed me
more than any other misfeature I think.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskel
s a type, of kind '*'.
since the method lookup is done explicitly via the case statement, it
can be optimized via standard transformations in nice ways.
John
>
> - Conal
>
> On 5/4/07, John Meacham <[EMAIL PROTECTED]> wrote:
> >
> >On Fr
1 - 100 of 292 matches
Mail list logo
