On Fri, Mar 14, 2008 at 9:58 PM, Wolfgang Jeltsch
[EMAIL PROTECTED] wrote:
Am Freitag, 14. März 2008 17:46 schrieben Sie:
I think that removing aliases completely is not a good idea. How about
generating much lower aliases for decimals (lets say until 1000),
I don't think, this is a good
Am Samstag, 2. Februar 2008 14:54 schrieben Sie:
On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote:
Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta:
[…]
To make it friendlier for the end user I thought about defining
aliases for lets say the first 1 numbers using Template
On Fri, Mar 14, 2008 at 5:30 PM, Wolfgang Jeltsch
[EMAIL PROTECTED] wrote:
I have a feedback from my Grapefruit co-developer about those aliases in the
type-level package. He told me that on his machine, building this package
took about 15 minutes, obviously because the machine ran out of
Am Freitag, 14. März 2008 17:46 schrieben Sie:
[…]
I think that removing aliases completely is not a good idea. How about
generating much lower aliases for decimals (lets say until 1000),
I don’t think, this is a good idea. Like nobody will need an alias for 8247,
nobody will need an alias
OK I'll include the module after I change the things mentioned.
BTW, I finally have an initial version of the parameterized-data package:
Darcs repository:
http://code.haskell.org/parameterized-data
Haddock documentation:
http://code.haskell.org/~fons/parameterized-data/doc/
Any
Am Mittwoch, 20. Februar 2008 09:20 schrieben Sie:
OK I'll include the module after I change the things mentioned.
BTW, I finally have an initial version of the parameterized-data package:
Darcs repository:
http://code.haskell.org/parameterized-data
Haddock documentation:
On Wed, Feb 20, 2008 at 11:26 AM, Wolfgang Jeltsch
[EMAIL PROTECTED] wrote:
Hello Fons,
why do you use the term vector? I'd say that this term is more or less wrong
for what this type is about. The distinguishing property of vectors compared
to lists is that there is addition and scalar
On Feb 14, 2008 10:40 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
So we should parameterized for the package name.
That's the packagename I've been using. I'm done with a basic
implementation but I'd like to test some other things before showing
the code.
On the other hand, I think that the
Am Dienstag, 19. Februar 2008 21:44 schrieben Sie:
* Support of type-level Booleans (Wolfgang?)
Attached is just a quickly hacked Boolean module. Nothing very special. I’d
be happy if you could prettify this (choose better names, add documentation,
etc.). Thanks for any effort.
Best
2008/2/19 Wolfgang Jeltsch [EMAIL PROTECTED]:
Attached is just a quickly hacked Boolean module. Nothing very special. I'd
be happy if you could prettify this (choose better names, add documentation,
etc.). Thanks for any effort.
Thanks to you for the module. I have a few questions though.
Am Mittwoch, 20. Februar 2008 00:39 schrieben Sie:
Why are the value-level reflecting functionsimplemented as type-class
methods? It makes the code more verbose and I don't see any advantage
compared to simply defining a function per class. Let me show you an
example:
This is your
Am Donnerstag, 14. Februar 2008 03:23 schrieben Sie:
To directly answer Wolfgang's question: parameterized is the more
common. It is more correct only insofar as it is the more common.
So we should “parameterized” for the package name.
Best wishes,
Wolfgang
I asked Oleg regarding the use of GADTs to emulate dependent types. My
conclusion is that I should forget about them. Here is the full
answer:
-- Forwarded message --
From: [EMAIL PROTECTED]
Date: Feb 12, 2008 8:49 AM
Subject: Re: GADTs to emulate dependent types?
To: [EMAIL
Concerning parametrized vs parameterized
On 12 Feb 2008, at 11:21 pm, Wolfgang Jeltsch asked:
What spelling is more common?
Strictly speaking, there is no such word in English as parametrized.
There is no general morphological rule Xer = Xrized in English.
The only spelling accepted by the OED
Richard A. O'Keefe wrote:
Concerning parametrized vs parameterized
On 12 Feb 2008, at 11:21 pm, Wolfgang Jeltsch asked:
What spelling is more common?
Strictly speaking, there is no such word in English as parametrized.
Except that, strictly speaking, there *is* a word parametrized in
Am Montag, 11. Februar 2008 21:44 schrieben Sie:
Alfonso Acosta wrote:
So type-level + parametrized-data is my vote. But don't let's spend too
much time discussing the name. ;-)
Fair enough. type-level + parameterized-data it is then (unless
someone else has a better suggestion). I'm
Hi Dan,
On Feb 10, 2008 6:08 PM, Dan Licata [EMAIL PROTECTED] wrote:
The ideal type for the function would be:
vector :: [a] - FSVec s a
Well, I probably didn't express myself properly when writing The
ideal type, the first type which comes to mind would have been more
accurate.
Thanks
Alfonso Acosta wrote:
So type-level + parametrized-data is my vote. But don't let's spend too much
time discussing the name. ;-)
Fair enough. type-level + parameterized-data it is then (unless
someone else has a better suggestion). I'm going to begin coding now.
hang on, parametrized or
Am Montag, 11. Februar 2008 18:17 schrieben Sie:
[…]
As suggested by the pointer you provided, I redefined FSVec and tailV
using a transformating of Succ into a type synonym family (see the end
of this mail for its full definition) but it didn't help.
Be careful! Type family support is
Am Sonntag, 10. Februar 2008 05:14 schrieben Sie:
[…]
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 +
Am Samstag, 9. Februar 2008 23:33 schrieben Sie:
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
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
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
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
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,
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
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
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
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
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
Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie:
On Feb 7, 2008 4:16 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
[…]
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
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
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'?
Dan Weston wrote:
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
On Feb 6, 2008 8:47 PM, Alfonso Acosta [EMAIL PROTECTED] wrote:
On Feb 7, 2008 2:30 AM, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
Ok. Is this what people want -- one big hold-all library with
everything, as opposed to smaller more specialized packages? I guess I
can see advantages (real or
Am Donnerstag, 7. Februar 2008 02:47 schrieb Alfonso Acosta:
The other library I use for type-level programming is HList. It has
type-level booleans already so you might what to take a look at it if
you're not already familiar with it.
Thanks I'll have a look at it.
I have to admit that I
On Feb 7, 2008 9:01 PM, Dan Weston [EMAIL PROTECTED] wrote:
This may be a GHC bug, but even though in the module
Data.TypeLevel.Num.Reps has the header
{-# LANGUAGE EmptyDataDecls, TypeOperators #-}
I still get an error with both ghc and ghci version 6.8.2 unless I throw
in the
I know that naming is arbitrary, but...
Digits in types seems ugly to me. In this case, it is also redundant.
Everyone but FORTRAN programmers counts from 0, not 1. Nat and Pos seem
clear. Nat0 could even mean Nat \ {0}, the opposite of what is proposed,
so confusion is even increased with
This may be a GHC bug, but even though in the module
Data.TypeLevel.Num.Reps has the header
{-# LANGUAGE EmptyDataDecls, TypeOperators #-}
I still get an error with both ghc and ghci version 6.8.2 unless I throw
in the -XTypeOperators flag.
cat Go.hs
import Data.TypeLevel.Num.Reps
main =
On Feb 7, 2008 4:16 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Nat means all natural numbers except zero while Nat0 means all natural
numbers (including zero). Since in computer science, natural numbers
usually cover zero, we should use Pos instead of Nat and Nat instead of Nat0.
Sounds
On Feb 7, 2008 8:38 PM, Dan Weston [EMAIL PROTECTED] wrote:
I know that naming is arbitrary, but...
Digits in types seems ugly to me. In this case, it is also redundant.
Everyone but FORTRAN programmers counts from 0, not 1. Nat and Pos seem
clear. Nat0 could even mean Nat \ {0}, the opposite
On 8 Feb 2008, at 8:38 am, Dan Weston wrote:
I know that naming is arbitrary, but...
Digits in types seems ugly to me. In this case, it is also
redundant. Everyone but FORTRAN programmers counts from 0, not 1.
Nat and Pos seem clear. Nat0 could even mean Nat \ {0}, the
opposite of what
On Feb 6, 2008 4:32 AM, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
Well, could you elaborate a little on joining efforts? The effort I
was planning to invest in my package consists mainly of creating a
.cabal file plus some logistics to get tarballs to where they have to
be.
I understand that
On Feb 6, 2008 1:03 PM, Alfonso Acosta [EMAIL PROTECTED] wrote:
On Feb 6, 2008 4:32 AM, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
I understand that you (and Wolfgang) are creating a library of type
level decimals for the purpose of constraining vector (list?) lengths.
After that I haven't
On Feb 7, 2008 2:30 AM, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
Ok. Is this what people want -- one big hold-all library with
everything, as opposed to smaller more specialized packages? I guess I
can see advantages (real or perceived) to both approaches.
Apart from Dockins' typenats library
On Fri, 1 Feb 2008, Aaron Denney wrote:
On 2008-02-01, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
If Naturals had been sufficient for me I wouldn't have done my own
implementation (I'm unaware of any other implementation of Integers).
And there is certainly a lot of value to the clearer
On Feb 5, 2008 2:16 PM, Alfonso Acosta [EMAIL PROTECTED] wrote:
On Feb 5, 2008 4:10 PM, Henning Thielemann
[EMAIL PROTECTED] wrote:
On Fri, 1 Feb 2008, Aaron Denney wrote:
On 2008-02-01, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
If Naturals had been sufficient for me I wouldn't have
On Feb 5, 2008 4:10 PM, Henning Thielemann
[EMAIL PROTECTED] wrote:
On Fri, 1 Feb 2008, Aaron Denney wrote:
On 2008-02-01, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
If Naturals had been sufficient for me I wouldn't have done my own
implementation (I'm unaware of any other implementation
On Feb 5, 2008 8:29 PM, Bjorn Buckwalter [EMAIL PROTECTED] wrote:
On Feb 5, 2008 2:16 PM, Alfonso Acosta [EMAIL PROTECTED] wrote:
On Feb 5, 2008 4:10 PM, Henning Thielemann
[EMAIL PROTECTED] wrote:
On Fri, 1 Feb 2008, Aaron Denney wrote:
On 2008-02-01, Bjorn Buckwalter [EMAIL
I'm almost done with the decimal library but it would be nice to check
some Integer implementations for future inclusion. So, Aaron, Björn,
are your implementations available somewhere?
As noted elsewhere in the thread my implementation is available at:
On Feb 4, 2008 12:36 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Am Samstag, 2. Februar 2008 14:54 schrieben Sie:
Again, if someone complains about the TH dependency, the aliases could
be generated by TH but saved statically in a module for each release.
Hmm, this could be a compromise
Am Montag, 4. Februar 2008 13:22 schrieben Sie:
On Feb 4, 2008 12:36 PM, Wolfgang Jeltsch wrote:
[…]
I don't still know how many people would be interested in using the
type-level library so, again, I think it won't hurt to include the
TH-generated aliases and then change it if some non-GHC
Am Samstag, 2. Februar 2008 14:54 schrieben Sie:
On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote:
Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta:
[…]
To make it friendlier for the end user I thought about defining
aliases for lets say the first 1 numbers using Template
Am Montag, 4. Februar 2008 20:44 schrieben Sie:
I'll host the project in community.haskell.org, do you have an account
there?
Now, I haven't. :-(
Well, you can request one at
http://community.haskell.org/admin/account_request.html if you want
Otherwise I'll take the maintainer role.
On Feb 4, 2008 8:27 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Am Montag, 4. Februar 2008 13:22 schrieben Sie:
I don't still know how many people would be interested in using the
type-level library so, again, I think it won't hurt to include the
TH-generated aliases and then change it if
On Feb 1, 2008 10:33 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Actually it would maybe be better to create common high-level
interface that could include unary, binary and decimal arithmetic so
that the library could be easily reused in other projects (people like
Bjorn, seem to be
On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta:
On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch [EMAIL PROTECTED]
This is essentially what I had in mind. While Oleg's implementation
needs a thrusted core, the GADT
On Feb 2, 2008 2:54 PM, Alfonso Acosta [EMAIL PROTECTED] wrote:
Just compare
f :: List (() :- D1 :- D0 :- D0 :- 1000) Int - List (() :- D1 :- D0
:- D0 :- D0) Int
I meant
f :: List (() :- D1 :- D0 :- D0 :- D0) Int - List (() :- D1 :- D0 :-
D0 :- D0) Int
sorry for the typo
On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Am Donnerstag, 31. Januar 2008 18:30 schrieb Dominic Steinitz:
Look at
http://sneezy.cs.nott.ac.uk/fun/feb-07/jeremy-slides.pdf
This is essentially what I had in mind. While Oleg's implementation needs
a thrusted core,
What about FixedVector for the vector library and DecTypArith (maybe
too long) or DecTypes for the type-level decimal arithmetic library?
Actually it would maybe be better to create common high-level
interface that could include unary, binary and decimal arithmetic so
that the library could be
Am Freitag, 1. Februar 2008 05:11 schrieben Sie:
Wolfgang Jeltsch wrote:
Well, the representation (D1,D2,D9) might be considered more readable.
It has the disadvantage of a fixed maximum size for the numbers. Which
takes me to a point I had already considered some time ago: Wouldn’t it
Am Freitag, 1. Februar 2008 13:09 schrieben Sie:
What about FixedVector for the vector library and DecTypArith (maybe
too long) or DecTypes for the type-level decimal arithmetic library?
Actually it would maybe be better to create common high-level
interface that could include unary, binary
Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta:
On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch [EMAIL PROTECTED]
wrote:
Am Donnerstag, 31. Januar 2008 18:30 schrieb Dominic Steinitz:
Look at
http://sneezy.cs.nott.ac.uk/fun/feb-07/jeremy-slides.pdf
This is essentially what I
Wolfgang Jeltsch wrote:
Am Freitag, 1. Februar 2008 05:11 schrieben Sie:
Wolfgang Jeltsch wrote:
Well, the representation (D1,D2,D9) might be considered more readable.
It has the disadvantage of a fixed maximum size for the numbers. Which
takes me to a point I had already considered some
Am Donnerstag, 31. Januar 2008 18:30 schrieb Dominic Steinitz:
Look at
http://sneezy.cs.nott.ac.uk/fun/feb-07/jeremy-slides.pdf
This is essentially what I had in mind. While Oleg’s implementation needs
a “thrusted core”, the GADT solution doesn’t.
It would be interesting to combine GADTs
Hello Ryan,
I hope, it’s okay to forward your message to the list:
Date: Freitag, 1. Februar 2008 01:41
From: Ryan Ingram [EMAIL PROTECTED]
To: Wolfgang Jeltsch [EMAIL PROTECTED]
This representation is not exactly the same when you include _|_.
For example:
data None -- only _|_ /
Wolfgang Jeltsch wrote:
Well, the representation (D1,D2,D9) might be considered more readable. It has
the disadvantage of a fixed maximum size for the numbers. Which takes me to
a point I had already considered some time ago: Wouldn’t it be good if we had
just a type
data Pair val1
You could solve it this way:
data PairL a b = PairL a !b
where (a,b,c) is syntactic sugar for
PairL a (PairL b (PairL c ()))
There are still potential efficiency issues, although this could be
worked out in the compiler; right now it's a single operation to get
from a tuple to any member,
68 matches
Mail list logo
