Re: [Haskell-cafe] Qualified import syntax badly designed (?)

[Henning Thielemann]

On Tue, 8 Jul 2008, [EMAIL PROTECTED] wrote:


How about using + and - prefixes instead of implicit and explicit clause?


Hiding of identifiers is the wrong way round. It fails if new identifiers 
are added to a module interface:

  http://www.haskell.org/haskellwiki/Import_modules_properly

For one-line imports, see:
  http://www.haskell.org/haskellwiki/Qualified_names
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Qualified import syntax badly designed (?)

[Henning Thielemann]

On Wed, 9 Jul 2008, Neil Mitchell wrote:


It seems that the qualified import syntax is a bit awkward. At the
moment, its common to see:

import qualified Data.Map as M
import Data.Map(Map)

i.e. import a module, give it an alias (M), and put some things in the
current namespace (Map).

Another way some people sometimes do it is:

import qualified Data.Map as M
import Data.Map hiding (lookup)

i.e. import a module, give it an alias (M), and exclude some things
from the current namespace.

Both of these require two imports, yet feel like they should require
only one. It seems as though the import syntax more naturally promotes
security (preventing access to some functions), rather than
namespacing.

I think a better design for namespacing might be:

import Data.Map as M implicit (Map)
import Data.Map as M explicit (lookup)


Why 'implicit' and 'explicit'? Do you mean something like 'include' and 
'exclude'?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Qualified import syntax badly designed (?)

[wren ng thornton]

Quoth [EMAIL PROTECTED]:

Quoth Neil Mitchell <[EMAIL PROTECTED]>:
> [...]
>
> Both of these require two imports, yet feel like they should require
> only one. It seems as though the import syntax more naturally promotes
> security (preventing access to some functions), rather than
> namespacing.
>
> I think a better design for namespacing might be:
>
> import Data.Map as M implicit (Map)
> import Data.Map as M explicit (lookup)
>
> If this was the design, I'm not sure either qualified or hiding would
> be necessary for namespacing. You'd get module names aligning up in
> the same column after the import rather than being broken up with
> qualified. You'd only need one import of a module for most purposes.
> The hiding keyword might still be nice for lambdabot style
> applications, but that is probably a secondary concern, and better
> handled in other ways.
>
> Thoughts? Is this design flawed in some way? Does the existing design
> have some compelling benefit I've overlooked?

How about using + and - prefixes instead of implicit and explicit clause?

\begin{code}
module T where

import Data.Map (Map, (\\))
import qualified Data.Map as M hiding (lookup)

f :: (Ord k) => Map k v -> k -> Map k v
f m k = m \\ M.singleton k (m M.! k)
\end{code}

the following import command would mean the same:
import qualified Data.Map as M (+Map,  -lookup, +singleton, +(\\))



What I would like to see is the ability to do (1) module renaming, (2) 
qualified import, (3) unqualified import, and (4) hiding all in a single 
declaration with a regular syntax. For example:


import Data.Map as Map
unqualified (Map, (\\))
qualified   (lookup, map, null)
hiding  (filter)

To simplify this full generality for the common cases:

* At most one of the lists can be dropped, keeping the keyword, to mean 
"everything else".


* Naturally if both the qualified and unqualified clauses have lists, 
then everything else is assumed to be hidden and so the 'hiding' keyword 
can be dropped too.


* Similarly, if any clause has an empty list, both the keyword and the 
() can be dropped.


* A special case can be made when all three clauses are dropped so that, 
if there's no 'as'-clause then everything is imported unqualified, 
otherwise everything is imported qualified.


* Another special case to better mimic the current syntax is that if 
neither 'qualified'- nor 'hiding'-clauses are present, then the 
'unqualified' keyword can be dropped (retaining the list of imports).




As Neil mentioned, the most common idioms are to combine 
unqualified/hiding or unqualified/qualified, but allowing all three 
makes the syntax more consistent. And there are times when we would want 
all three, such as when being very specific about expressing 
dependencies: unqualified types and operators (for sanity), qualified 
functions (for explicitness), hidden "dangerous"/known-unused functions 
(for safety).


