[Haskell-cafe] Compulsory relation 1 to many from entity A to entity A
Hallo! I'd like to build a database model with winHugs that allows a recursive relation. For example a single instance of entity components is related with at least another row of the entity components (1 to many relationship). How can I do that? Thank you for your attention! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Create a list without duplicates from a list with duplicates
For Bimap is there anything like Data.Map.insertWithKey ? Stuart Cook wrote: On Sat, Feb 9, 2008 at 7:36 AM, Dan Weston [EMAIL PROTECTED] wrote: If order is important, the new bijective Data.Bimap class http://code.haskell.org/~scook0/haddock/bimap/Data-Bimap.html may be your best bet (I haven't yet tried it myself). Let me try: nub :: (Ord a) = [a] - [a] nub = map snd . Data.Bimap.toAscList . Data.Bimap.fromList . reverse . zip [1..] nub hello, world! helo, wrd! Without the call to (reverse), this would still be an order-preserving nub, except that it would preserve the relative order of the *last* occurrence of each element. Actually, this makes me wonder whether fromList's behaviour should be changed, and whether I should add a non-clobbering variant of insert. Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Create a list without duplicates from a list with duplicates
On Sun, Feb 10, 2008 at 12:19 AM, ChrisK [EMAIL PROTECTED] wrote: For Bimap is there anything like Data.Map.insertWithKey ? No. I wanted to implement the insertWith family, but it wasn't clear to me what should happen if the value produced by the user's function already exists, bound to something else. One possibility might be to do nothing (or error) if that happens, making it the user's responsibility to not do such things. Whatever the case may be, it should be possible for client code to define such an operation, with no more than a constant-factor overhead. Perhaps I should wait and see if people find themselves doing this before guessing at an implementation. (Incidentally, almost everything in Map that's missing from Bimap is missing either because it doesn't make sense, or because of corner cases like this one.) Stuart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
Matthew Naylor wrote: [snip] Finally, when I say observable sharing, I don't necessarily mean it as defined by Koen Claessen and David Sands. I simply mean the use of unsafePerformIO to detect sharing, whether or not this is done by an eq predicate on Refs. (I say this because I think there are simpler ways to detect sharing, though these will probably not have the nice semantic properties of observable sharing.) ghc actually provides a primop for this: reallyUnsafePtrEquality# :: a - a - Int# Use at your own risk. Note that you can only check for equality uing that primop. To detect cycles in data structures efficiently, a total order would be better, but in the presence of copying garbage collection that's asking too much. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
On Feb 9, 2008 12:34 PM, Bertram Felgenhauer [EMAIL PROTECTED] wrote: ghc actually provides a primop for this: reallyUnsafePtrEquality# :: a - a - Int# Use at your own risk. Why is it more than unsafe? 'unsafePerformIO' seems to me a lot unsafer than 'reallyUnsafePtrEquality#'. Also, is anybody using 'reallyUnsafePtrEquality#' on a working project? Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
Matthew Naylor wrote: (snip) Now, there remains the concern that Haskell's semantics does not enforce sharing. A Haskell compiler is free to change the sharing a program at a whim, unknowingly to the programmer who may be relying on it in for an efficient program. However, to my knowledge, it is an unwritten rule of Haskell compilers that sharing *is* preserved, and that they do perform *graph* reduction. That is not true anymore for the threaded runtime of ghc. If two threads demand the same thunk, one of them will usually block, but there is a small window where both threads can start evaluting the expression. To prevent this, you'd have to take a lock or otherwise synchronize the threads upon entering each thunk, which is prohibitively expensive. See Haskell on a Shared-Memory Multiprocessor, http://www.haskell.org/~simonmar/papers/multiproc.pdf for details, section 3.1 in particular. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec3 pre-release [attempt 2]
On Thu, 7 Feb 2008, Albert Y. C. Lai wrote: Is it good or bad to add: instance (MonadIO m) = MonadIO (ParsecT s u m) I don't see any reason not to add it - it's not as if we can prevent people lifting to IO! Good catch. -- [EMAIL PROTECTED] A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
Am Freitag, 8. Februar 2008 17:14 schrieb Stefan Monnier: You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the latter representation should probably be prefered. With it, :+ always has a number as its left argument and a digit as its right. Without the () :+ we get ugly exceptional cases. You can see this, for example, in the instance declarations for Compare. With the second representation, we could reduce the number of instances dramatically. We would define a comparison of digits (verbose) and than a comparison of numbers based on the digit comparison (not verbose). Even if () would be preferred from the programmers point of view (I'm not sure how much we could reduce the number of instances though), it makes the representation less attractive on the user-side. Anyone using the library would find it annoying and would wonder why is it neccessary. I wouldn’t wonder. Leaving out the () :* part just works because our type-level “values” are not typed, i.e., there aren’t different kinds Digit and Number but only kind *. If :+ would be a data constructor (on the value level), it would take a number and a digit argument which would forbid using a digit as its left argument. So I consider using a digit on the left as “unclean”. It’s similar to using a number as the second part of a cons cell in LISP. How 'bout treating :+ as similar to `append' rather than similar to `cons'? Basically treat :+ as taking 2 numbers (rather than a number and a digit). So what would (D1 :* D1) :* (D2 :* D2) mean then? Stefan Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Internships at GHC HQ
On Jan 25, 2008 11:40 AM, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Would you be interested in working at Microsoft Research for three months? If so, you might want to think about applying for an internship. Simon and I are looking for interns, starting in summer 2008. Lots of background info here: http://hackage.haskell.org/trac/ghc/wiki/Internships including a bunch of possible projects, although you may also have ideas of your own. Hello Simon, I wonder if there is any interest by the part of Microsoft and the Haskell community in a software model checker using SAT-based techniques for Haskell. There's have been in the last few year a couple of approaches on this for C by several people, including some Microsoft people. Cheers, Paulo Matos But the bottom line is - apply by end Feb 2008 for this round - tell one of us that you have done so (None of this is restricted to Haskell stuff. You can apply to work at any Microsoft Research lab, on any topic. But there are a lot of applicants, so you are more likely to be successful if you are fairly specific about who at MSR you'd like to work with and why, and contact that person to say that you've applied.) Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool?
Dave Bayer wrote:
What is the best way to embed an arbitrary file in a Haskell program?
I don't know the best way. I'd probably use FFI.
main.hs:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.ForeignPtr
import qualified Data.ByteString as B
import qualified Data.ByteString.Internal as BI
foreign import ccall hello hello :: Ptr Word8
foreign import ccall hello_size helloSize :: Ptr Int
main = do
helloSize' - peek helloSize
hello' - newForeignPtr_ hello
let helloBS = BI.PS hello' 0 helloSize'
B.putStr helloBS
hello.c:
char hello[] = Hello, world!\n;
int hello_size = sizeof(hello);
Test:
# ghc -O -o main main.hs hello.c -package bytestring
# ./main
Hello, world!
The idea is then to use some existing tool that embeds binary
data in C programs.
Bertram
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Inverting a Monad
On Feb 7, 2008 4:58 AM, David Menendez [EMAIL PROTECTED] wrote: If you're doing any kind of backtracking or non-determinism, you might consider the msplit operation defined in Backtracking, Interleaving, and Terminating Monad Transformers http://okmij.org/ftp/Computation/monads.html#LogicT. Thanks for pointing me to this very interesting paper! Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool?
On Feb 9, 2008, at 8:03 AM, Bertram Felgenhauer wrote: Dave Bayer wrote: What is the best way to embed an arbitrary file in a Haskell program? I don't know the best way. I'd probably use FFI. snip The idea is then to use some existing tool that embeds binary data in C programs. Since you're specifically interested in OS X, I'd follow this advice, and then look at /usr/include/mach-o/getsect.h. This header declares a function extern char *getsectdata( const char *segname, const char *sectname, unsigned long *size); which seems like it'll give you all of the data in one of the sections of the executable file for the currently running program. I haven't used it, though, so I'm not positive about how it works. I think it's then fairly straightforward to tell the linker to just include an arbitrary file into a section with a name of your choice. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Newbie question: mutually exclusive strict / lazy
Consider the function cond x y z = if x then y else z I guess we can certainly say cond is strict in x. But what about y and z? If x is true, then cond is strict in y If x is false, then cond is strict in z So we can't really say cond is lazy nor strict in its second or third argument. Of course, this is the case for many more functions, but in the case of the if-then-else primitive, does the strictness analyzer make use of this mutually exclusive strictness fact? Cheers, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie question: mutually exclusive strict / lazy
Am Samstag, 9. Februar 2008 17:33 schrieb Peter Verswyvelen: Consider the function cond x y z = if x then y else z I guess we can certainly say cond is strict in x. But what about y and z? If x is true, then cond is strict in y If x is false, then cond is strict in z So we can't really say cond is lazy nor strict in its second or third argument. Of course, this is the case for many more functions, but in the case of the if-then-else primitive, does the strictness analyzer make use of this mutually exclusive strictness fact? Cheers, Peter Hope I remember correctly... A function is strict in an argument, if whenever that argument is _|_, the result is _|_, regardless of possible other arguments. Since if True then 0 else _|_ == 0, if-then-else is nonstrict in the third argument, similarly if False then _|_ else 0 == 0, so if-then-else is nonstrict in the second argument. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
Hi Tom, In addition to the sharing problem, another shortcoming of Haskell DSLs is they can not fully exploit the benefits of algebraic datatypes. Specifically, pattern matching ADTs can only be used to control the compile-time configuration of the target, it can't be used to describe the target's behavior -- at least for DSLs that generate code that executes outside of Haskell's runtime. you can embed algebraic data types and pattern matching in Haskell with your own semantics, and retain type inference. It goes something like this: (nil, (|)) = datatype (cons0 [] \/ cons2 (:)) map f xs = match xs rules where rules (x, xs) = [ nil -- nil , x | xs -- f x | map f xs ] here, map :: (Term a - Term b) - Term [a] - Term [b]. The main issue is that you have to quantify the free variables in patterns, hence the rules function. I don't know if this helps you. Writing a real compiler would solve both of these problems. Is there any Haskell implementation that has a clean cut-point, from which I can start from a fully type-checked, type-annotated intermediate representation? The Yhc.Core library is very simple to use and fairly mature (Neil's been tweeking it for about 3 years now), but it doesn't meet your type-annotated requirement. (Untyped core is still pretty useful, though.) If you go the real compiler route, would it not make sense to take the DSL as the source language rather than Haskell? Or are the DSL and Haskell quite similar? Or perhaps you are thinking of a two language system, where some code is evaluated at compile time by Haskell, and some is compiled to the target language? If so, maybe you just want domain specific syntax inside a Haskell program, in which case the paper Why it's nice to be quoted: quasiquoting for haskell might be relevant (it's actually supported in GHC I think). Anyway, all very thought provoking! Matt. P.S. Tom Hawkins wrote: Emil Axelsson wrote: I know of a few of ways to express sharing in a pure language: 1) Observable sharing, which, in general, is unsafe. 2) Using Template Haskell 3) Matthew Naylor has done some work on expressible sharing, which has 4) Use a monad (but I'm sure this is what you're trying to avoid). Or... 5) Forget embedding the DSL, and write a direct compiler. Taking options 2 or 5 just to solve the sharing problem sounds to me like a lot of hard work for little reward. But don't worry, I won't repeat my observable sharing speech. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
On Fri, 8 Feb 2008, Tom Hawkins wrote: 5) Forget embedding the DSL, and write a direct compiler. In addition to the sharing problem, another shortcoming of Haskell DSLs is they can not fully exploit the benefits of algebraic datatypes. Specifically, pattern matching ADTs can only be used to control the compile-time configuration of the target, it can't be used to describe the target's behavior -- at least for DSLs that generate code that executes outside of Haskell's runtime. Also in a pure Haskell library you will try to avoid direct access to constructors, because the internal data structures might change. Better are functions that access the internal data of a type, like 'maybe' and 'either' for 'Maybe' and 'Either', respectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Fri, 8 Feb 2008, Wolfgang Jeltsch wrote: Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie: Even if () would be preferred from the programmers point of view (I'm not sure how much we could reduce the number of instances though), it makes the representation less attractive on the user-side. Anyone using the library would find it annoying and would wonder why is it neccessary. I wouldn’t wonder. Leaving out the () :* part just works because our type-level “values” are not typed, i.e., there aren’t different kinds Digit and Number but only kind *. If :+ would be a data constructor (on the value level), it would take a number and a digit argument which would forbid using a digit as its left argument. So I consider using a digit on the left as “unclean”. It’s similar to using a number as the second part of a cons cell in LISP. seconded ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 9, 2008 11:33 PM, Alfonso Acosta [EMAIL PROTECTED] wrote: On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: example really applies here. Besides, you should be regarded :* as (,) and not as a constructor which would take a number and a digit Sorry for my lousy English, I meant you should regard not you should be regarded. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 9, 2008 4:08 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: So what would (D1 :* D1) :* (D2 :* D2) mean then? Nothing. That value doesn't satisfy the Nat or Post class constraints and should be taken into consideration. Why should :* be provided a meaning? it is an unavoidable syntactical connective for all that I care. The meaning is provided by class constraints and that's all that matter from the semantical point of view. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 8, 2008 5:14 PM, Stefan Monnier [EMAIL PROTECTED] wrote: How 'bout treating :+ as similar to `append' rather than similar to `cons'? Basically treat :+ as taking 2 numbers (rather than a number and a digit). Interpreting it like that would certainly make make more sense. But again, I think that :* should be interpreted just as an unavoidable syntactical annoyance without meaning or interpretation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie: Even if () would be preferred from the programmers point of view (I'm not sure how much we could reduce the number of instances though), it makes the representation less attractive on the user-side. Anyone using the library would find it annoying and would wonder why is it neccessary. I wouldn't wonder. Leaving out the () :* part just works because our type-level values are not typed, i.e., there aren't different kinds Digit and Number but only kind *. If :+ would be a data constructor (on the value level), it would take a number and a digit argument which would forbid using a digit as its left argument. Well, the fact is that :+ (or :* as it is called now) is not a value constructor but a type constructor as you said, so I don't think your example really applies here. Besides, you should be regarded :* as (,) and not as a constructor which would take a number and a digit argument which would forbid using a digit as its left argument. Indeed, :* exists as a value-level constructor too and works exactly like that. Furthermore, you probably consider using () as natural and logical because you are still thinking from the implementation side. If you forget the implementation details and think as a user who barely wants to write type-level numerical literals, :* is simply an ugly syntactic requirement which we cannot get rid of (I would be happy to find another representation closer to a literal, but I couldn't until now). That is not the case for (), since, as shown in the initial implementation, can be avoided. So, for me, it's just a matter of usability and syntax, the closer the representation can be to literals, the better. I don't see the semantic implications of :* as a valid argument. For me, :* is just an unavoidable ugly syntactical token without meaning. Imagine that for some reason, adding () as a prefix in every numerical literal made the implementation of a compiler slightly easier/faster. I bet users would rant about it till exhaustion :) If the argument was that, for some reason, () was proven to speed up the implementation or make a big maintainability difference (I still have my doubts) it would maybe make more sense (I still wouldn't be sure if it pays off though). Maybe it would be a good idea to create a patch and see what happens :) As a side note, I think that type-value digits actually are typed (metatyped maybe is a nicer term?). Class constraints take the role of types in this case. After all (sorry if the definition is imprecise), a type establishes a set of valid values. Nat n = n does exactly that. For example, it forces type-level naturals to be normalized (i.e. numerals with leading zeros don't satisfy the Nat constraint) So I consider using a digit on the left as unclean. It's similar to using a number as the second part of a cons cell in LISP. Again, the comparisson is based on semantical implications of the implementation which shouldn't be visible for, or at least not taken into consideration by, the final user. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
On Feb 9, 2008 12:28 AM, Tom Hawkins [EMAIL PROTECTED] wrote: 5) Forget embedding the DSL, and write a direct compiler. In addition to the sharing problem, another shortcoming of Haskell DSLs is they can not fully exploit the benefits of algebraic datatypes. Specifically, pattern matching ADTs can only be used to control the compile-time configuration of the target, it can't be used to describe the target's behavior -- at least for DSLs that generate code that executes outside of Haskell's runtime. Only partly true. Probably you are not aware of them (I myself learned about its existence a few days ago) but pattern quasiquoting (available in GHC's HEAD) can be used for that. http://www.haskell.org/ghc/dist/current/docs/users_guide/template-haskell.html#th-quasiquotation Writing a real compiler would solve both of these problems. Is there any Haskell implementation that has a clean cut-point, from which I can start from a fully type-checked, type-annotated intermediate representation? If you have to write a compiler why not define a language which fits better with the semantics of the embedded language instead of using plain Haskell? The approach you propose has the disadvantages of both the embedded and the standalone languages. On one hand you have to stick with the syntax of the host language which may not fit with your exact semantical requirements and, on the other hand, you cannot take advantage of all the existing machinery around the host language (you have to code your own compiler). Furthermore, the first citizen status of functions make it impossible (or really difficult at least) to compile EDSL descriptions avoiding runtime and simply applying a static analysis approach (using Core or plain Haskell as input). And thanks for the link to John's paper describing Hydra's use of Template Haskell. I will definiately consider TH. Well, TH would be one of those static analysis approaches. Actually, O'Donell's implementation (which uses an outdated version of Template Haskell) only works with a small Haskell subset. So using TH you'd probably be changing the host language anyhow. Furthermore, the TH approach consists in adding node labels by preprocessing the EDSL description, making sharing observable. That makes the original EDSL description inpure. The only difference is that side effects are added by preprocessing instead of using runtime unsafe functions. Some pointers covering the topic: [1] and [2] summarize what are the alternatives to observe sharing in Haskell whereas [3] compares the embedded approach vs standalone approach and advocates the last one. 1) http://www.imit.kth.se/~ingo/MasterThesis/ThesisAlfonsoAcosta2007.pdf (section 2.4.1 and 3.1) 2) http://www.cs.um.edu.mt/svrg/Papers/csaw2006-01.pdf (section 3) 3) http://web.cecs.pdx.edu/~sheard/papers/secondLook.ps ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
On Fri, 8 Feb 2008, Matthew Naylor wrote: Now recall that referential transparency lets you replace equals with equals without changing the *value produced* by a program. Note that it says nothing about preserving *runtime behaviour*. Sharing, for example, may be lost. So if you do equational reasoning on function f (above), and loose some sharing, then you can only expect that the same sharing will also be also lost in the generated program. As long as the generated program computes the same result as it did before, referential transparency will be, overall, preserved; it would only be lost intermediately. This is what I mean by safe. I think there are degrees of observability. If a Haskell library immediately talks to a C library and shares resources generated by the library, then this sharing can be hardly observed and the method is somehow safe. If you generate a C program with Haskell and write it to a disk it can be easily observed and people might rely on a particular resulting C program. If the C program is piped to a C compiler which is immediately run, then sharing can be hardly observed. Even within Haskell sharing is somehow observable, the Haskell program could observe the free memory of the machine and thus it can see a difference between sharing and duplicated objects. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Create a list without duplicates from a list with duplicates
On Fri, 8 Feb 2008, [EMAIL PROTECTED] wrote: Hallo! Let's suppose I have a list [a,b,c,d,c,d]. I'd like to write a function that returns a new list without duplicates (in the example [a,b,c,d]). How can I do that? What is the most general way? I'd like to use the same function for a list of Int or String or some other user defined data type. List.nub I assume you couldn't find this function due its cryptic name. Don't worry, many others failed before. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Datatypes - Haskell
Hello to everybody I am an new user of Haskel and generally in functional programming and I could say that I am very impressed from this Language. Though I can't understand the use of datatypes. Let's take a firly simple situtation e.g. data Pair a b = Pair a b i.e. an new type with name Pair parameterized over the types a,b with one Constructor named Paid which take two values of type a,b a more complex one would be data Either a b = Left a | Right b i.e a new type named Either parameterized over the types a, b and two Constructors 1. Left which take one value of type a and 2. Right which takes one value of type b I consider that the definitions above are well formulated. Nevertheless I can't understand them quite well. I have read that datatypes are used to define new structures. So, is there any corresponding example in C, sinch I am quite familiar with structures in it? I hope the word C here is allowed here :o) Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Datatypes - Haskell
On Feb 9, 2008, at 19:09 , Mattes Simeon wrote:
e.g. data Pair a b = Pair a b
struct Pair { a pair_a; b pair_b; };
data Either a b = Left a | Right b
union Either { enum { Left, Right } _tag; a either_left; b
either_right; };
(except that Haskell makes sure you use it properly, while C will let
you access foo.either_right when foo._tag == Left).
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Fri, 8 Feb 2008, Brandon S. Allbery KF8NH wrote: On Feb 8, 2008, at 11:14 , Stefan Monnier wrote: You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the latter representation should probably be prefered. (...) How 'bout treating :+ as similar to `append' rather than similar to `cons'? Basically treat :+ as taking 2 numbers (rather than a number and a digit). Dumb questions department: why not define e.g. D'0 .. D'9 as () :* 0 .. () :* 9? Programmers then get D'1 :* 2, but the library sees () :* 1 :* 2. Do you remember that they talk about types D0, D1, and so on? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Datatypes - Haskell
On Feb 10, 2008 12:09 AM, Mattes Simeon [EMAIL PROTECTED] wrote:
Hello to everybody
I am an new user of Haskel and generally in functional programming and I
could
say that I am very impressed from this Language. Though I can't understand
the
use of datatypes.
Let's take a firly simple situtation
e.g. data Pair a b = Pair a b
i.e. an new type with name Pair parameterized over the types a,b with one
Constructor named Paid which take two values of type a,b
a more complex one would be
data Either a b = Left a | Right b
i.e a new type named Either parameterized over the types a, b and two
Constructors 1. Left which take one value of type a and 2. Right which
takes one
value of type b
I consider that the definitions above are well formulated. Nevertheless I
can't
understand them quite well.
I have read that datatypes are used to define new structures. So, is there
any
corresponding example in C, sinch I am quite familiar with structures in
it? I
hope the word C here is allowed here :o)
I guess C++ would be closer...
template class A, class B
struct Pair
{
A fst;
B snd;
}
template class A, class B
struct Either
{
enum {Left, Right} tag;
union{
A left;
B right;
};
}
In the second example the tag would be used to figure out which of the two
alternatives the structure actually is. In Haskell you can just pattern
match on the constructor.
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Finance-Treasury 0.1.1
A new experimental package, Finance-Treasury, has been uploaded to hackage. It automates the fetching of Treasury's daily yield curve data (XML) and translates the data into Data.Map representation. The collection of historical data can go back to 1992. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Treasury The APIs are largely working. But the internal code still needs improvement. Welcome suggestions and fixes. Recommendation on proper error handling design will be particularly appreciated. steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
Moving on to the implementation of fixed-sized vectors themselves ...
I have been trying to implement them as a GADT but I have run into
quite few problems. As a result, I'm considering to implement them
using the more-traditional phantom type-parameter approach. Anyhow,
I'd like to share those problems with the list, just in case someone
comes with a solution.
Here are some examples of what I was able to define without problems
(although, for some cases, I was forced to break the safety layer of
the GADT by using the toInt reflection function).
Save this email as FSVec.lhs to test them.
{-# LANGUAGE GADTs, Rank2Types, ScopedTypeVariables, KindSignatures #-}
module Data.Param.FSVec where
import Data.TypeLevel.Num
The Fixed Sized Vector data type. I know Wolfgang would prefer
something more closely named to LiSt to, but let's avoid getting into
that discussion now.
data FSVec :: * - * - * where
NullV :: FSVec D0 a
(:) :: Succ s s' = a - FSVec s a - FSVec s' a
infixr :
Some successful examples
headV :: Pos s = FSVec s a - a
headV (x : xs) = x
lastV :: Pos s = FSVec s a - a
lastV = lastV'
-- trusted function without the Pos constraint, otherwise the compiler
would complain about
-- the Succ constraint of : not being met.
where lastV' :: FSVec s a - a
lastV' (x : NullV) = x
lastV' (x : xs)= lastV' xs
atV :: (Pos s, Nat n, n :: s) = FSVec s a - n - a
atV v n = atV' v (toInt n)
-- Reflecting the index breaks checking that the recursive call
-- verifies the atV constraints, however I couldn't find another way.
-- atV' is to be trusted regarding the recursive call
where atV' :: FSVec s a - Int - a
atV' (x : xs) n
| n == 0 = x
| otherwise= atV' xs (n-1)
-- this defition is nicer but doesn't typecheck
-- atV (x : xs) n
-- | toInt n == 0 = x
-- | otherwise = atV xs (predRef n)
Now some functions which I wasn't able to define
Concat function. This would be the naive implementation, but it fails
to compile.
(+) :: Add s1 s2 s3 = FSVec s1 a - FSVec s2 a - FSVec s3 a
NullV + ys = ys
(x:xs) + ys = x : (xs + ys)
Tail function, which is also incorrect.
tailV :: Succ s' s = FSVec s a - FSVec s' a
tailV (x : xs) = xs
And finally, vector, which is supposed to build a fixed-sized vector
out of a list.
The ideal type for the function would be:
vector :: [a] - FSVec s a
But there is no apparent way in which to obtain s based on the length
of the input list.
[1] shows a way in which to create vector using CPS style and a
reification function:
reifyInt :: Int - (forall s . Nat s = FSVect s a - w) - w
The result would be a function with the following type:
vector :: [a] - (forall s . Nat s = FSVec s a - w) - w
Nevertheless, I'm not fully satisfied by it.
Another alternative would be forcing the user to provide the size
explicitly (which is ugly as well)
vector' :: Nat s = s - [a] - FSVec s a
The Succ constraint in the definition of : doesn't allow me to do
such a thing. The following implementation does not typecheck:
vector' :: Nat s = s - [a] - FSVec s a
vector' s l
| toInt s == length l = vector' l
| otherwise = error dynamic/static size mismatch
where vector'' :: [a] - FSVec s a
vector'' []= NullV
vector'' (x : xs) = x : vector' xs
The problem is that I don't know a way in which to bypass the Succ
constraint of : .
Using a traditional phantom type-parameter to express the size is the
only solution I can think of (which would also solve the problems of
init and tail). However, that would mean losing the ability of
pattern matching with (:).
Any comments/suggestions would be very much appreciated.
Cheers,
Fons
[1] http://ofb.net/~frederik/vectro/draft-r2.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
Hi Matt, On Feb 9, 2008 1:07 PM, Matthew Naylor [EMAIL PROTECTED] wrote: If you go the real compiler route, would it not make sense to take the DSL as the source language rather than Haskell? Or are the DSL and Haskell quite similar? The two are nearly identical. In fact the only significant difference between the languages is the semantics of top level monad; it wouldn't be IO, but something else. With the syntax the same, it could leverage much of Haskell's standard library. Or perhaps you are thinking of a two language system, where some code is evaluated at compile time by Haskell, and some is compiled to the target language? Not necessarily in the same compilation flow, but I can think of several scenarios where it would be advantageous for code written in this other language to be pulled into a conventional Haskell program. Taking options 2 or 5 just to solve the sharing problem sounds to me like a lot of hard work for little reward. But don't worry, I won't repeat my observable sharing speech. :-) So is the general strategy with observable sharing to use unsafePerformIO with Data.Unique to label expressions at construction? Ahh...clever! I did not think of this. Of course, now that you have me reading up on Yhc.Core, option #5 is looking considerably more fun. -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
