billpmurphy/hask

Haskell language features and standard libraries in pure Python.

hask's Issues

No floating point ranges

Haskell allows floating point ranges:

Prelude> [0.1, 0.2 .. 0.5]
[0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001]

This does not work in Hask:

>>> L[0.1, 0.2, ..., 0.5]
TypeError Traceback (most recent call last)
....
TypeError: No instance for 0.1

Because floating point ranges are tricky:

Prelude> [0.1, 0.3 .. 1]
[0.1,0.3,0.5,0.7,0.8999999999999999,1.0999999999999999]

it might not be a good idea to implement them at all. In this case a more descriptive error message or even a own, new exception type might be helpful.

Improve printing of type signatures

Hask prints type signatures with a lot of superfluous parens (e.g. a -> (b -> c) when a -> b -> c will do). It also puts extra parens around higher-kinded types even when this is not necessary.

bug in file __init__.py

I want to install hask. On Python 3.4.3 64 bit in windows 8.1
I using

git clone https://github.com/billpmurphy/hask
cd hask
python setup.py install

but

Traceback (most recent call last):
  File "setup.py", line 1, in <module>
    import hask
  File "C:\Users\วรรณพงษ์\hask\hask\__init__.py", line 8, in <module>
    import lang
ImportError: No module named 'lang'

No module named 'lang'.

Proposing a PR to fix a few small typos

Issue Type

[x] Bug (Typo)

Steps to Replicate and Expected Behaviour

• Examine README.md and observe tempurature, however expect to see temperature.
• Examine hask/lang/syntax.py and observe undesireable, however expect to see undesirable.
• Examine hask/lang/syntax.py and observe statment, however expect to see statement.
• Examine README.md and observe separted, however expect to see separated.
• Examine hask/lang/type_system.py and observe psuedo, however expect to see pseudo.
• Examine README.md and observe provies, however expect to see provides.
• Examine hask/lang/type_system.py and observe paramaters, however expect to see parameters.
• Examine hask/lang/lazylist.py and observe interable, however expect to see iterable.
• Examine README.md and observe convineient, however expect to see convenient.
• Examine README.md and observe convinience, however expect to see convenience.
• Examine README.md and observe compatibity, however expect to see compatibility.

Notes

Semi-automated issue generated by
https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md

To avoid wasting CI processing resources a branch with the fix has been
prepared but a pull request has not yet been created. A pull request fixing
the issue can be prepared from the link below, feel free to create it or
request @timgates42 create the PR. Alternatively if the fix is undesired please
close the issue with a small comment about the reasoning.

https://github.com/timgates42/hask/pull/new/bugfix_typos

Thanks.

Correctly unify typeclass constraints when inferring types

When a TypeVariable with typeclass constraints are unified with a TypeOperator, the type system (i.e., unify in hindley_milner.py) does not check to see if the TypeOperator is actually a member of the required typeclasses. As a result of this, some TypeErrors related to typeclass membership will not be raised until function-call time (as opposed to function-compose time).

For example, consider show (of the Show typeclass). When show is composed with id, the typeclass constraints will be unified and the composed function will have the correct constrained type. If you compose show with a function with a concrete (TypeVariable) output type which is not a member of Show, the type inference system will not check the constraint and raise a TypeError until the composed function is actually called.

Upgrade Hask port of Prelude and Data.List to 4.8.1.0

The Hask port of the Prelude and Data.List are on version 4.7.0.2 of base. These should be upgraded to the newest version (at time of writing). 4.8.1.0. The primary difference between versions is that some of functions in Data.List are now in Data.Foldable, and operate on Foldable instances rather than just lists.

Double underscore conflicts with IPython

Description

IPython (and IPython Notebook) uses __ to point to the next previous output.
Open IPython and type:

In [1]: %quickref

to see this help message:

_, __, ___       : previous, next previous, next next previous output

Because IPython is used widely and will likely be used by more and more Python users, I strongly recommend to change __ into something else. For example, _s for section could work.

Example

In [1]: from hask import __

In [2]: __
Out[2]: <hask.lang.syntax.__section__ at 0x1039e9890>

In [3]: 1 + 1
Out[3]: 2

In [4]: 2 + 2
Out[4]: 4

In [5]: __
Out[5]: 2

Unexpected repr of sliced list with [:]

The representation of a sliced list with an end index looks as expected:

>>> L[1, 2, 3][:10]
L[1, 2, 3]

Using the [:] to "slice" the whole list shows extra ...:

L[1, 2, 3][:]
L[1, 2, 3 ...]

Is this intentional? If yes, what is the rational behind it?

Python 3?

Hey @billpmurphy, just saw you were active a few days ago. I know it's been a heck of a long time since you made hask, but would you be willing to update it to Python 3? Or do you know of a way I can do so?

setup.py does not install subpackages

Problem