With the abbreviations above, this syntax is almost a proper superset of 
the current syntax. The main incompatible difference is moving the 
'qualified' keyword to make the syntax more consistent.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] use of the GHC universal quantifier

[Galchin, Vasili]

Hello,

 It seems to me by its name that "forall" denotes a logical universal
quantifier. In any case, hsql-1.7/Database/HSQL/Types.hs uses "forall" at
line #134. I got a nasty build so I added {-# LANGUAGE
ExistentialQuantification #-} at the top of the module. Now I get the
following a coupleof lines up:

Database/HSQL/Types.hs:131:5:
Illegal polymorphic or qualified type: forall a.
   Int
   -> FieldDef
   -> FieldDef
   -> CString
   -> Int
   -> IO a
   -> IO a
In the definition of data constructor `Statement'
In the data type declaration for `Statement'

If seems that GHC doesn't like "a". Why?

Kind regards, Vasili
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] FPGA / Lava and haskell

[Alfonso Acosta]

We'll soon (before september, hopefully) relase a deep-embedded
version of ForSyDe[1] which, among other things, has a VHDL backend
(with specific support for Altera's Modelsim and Quartus).

ForSyDe's new implementation is internally based upon the same concept
as Lava (Observable Sharing). However, it has quite a few differences:

* ForSyDe is behavioural (computations are expressed in plain haskell)
* It has support for components
* Is not barely targeted at synchrounous hardware systems (although
the VHDL backend is obviously aimed at them). It has suport for other
MoCs (Models of Computation).

[1] http://www.imit.kth.se/info/FOFU/ForSyDe/


On Tue, Jul 8, 2008 at 7:43 PM, Marc Weber <[EMAIL PROTECTED]> wrote:
> Is Haskell still used (in industry as well ?) to write (V)HDL code to
> program FPGAs and create circuits on chips?
> The Chalmers Lava homepage tells abouta Xilinx version which should be
> merged in soon. But on the xilinx homepage there was no reference to
> neither Lava nor haskell..
> I'm thinking about designing a similar tool to www.combimouse.com.
>
> Sincerly
> Marc
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] FPGA / Lava and haskell

[Philip Weaver]

On Tue, Jul 8, 2008 at 5:43 PM, Marc Weber <[EMAIL PROTECTED]> wrote:

> Is Haskell still used (in industry as well ?) to write (V)HDL code to
> program FPGAs and create circuits on chips?


Indeed!  Galois maintains a language called Cryptol.  Almost all tools for
this language, including an FPGA compiler that produces HDL, are written in
Haskell.  It is not open source, nor is it free as in beer, but there is a
free academic version without FPGA support.

The Chalmers Lava homepage tells abouta Xilinx version which should be
> merged in soon. But on the xilinx homepage there was no reference to
> neither Lava nor haskell..


As for Lava and the Xilinx version, I am not really sure how actively it is
being developed.  Perhaps someone else here knows?


> I'm thinking about designing a similar tool to www.combimouse.com.


You're going to design something like that with an FPGA in it?  :)

For a simple enough design, it can be useful to write specs in Haskell and
then translate them to HDL by hand.  I believe someone on this list had a
particularly successful experience doing that :).

- Philip


> Sincerly
> Marc
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Qualified import syntax badly designed (?)

[skynare]

How about using + and - prefixes instead of implicit and explicit clause?

\begin{code}
module T where

import Data.Map (Map, (\\))
import qualified Data.Map as M hiding (lookup)

f :: (Ord k) => Map k v -> k -> Map k v
f m k = m \\ M.singleton k (m M.! k)
\end{code}

the following import command would mean the same:
import qualified Data.Map as M (+Map,  -lookup, +singleton, +(\\))




On 7/8/08, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It seems that the qualified import syntax is a bit awkward. At the
> moment, its common to see:
>
> import qualified Data.Map as M
> import Data.Map(Map)
>
> i.e. import a module, give it an alias (M), and put some things in the
> current namespace (Map).
>
> Another way some people sometimes do it is:
>
> import qualified Data.Map as M
> import Data.Map hiding (lookup)
>
> i.e. import a module, give it an alias (M), and exclude some things
> from the current namespace.
>
> Both of these require two imports, yet feel like they should require
> only one. It seems as though the import syntax more naturally promotes
> security (preventing access to some functions), rather than
> namespacing.
>
> I think a better design for namespacing might be:
>
> import Data.Map as M implicit (Map)
> import Data.Map as M explicit (lookup)
>
> If this was the design, I'm not sure either qualified or hiding would
> be necessary for namespacing. You'd get module names aligning up in
> the same column after the import rather than being broken up with
> qualified. You'd only need one import of a module for most purposes.
> The hiding keyword might still be nice for lambdabot style
> applications, but that is probably a secondary concern, and better
> handled in other ways.
>
> Thoughts? Is this design flawed in some way? Does the existing design
> have some compelling benefit I've overlooked?
>
> Thanks
>
> Neil
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] FPGA / Lava and haskell

[Marc Weber]

Is Haskell still used (in industry as well ?) to write (V)HDL code to
program FPGAs and create circuits on chips?
The Chalmers Lava homepage tells abouta Xilinx version which should be
merged in soon. But on the xilinx homepage there was no reference to
neither Lava nor haskell..
I'm thinking about designing a similar tool to www.combimouse.com.

Sincerly
Marc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Qualified import syntax badly designed (?)

[Neil Mitchell]

Hi,

It seems that the qualified import syntax is a bit awkward. At the
moment, its common to see:

import qualified Data.Map as M
import Data.Map(Map)

i.e. import a module, give it an alias (M), and put some things in the
current namespace (Map).

Another way some people sometimes do it is:

import qualified Data.Map as M
import Data.Map hiding (lookup)

i.e. import a module, give it an alias (M), and exclude some things
from the current namespace.

Both of these require two imports, yet feel like they should require
only one. It seems as though the import syntax more naturally promotes
security (preventing access to some functions), rather than
namespacing.

I think a better design for namespacing might be:

import Data.Map as M implicit (Map)
import Data.Map as M explicit (lookup)

If this was the design, I'm not sure either qualified or hiding would
be necessary for namespacing. You'd get module names aligning up in
the same column after the import rather than being broken up with
qualified. You'd only need one import of a module for most purposes.
The hiding keyword might still be nice for lambdabot style
applications, but that is probably a secondary concern, and better
handled in other ways.

Thoughts? Is this design flawed in some way? Does the existing design
have some compelling benefit I've overlooked?

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Interesting feature

[David Overton]

On 08/07/2008, Benjamin L. Russell <[EMAIL PROTECTED]> wrote:
>  Do you know of any logic programming languages with strong typing and
>  modules that have GUI-based REPL's, similar to WinHugs, available?

You might want to look at Visual Prolog (http://www.visual-prolog.com/).  It
is strongly typed and has a Windows IDE.  I'm not sure if it has a REPL though.

David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What is a rigid type variable?

[Henning Thielemann]

On Tue, 8 Jul 2008, Ben Franksen wrote:


Wow. Such a short and clear explanation. I have been wondering for some time
what exactly this 'rigid' means... Please somebody who understands stuff
like that better than me put it on some wiki page. It's obviously a FAQ.

BTW, do we have a FAQ page? I think we should have one.


http://www.haskell.org/haskellwiki/Category:FAQ
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: What is a rigid type variable?

[Ben Franksen]

Ryan Ingram wrote:
> To answer the question in the subject:
> 
>>From "Simple unification-based type inference for GADTs",
> Peyton-Jones, et al.  ICFP 2006.
> http://research.microsoft.com/users/simonpj/papers/gadt/
> 
> "Instead of "user-specified type", we use the briefer term rigid
> type to describe a type that is completely specified, in some
> direct fashion, by a programmer-supplied type annotation."
> 
> So a rigid type is any type specified by a programmer type signature.
> All other types are "wobbly".

Wow. Such a short and clear explanation. I have been wondering for some time
what exactly this 'rigid' means... Please somebody who understands stuff
like that better than me put it on some wiki page. It's obviously a FAQ.

BTW, do we have a FAQ page? I think we should have one.

Cheers
Ben
(a little behind on cafe, catching up...)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] more database issues