The setup.py is does not install subpackages:

Fix

This line in the call to setup:

packages=['hask'], 

needs to be replaced by:

packages=['hask', 'hask.lang', 'hask.Python', 'hask.Data',  'hask.Control'],

Remove the `t` operator in type signatures

Instead of having to type t(Maybe, int) or t(Either, "a", str), it would be much cleaner to type Maybe(int) or Either("a", str).

This should be relatively easy to implement, though it would require a major change to some parts of type_system.py, which would be a large breaking change. More experimentation is necessary, I think.

Fix unification of higher-kinded types when performing type inference

Related to #1, the type system does not unify higher-kinded types correctly, as it ignores kind when unifying, so a TypeVariable like m a currently unifies with a type like Either int str. This was done tso that typeclasses could be quickly grafted onto the type system; unlike in Haskell, where a partially-applied HKT can be a member of a typeclass (e.g., Either a is a member of Monad), here the HKT object itself is always a member. This is a temporary hack and should be corrected.

Letters in signatures always get incremented. Results in running out of letters quickly.

This test script:

from __future__ import print_function

from hask import H, sig, _t

for x in range(10):
    @sig(H / 'a' >> 'b')
    def f1(a):
       return a

    @sig(H / 'a' >> 'b')
    def f2(a):
       return a

    print('f1:', _t(f1))
    print('f2:', _t(f2))

Produces this output (Note: _t has been modified to return instead of printing.) :

f1: (a -> b)
f2: (c -> d)
f1: (e -> f)
f2: (g -> h)
f1: (i -> j)
f2: (k -> l)
f1: (m -> n)
f2: (o -> p)
f1: (q -> r)
f2: (s -> t)
f1: (u -> v)
f2: (w -> x)
f1: (y -> z)
f2: ({ -> |)
f1: (} -> ~)
f2: ( -> ?)
f1: (? -> ?)
f2: (? -> ?)
f1: (? -> ?)
f2: (? -> ?)

Wouldn't it be better start afresh with a for each function? There are two cases were this really matters:

1. Defining many functions.
2. Working interactively, for example in an IPython Notebook, and redefining a function again and again.

Both scenarios can lead to a running out of printable characters.

Gradual typing?

It seems like it would be relatively easy to enable gradual typing in Hask. In Hask's internal type system, the type of Python functions and methods (regardless of arity) is PyFunc. To enable gradual typing, there could be an option that will allow any function type to unify with PyFunc.

Polymorphic typechecking doesn't work

It looks like hask always trusts type signatures and doesn't check them.

E.g.

from hask import *

@sig(H/ "a" >> "b" >> "c")
def const1(x, y):
    return x+1
print(const1(1,2))

runs successfully.

If my understanding is correct, perhaps you should highlight this fact in the readme and not claim "Full Hindley-Milner type system that will typecheck any function decorated with a Hask type signature".

Foldr does not unify types correctly

Somethis is not quite right with the way the list type is being unified, as seen here when using foldr with cons:

>>> from hask import *
>>> import hask.Data.List as DL
>>> cons = (lambda x, y: x ^ y) ** (H/ "a" >> ["a"] >> ["a"])

>>> _t(cons)
'(a -> ([a] -> [a]))'

>>> DL.foldr(cons, L[[]], L[[1, 2, 3]])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "hask/lang/type_system.py", line 362, in __call__
    result_type = analyze(ap, env)
  File "hask/lang/hindley_milner.py", line 216, in analyze
    unify(Function(arg_type, result_type), fun_type)
  File "hask/lang/hindley_milner.py", line 349, in unify
    unify(p, q)
  File "hask/lang/hindley_milner.py", line 349, in unify
    unify(p, q)
  File "hask/lang/hindley_milner.py", line 347, in unify
    raise TypeError("Type mismatch: {0} != {1}".format(str(a), str(b)))
TypeError: Type mismatch: int != ([] e)

__contains__ is not typechecked for Lists

"a" in L[1L, 3L, ...] fails to terminate; ideally, this should probably raise a TypeError. Some other list operations may be similarly broken.

Hat tip pietrod21 on reddit.

Negative list increment does not work

Haskell allows negative increments:

Prelude> [10, 9 .. 1]
[10,9,8,7,6,5,4,3,2,1]

This does not work in Hask:

>>> L[10, 9, ..., 1]
L[[]]

No PyPI package

Would be far easier to install via pip

Python 3 Install

I can install hask with Python 2 with no issues, but in Python 3 I get the error:

Traceback (most recent call last):
  File "setup.py", line 1, in <module>
    import hask
  File "/home/user/Downloads/hask/hask/__init__.py", line 9, in <module>
    import Data.Char
ModuleNotFoundError: No module named 'Data'

This is presumably because relative imports are gone in Python 3. Is there any way to get it working regardless? I'm really keen to use this.