[Galchin, Vasili]

Thanks to everybody who responded!

Vasili

On Tue, Jul 8, 2008 at 7:40 AM, Denis Bueno <[EMAIL PROTECTED]> wrote:

> 2008/7/8 Galchin, Vasili <[EMAIL PROTECTED]>:
> > Database/HSQL.hsc:66:7:
> > Could not find module `System.Time':
> >   it is a member of package old-time-1.0.0.0, which is hidden
> > [EMAIL PROTECTED]:~/Desktop/hsql-1.7$
> >
> > I have a global ghc installation plus a local one off my user directory.
> In
> > any case, when I do "ghc-pkg list"  old-time-1.0.0.0 is not hidden.
> > 
>
> I believe "hidden" here means that the .cabal file isn't specifically
> told it's okay to use "old-time", thus it's "hidden" to cabal, not to
> GHC.
>
> If you add "old-time" to the Build-depends field of the package, you
> should be able to get rid of this message.
>
> --
>  Denis
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] data Color3 a = Color3 !a !a !a

[Albert Y. C. Lai]

Daryoush Mehrtash wrote:

Can some one explain what the !a does in this:

data Color3 a = Color3 !a !a !a


Shameless plug: http://www.vex.net/~trebla/haskell/strict-field.xhtml
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] data Color3 a = Color3 !a !a !a

[Ryan Ingram]

A simple example to help understand the difference

> data NoStrict a = NoStrict a deriving Show
> data Strict a = Strict !a deriving Show

> ns1 = NoStrict ()
> ns2 = NoStrict undefined
> ns3 = undefined

> nf1 (NoStrict ()) = "ok"
> nf2 (NoStrict _) = "ok"

> s1 = Strict ()
> s2 = Strict undefined
> s3 = undefined

> f1 (Strict ()) = "ok"
> f2 (Strict _) = "ok"

The difference between these:

*Strict> nf2 ns2
"ok"
*Strict> f2 s2
"*** Exception: Prelude.undefined

s2 and s3 are both the same (undefined), while ns2 and ns3 are different.

As to why you'd want that behavior?  Here are a couple of reasons:
1) You can avoid hiding exceptions in strict data structures; if the
top level evaluates, you know the entire structure is valid.
2) With -funbox-strict-fields, the compiler can remove a level of
indirection; the performance difference between a structure that
contains three machine words and a structure that contains three
pointers to boxed integers is pretty significant.

On the other hand, you lose the benefits of laziness; I find most
"structure-like" data structures work better strict, but that
"list-like" data structures definitely gain an advantage from
laziness.

  -- ryan


2008/7/8 Daryoush Mehrtash <[EMAIL PROTECTED]>:
> Can some one explain what the !a does in this:
>
> data Color3 a = Color3 !a !a !a
>
> http://cvs.haskell.org/Hugs/pages/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-VertexSpec.html#t%3AColor3
>
> Thanks,
>
> Daryoush
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Swapping Monads

[Derek Elkins]

On Tue, 2008-07-08 at 06:39 +0100, Dominic Steinitz wrote:
> I have a solution so this is for interest only.
> 
> It is not normally the case that two monads compose to give another
> monad. Monad transformers capture when this is possible. However, when
> there is a "swap" function satisfying some commutative diagrams then it
> can be proved that the monads compose  to produce a monad.
> 
> Is there such a swap function in a library? I had a look in the
> comprehensive category-extra package but couldn't find anything.

You didn't look hard enough.  What you want is called a distributive law
in category theory.  A class for exactly what you want is in
Control.Functor.Extras.

http://hackage.haskell.org/packages/archive/category-extras/0.53.5/doc/html/Control-Functor-Extras.html#t%3ADistributes

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] more database issues

[Denis Bueno]

2008/7/8 Galchin, Vasili <[EMAIL PROTECTED]>:
> Database/HSQL.hsc:66:7:
> Could not find module `System.Time':
>   it is a member of package old-time-1.0.0.0, which is hidden
> [EMAIL PROTECTED]:~/Desktop/hsql-1.7$
>
> I have a global ghc installation plus a local one off my user directory. In
> any case, when I do "ghc-pkg list"  old-time-1.0.0.0 is not hidden.
> 

I believe "hidden" here means that the .cabal file isn't specifically
told it's okay to use "old-time", thus it's "hidden" to cabal, not to
GHC.

If you add "old-time" to the Build-depends field of the package, you
should be able to get rid of this message.

-- 
 Denis
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Associative Commutative Unification

[Edsko de Vries]

On Tue, Jul 08, 2008 at 08:24:45AM -0400, John D. Ramsdell wrote:
> The Haskell typechecker contains a nice example of a unifier for
> freely generated terms.  My focus is on equational unification, but
> thanks anyway.

Are you aware of "Term Rewriting and all That"? It describes how to do
associative commutative unification; whether it satisfies your
'obviously correct' criterion I don't know. 

Edsko
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] extensible data types in Haskell?

[David Walker]

thanks for everyone's help -- it seems the simplest solution is to use
the Typeable class, existential types and type-safe cast.

Cheers,
Dave

On Sun, Jul 6, 2008 at 9:18 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> princedpw:
>> Hi all,
>>
>> SML conveniently contains the type "exn" which is an instance of an
>> "extensible data type".  In other words, unlike normal data types that
>> are "closed" (can't admit new constructors once defined), SML's exn
>> type is "open," allowing programmers to keep adding new alternatives
>> as often as they choose.  Like normal datatypes, the elimination form
>> for an extensible data type is a case statement (or match function).
>>
>> Friends have told me that Haskell doesn't have extensible data types.
>> However, it seems fairly straightforward to code them up using type
>> classesthough the solution I'm thinking of has a little bit of
>> boilerplate I'd like to scrap (you have to define a new type
>> declaration *and* an instance of a type class with a "match" method)
>> and matching occurs through a string comparison (which can lead to
>> silly programmer errors if there is accidentally a typo in the
>> string).
>
> You should probably use Typeable here, for the type matching, rather
> than a custom matcher. class Typeable a => Extensible a, this leads to a
> fairly straighforward extensible data type, where the open instance
> definition lets you add variants on the fly.
>
>> Anyway, it's possible with some thought I could come up with a better
>> solution, but before worrying about it, I figured I'd ask if anybody
>> else already has a package that does this.  It seems like a pretty
>> natural feature to want to have.
>
> There's a number of ways to do this, including fully statically via type
> classes and existential types, or via the Dynamic type.
>
> Googling for "expression problem Haskell" will turn up some things. Some
> implementions of open data types in use can be found in xmonad, and the
> extensible exceptions proposal here,
>
>
> http://209.85.173.104/search?q=cache:xeXhle5KAqkJ:www.haskell.org/~simonmar/papers/ext-exceptions.pdf
>
> -- Don
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Associative Commutative Unification

[John D. Ramsdell]

The Haskell typechecker contains a nice example of a unifier for
freely generated terms.  My focus is on equational unification, but
thanks anyway.

John

On Sun, Jul 6, 2008 at 10:38 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> ramsdell0:
>> I'd like to write an obviously correct implementation of a unifier, a
>> program that when given two terms, finds a substitution that makes the
>> two terms equal.  The phrase "obviously correct" is meant to imply
>> that the clarity of the code trumps efficiency.  As near as I can
>> tell, high performance unifiers are full of side-effects, and
>> achieving the same performance without side-effects in Haskell is
>> difficult or impossible.
>>
>> In contrast, it is easy to write obviously correct Hasklell
>> implementations of unifiers for freely generated term algebras.  One
>> can use Lawrence Paulson's code in ML for the Working Programmer as a
>> template or follow Martelli and Montanari's simple set of rules.
>>
>> My problem is one of my operators is multiplication, which is
>> associative and commutative.  These two properties make unification
>> much more difficult.  Mark Stickel described a complete unification
>> algorithm for this problem, but the task of translating his
>> description into an obviously correct Haskell program appears to be
>> difficult.  For example, the algorithm requires the generation of the
>> basis of solutions to linear homogeneous diophantine equations.  I
>> haven't located an algorithm for this part yet.
>>
>> If you have experience implemented equational unification in Haskell,
>> please share it.
>
> "Typing Haskell in Haskell" lives here,
>
>http://hackage.haskell.org/cgi-bin/hackage-scripts/package/thih
>
> "a Haskell program that implements a Haskell typechecker, thus providing
> a mathematically rigorous specification in a notation that is familiar
> to Haskell users. We expect this program to fill a serious gap in
> current descriptions of Haskell, both as a starting point for
> discussions about existing features of the type system, and as a
> platform from which to explore new proposals"
>
> Might be useful as a starting point.
>
> -- Don
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] data Color3 a = Color3 !a !a !a

[Janis Voigtlaender]

Daryoush Mehrtash wrote:

Can some one explain what the !a does in this:

data Color3 
 
a = Color3 
 
!a !a !a


http://cvs.haskell.org/Hugs/pages/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-VertexSpec.html#t%3AColor3


In short,

http://haskell.org/onlinereport/decls.html#strictness-flags

--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] data Color3 a = Color3 !a !a !a

[Daryoush Mehrtash]

Can some one explain what the !a does in this:

data 
Color3a
=
Color3!a
!a !a

http://cvs.haskell.org/Hugs/pages/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-VertexSpec.html#t%3AColor3

Thanks,

Daryoush
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Interesting feature

[Benjamin L . Russell]

On Tue, 8 Jul 2008 16:59:00 +1000, "David Overton"
<[EMAIL PROTECTED]> wrote:

>Also, see my recent attempts at (constraint) logic programming in Haskell:
>http://overtond.blogspot.com/2008/07/pre.html
>http://overtond.blogspot.com/2008/07/haskell-sudoku-solver-using-finite.html

Whoops!  Sorry, I rushed to reply with my earlier message, and forgot
to respond to this part of your post.

Your blog posts about a Haskell Sudoku solver remind me of similar
blog posts about Sudoku solvers in Python (see "Solving Every Sudoku
Puzzle": http://norvig.com/sudoku.html) and Scheme (see "Schemely:
Sudoku Solver1":
http://www.bobmc.net/cgi-bin/Schemely.pl/Sudoku_Solver1, and "Schemely
Blog: Scheme Sudoku Solver":
http://schemely.blogspot.com/2006/02/scheme-sudoku-solver.html).  Some
programmers learn new languages by translating code for Sudoku solvers
from one language that they already know well to another language that
they are trying to learn.

Because solving a Sudoku puzzle can be accomplished more easily by
using constraint propagation, in which placing a constraint on one
square can cause further constraints to be placed on other squares,
this definition lends itself to constraint programming.  Since
constraint programming is a form of declarative programming, this form
of programming lends itself to constraint logic programming.  As an
example, GNU Prolog has a constraint logic programming interpreter;
however, GNU Prolog lacks strong typing.

If you are interested in constraint programming, you may wish to
investigate the multi-paradigm programming language Oz (see
http://www.mozart-oz.org/), which can implement constraints in a
functional programming language.  The language lacks multiprocessor
support, but supports declarative programming, object-oriented
programming, constraint programming, and concurrency as part of a
coherent whole.

-- Benjamin L. Russell

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Interesting feature

[Benjamin L . Russell]

On Tue, 8 Jul 2008 16:59:00 +1000, "David Overton"
<[EMAIL PROTECTED]> wrote:

>On 08/07/2008, Benjamin L. Russell <[EMAIL PROTECTED]> wrote:
>>  If you are interested in logic programming in a language with some
>>  similarity to Haskell, you might also wish to investigate the strongly
>>  typed logic programming language Godel (see
>>  http://www.cs.bris.ac.uk/~bowers/goedel.html).  When I first saw an
>>  example of the code, I was surprised that, unlike Prolog, the language
>>  was strongly typed, and supported modules, and (albeit very loosely)
>>  resembled Haskell, except that it was a logic programming language.
>
>While we're plugging logic programming languages, you might also be interested
>in Mercury (http://www.cs.mu.oz.au/research/mercury/).  This is a
>logic/functional language with Prolog-like syntax, but with a Haskell-like
>type system, including Hindley-Milner types and type classes.
>IMHO Mercury is even closer to Haskell than Goedel.

Yes, Mercury appears interesting, but I was also wondering whether
there were any logic programming languages with strong typing and
modules that have GUI-based REPL's, similar to WinHugs, available. For
example, both SWI-Prolog and GNU Prolog have GUI-based REPL's of that
type, but Mercury, at least from what I read in the on-line
documentation, does not appear to have one.  Go"del has SAGE (Self
Applicable Go"del Evaluator) (download goedel-sage.tar.Z (200KB) at
ftp://ftp.cs.bris.ac.uk/pub/goedel/latest/goedel-sage.tar.Z), but
Go"del is not available for Windows, and according to the home page,
there are no plans for this to change in the future.

The advantage of a GUI-based REPL is that it facilitates learning the
language for beginners and non-*NIX/Linux users, and, in some cases,
using the language in a non-*NIX/Linux environment.  For example,
although I can use Mac OS X at home, my work computer, on which I
study programming during lunch and after work, uses Windows XP
Professional.  It is clumsy switching to Cygwin and Emacs in a Windows
environment, because I cannot use UNIX-style tools in the same way
outside of Cygwin in Windows as in UNIX.  In addition, many
directories have spaces in their paths, and many UNIX tools do not
support spaces in paths to files.  In this environment, a GUI-based
REPL would be convenient.

Do you know of any logic programming languages with strong typing and
modules that have GUI-based REPL's, similar to WinHugs, available?

-- Benjamin L. Russell

>Also, see my recent attempts at (constraint) logic programming in Haskell:
>http://overtond.blogspot.com/2008/07/pre.html
>http://overtond.blogspot.com/2008/07/haskell-sudoku-solver-using-finite.html
>
>David

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] more database issues

[Henning Thielemann]

On Tue, 8 Jul 2008, Galchin, Vasili wrote:


[EMAIL PROTECTED]:~/Desktop/hsql-1.7$ runhaskell Setup.lhs clean
cleaning...
[EMAIL PROTECTED]:~/Desktop/hsql-1.7$ runhaskell Setup.lhs configure --user
--prefix=$HOME
Configuring hsql-1.7...
Warning: No license-file field.
[EMAIL PROTECTED]:~/Desktop/hsql-1.7$ runhaskell Setup.lhs build
Preprocessing library hsql-1.7...
Building hsql-1.7...

Database/HSQL.hsc:66:7:
   Could not find module `System.Time':
 it is a member of package old-time-1.0.0.0, which is hidden
[EMAIL PROTECTED]:~/Desktop/hsql-1.7$

I have a global ghc installation plus a local one off my user directory. In
any case, when I do "ghc-pkg list"  old-time-1.0.0.0 is not hidden.

Bottom line is how do I install DB libraries with least pain??


Is old-time listed in the dependencies of the HSQL package?

Problem is probably that many functions moved from 'base' to smaller 
packages like 'old-time' but package maintainers did not move to new 
compilers and thus new package structure. It's very inconvenient, but a 
known issue.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] extensible data types in Haskell?

[Pablo Nogueira]

I prefer Bruno's approach, though. It allows meta-level type-checking
of expressions and there's the possibility of closing the extension
with a wrapper:
(References: "Generics as a Library" and his PhD thesis)

- GADT as a type class (or encode the type as it's fold):

 class Exp e where
 lit  :: TyRange a => a -> e a
 plus :: e Int -> e Int -> e Int
 and  :: e Bool -> e Bool -> e Bool

- Notice we cannot construct an ill-typed expression, the Haskell
type-checker complains.

- |TyRange| is the class of indices:

class TyRange a
instance TyRange Int
instance TyRange Bool

- The behaviour is given by instances:

newtype Eval a = Eval {eval :: a}

instance Exp Eval where
 lit   = Eval
 plus x y  = Eval (eval x + eval y)
 and  x y  = Eval (eval x && eval y)

Extension is easy:

class Exp e => ExpIf e where
   ifOp :: TyRange a => e Bool -> e a -> e a -> e a

instance ExpIf Eval where
   ifOp c t e = Eval (if (eval c) then (eval t) else (eval e))

class Exp e => ExpMult e where
mult :: e Int -> e Int -> e Int

instance ExpMult Eval where
mult x y = Eval (eval x * eval y)

- Adding new meta-level types is easy:

instance TyRange a => TyRange [a]
instance TyRange Char

class Exp e => ExpConcat e where
conc :: e [Char] -> e [Char] -> e [Char]

instance ExpConcat Eval where
conc x y = Eval (eval x ++ eval y)

- Closing expressions is also easy:  wrap around a type and provide
new functions:

data TyRange a => Wrap a = Wrap (forall e. (Exp e, ExpIf e, ExpMult e,
ExpConcat e) => e a)

> evalExp :: TyRange a => Wrap a -> a
> evalExp (Wrap x) = eval x

- Some expresions:

Compare:

exp1 :: Exp e => e Int
exp1 = plus (lit 3) (lit 3)
val1 = eval exp1

With:

exp1' :: Eval Int
exp1' = plus (lit 3) (lit 3)
va1'  = eval exp1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A type signature inferred by GHCi that is rejected when written explicitly

[Pablo Nogueira]

> I myselft  don't understand why GHCi doesn't accept the type it
>  infered as an explicit signature ...

I think it has to do with the following:

Looking at the type errors, they seem to indicate that the type
checker is being general and does not assume the |From| and |To|
"relations" are between
a type |t| and (s (t x) x)| but, in general, between |t| and |s (t' x) x|.

Given that

from   :: (From a1 c1 x) => a1 x -> c1 x
 to :: (To   a2 c2 y) => c2 y -> a2 y
bimap  :: Bifunctor s => (t1 -> t3) -> (t2 -> t4) -> s t1 t2 -> s t3 t4

During type checking the following equations spring up:

c2 y   = s t3 t4
c1 x   =  s t1 t2
t2   = x
t4   = y
t1   = a1 x
t3   = a2 y

That'd give the same type as that inferred, but somehow new variables
|a11| and |a12| appear.

>  caused by a lack of functional dependencies.
>  class From a c x | a -> c where
> class To a c y | c -> a where
> ... hushes GHCi. The question now is, of course, if the new
>  dependencies are too restrictive for your problem.

They are of little avail given the instances I define:

 instance Bifunctor s => From (Fix s) (s (Fix s x)) x where
 from = out

 instance Bifunctor s => To (Fix s) (s (Fix s y)) y where
 to   = In
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hoogle often updates ?

[Neil Mitchell]

Hi,

>  I have just been asked for usage of timer in haskell. Which I did not
>  remember clearly. So I ask the search engine.
>
>  In Hoogle: timer
>  In Google: haskell timer

Hoogle does not search the general web, just the libraries supplied
with GHC. A quick scan of the first few Google results shows nothing
particularly obvious - what were you hoping Hoogle found?

>  After I tried these, I wonder, when and how often the hoogle update its
>  database?

Now and then. I think it should be up to date with respect to GHC
6.8.2 at the moment.

> And, could hoogle search range cover the hackages?

Yes, I'm currently working on this as a Summer of Code project.
http://neilmitchell.blogspot.com/2008/04/summer-of-code-2008.html

Hopefully, by the end of the Summer, Hoogle will search all of hackage.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe