If you'd design a Haskell-like language, what would you do different?

[Robert Clausecker]

Image you would create your own language with a paradigm similar to
Haskell or have to chance to change Haskell without the need to keep any
compatibility. What stuff would you add to your language, what stuff
would you remove and what problems would you solve completely different?

Thanks in advance for all answers, yours

        Robert Clausecker


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Mathijs Kwik-2]

A mascot :)


On Mon, Dec 19, 2011 at 8:20 PM, Robert Clausecker <[hidden email]> wrote:

> Image you would create your own language with a paradigm similar to
> Haskell or have to chance to change Haskell without the need to keep any
> compatibility. What stuff would you add to your language, what stuff
> would you remove and what problems would you solve completely different?
>
> Thanks in advance for all answers, yours
>
>        Robert Clausecker
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[David Fox-7]

After eight years I'm still discovering why various decisions made in Haskell are right.

On Mon, Dec 19, 2011 at 11:20 AM, Robert Clausecker <[hidden email]> wrote:

Image you would create your own language with a paradigm similar to
Haskell or have to chance to change Haskell without the need to keep any
compatibility. What stuff would you add to your language, what stuff
would you remove and what problems would you solve completely different?

Thanks in advance for all answers, yours

       Robert Clausecker


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Gregory Crosswhite]

On Dec 20, 2011, at 5:20 AM, Robert Clausecker wrote:

What stuff would you add to your language

Gratuitous use of parentheses.

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Alexander Solla]

On Mon, Dec 19, 2011 at 11:20 AM, Robert Clausecker <[hidden email]> wrote:

Image you would create your own language with a paradigm similar to
Haskell or have to chance to change Haskell without the need to keep any
compatibility. What stuff would you add to your language, what stuff
would you remove and what problems would you solve completely different?

Thanks in advance for all answers, yours

* Lenses as the default record infrastructure.  (Maybe...)

* Better organization of numeric (and algebraic/categorical) type classes in the Prelude.

* Documentation that discourages thinking about bottom as a 'value'.  It's not a value, and that is what defines it.

* Getting rid of the Functor/Monad nonsense.  (Every monad is in fact a functor, but we can't use fmap on arbitrary monads in Haskell)

* The inclusion of something like Djinn to automatically generate free theorems from types.  It would be nice if GHCi included an interactive Djinn-like interface to generate alternative non-free functions for a type.

* An API to make automating REPL and text editor interactions straight-forward.  (For example, if we were to use the hypothetical Djinn-like feature, we could select the implementation we want from a list and have it pasted into our text editor of choice automatically)

 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Roman Cheplyaka-2]

* Alexander Solla <[hidden email]> [2011-12-19 19:10:32-0800]
> * Documentation that discourages thinking about bottom as a 'value'.  It's
> not a value, and that is what defines it.

In denotational semantics, every well-formed term in the language must
have a value. So, what is a value of "fix id"?

--
Roman I. Cheplyaka :: http://ro-che.info/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Ben Lippmeier-2]

On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote:

> * Alexander Solla <[hidden email]> [2011-12-19 19:10:32-0800]
>> * Documentation that discourages thinking about bottom as a 'value'.  It's
>> not a value, and that is what defines it.
>
> In denotational semantics, every well-formed term in the language must
> have a value. So, what is a value of "fix id"?

There isn't one!

Bottoms will be the null pointers of the 2010's, you watch.
 
Ben.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Tillmann Rendel-5]

Hi,

Robert Clausecker wrote:
> Image you would create your own language with a paradigm similar to
> Haskell or have to chance to change Haskell without the need to keep any
> compatibility. What stuff would you add to your language, what stuff
> would you remove and what problems would you solve completely different?

I would try to improve the language's support for the embedding of
domain-specific embedded languages (aka. combinator libraries). Such
embedding requires the integration of a domain-specific language's
syntax, static semantics and dynamic semantics. Some (more or less far
fetched) ideas about these three areas follow.


To support better syntax for embedded languages, provide more rebindable
syntax à la do-notation. For example, (if c then t else e) currently
desugars to (case c of False -> e; True -> t). But it could also desugar
to (if' c t e) where if' is a method of a type class. For (c : Bool),
the standard library would provide an instance of this type class, but
for other condition types, third-party libraries could provide it.
Alternatively, if-then-else could even desugar to whatever if' is in
scope. A similar idea is currently applied to Scala in the
scala-virtualized project. A large part of the language should be
virtualized this way, including pattern matching, lambda expressions,
maybe even type or class declarations.

To support better static semantics for embedded languages, provide
better type-level computation, including some form of closed-world
reasoning (for example, backtracking or closed pattern matching) and a
reification of names at the type level, so that type-level computations
can reason about the binding structures of expressions-level code. Note
that I am interested in the static structure of terms, not their dynamic
behavior, so this is different from dependent types.

With Haskell being a fine general-purpose programming language, and even
having a good foreign language interface, there is already plenty of
support for the specification of dynamic semantics. Nevertheless, for
domain-specific embedded compilers, it would possibly be nice to access
a Haskell compiler at runtime, to compile snippets of Haskell code and
dynamically link them into the currently running program.


   Tillmann

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Thiago Negri]

How would you represent it then?

Would it cause a compiler error?

Thiago.

2011/12/20 Ben Lippmeier <[hidden email]>:

>
> On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote:
>
>> * Alexander Solla <[hidden email]> [2011-12-19 19:10:32-0800]
>>> * Documentation that discourages thinking about bottom as a 'value'.  It's
>>> not a value, and that is what defines it.
>>
>> In denotational semantics, every well-formed term in the language must
>> have a value. So, what is a value of "fix id"?
>
> There isn't one!
>
> Bottoms will be the null pointers of the 2010's, you watch.
>
> Ben.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Gregory Crosswhite]

On Dec 20, 2011, at 8:05 PM, Tillmann Rendel wrote:

Hi,

Robert Clausecker wrote:

Image you would create your own language with a paradigm similar to

Haskell or have to chance to change Haskell without the need to keep any

compatibility. What stuff would you add to your language, what stuff

would you remove and what problems would you solve completely different?

I would try to improve the language's support for the embedding of domain-specific embedded languages (aka. combinator libraries). Such embedding requires the integration of a domain-specific language's syntax, static semantics and dynamic semantics. Some (more or less far fetched) ideas about these three areas follow.


To support better syntax for embedded languages, provide more rebindable syntax à la do-notation. For example, (if c then t else e) currently desugars to (case c of False -> e; True -> t). But it could also desugar to (if' c t e) where if' is a method of a type class. For (c : Bool), the standard library would provide an instance of this type class, but for other condition types, third-party libraries could provide it. Alternatively, if-then-else could even desugar to whatever if' is in scope. A similar idea is currently applied to Scala in the scala-virtualized project. A large part of the language should be virtualized this way, including pattern matching, lambda expressions, maybe even type or class declarations.

To support better static semantics for embedded languages, provide better type-level computation, including some form of closed-world reasoning (for example, backtracking or closed pattern matching) and a reification of names at the type level, so that type-level computations can reason about the binding structures of expressions-level code. Note that I am interested in the static structure of terms, not their dynamic behavior, so this is different from dependent types.

With Haskell being a fine general-purpose programming language, and even having a good foreign language interface, there is already plenty of support for the specification of dynamic semantics. Nevertheless, for domain-specific embedded compilers, it would possibly be nice to access a Haskell compiler at runtime, to compile snippets of Haskell code and dynamically link them into the currently running program.

So in other words, you would like Haskell to simultaneously become more like Lisp and more like Agda?  :-)

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Ben Lippmeier-2]

On 20/12/2011, at 9:06 PM, Thiago Negri wrote:
>> There isn't one!
>>
>> Bottoms will be the null pointers of the 2010's, you watch.


> How would you represent it then?

Types probably. In C, the badness of null pointers is that when you inspect an  int*  you don't always find an int. Of course the superior Haskell solution is to use algebraic data types, and represent a possibly exceptional integer by "Maybe Int". But then when you inspect a "Maybe Int" you don't always get an .. ah.


> Would it cause a compiler error?


Depends whether you really wanted an Int or not.

Ben.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Jesse Schalken]

On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier <[hidden email]> wrote:

On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote:

> * Alexander Solla <[hidden email]> [2011-12-19 19:10:32-0800]
>> * Documentation that discourages thinking about bottom as a 'value'.  It's
>> not a value, and that is what defines it.
>
> In denotational semantics, every well-formed term in the language must
> have a value. So, what is a value of "fix id"?

There isn't one!

Bottoms will be the null pointers of the 2010's, you watch.

This ×1000. Errors go in an error monad.

Ben.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[MigMit]

Отправлено с iPhone

Dec 20, 2011, в 7:10, Alexander Solla <[hidden email]> написал(а):

> * Documentation that discourages thinking about bottom as a 'value'.  It's not a value, and that is what defines it.

It's definitely a value.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Gregory Crosswhite]

On Dec 20, 2011, at 8:30 PM, Jesse Schalken wrote:

On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier <[hidden email]> wrote:

On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote:

> In denotational semantics, every well-formed term in the language must
> have a value. So, what is a value of "fix id"?

There isn't one!

Bottoms will be the null pointers of the 2010's, you watch.

This ×1000. Errors go in an error monad.

Including all possible manifestations of infinite loops?

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Ben Lippmeier-2]

> In denotational semantics, every well-formed term in the language must
> have a value. So, what is a value of "fix id"?

There isn't one!

Bottoms will be the null pointers of the 2010's, you watch.

This ×1000. Errors go in an error monad.

Including all possible manifestations of infinite loops?

Some would say that non-termination is a computational effect, and I can argue either way depending on the day of the week.

Of course, the history books show that monads were invented *after* it was decided that Haskell would be a lazy language. Talk about selection bias.

Ben.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Jesse Schalken]

On Tue, Dec 20, 2011 at 9:34 PM, Gregory Crosswhite <[hidden email]> wrote:

On Dec 20, 2011, at 8:30 PM, Jesse Schalken wrote:

On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier <[hidden email]> wrote:

On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote:

> In denotational semantics, every well-formed term in the language must
> have a value. So, what is a value of "fix id"?

There isn't one!

Bottoms will be the null pointers of the 2010's, you watch.

This ×1000. Errors go in an error monad.

Including all possible manifestations of infinite loops?

Definitely.

If you think a value might not reduce, return an error in an error monad. Then the caller is forced to handle the case of an error, or propagate the error upwards. The error can also be handled in pure code this way, whereas bottom can only be handled within the IO monad.

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Gregory Crosswhite]

On Dec 20, 2011, at 8:40 PM, Jesse Schalken wrote:

If you think a value might not reduce, return an error in an error monad.

Okay, I'm completely convinced!  Now all that we have to do is to solve the halting problem to make your solution work...  :-)

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Gregory Crosswhite]

On Dec 20, 2011, at 8:38 PM, Ben Lippmeier wrote:

Some would say that non-termination is a computational effect, and I can argue either way depending on the day of the week.

*shrug*  I figure that whether you call _|_ a value is like whether you accept the Axiom of Choice:  it is a situational decision that depends on what you are trying to learn more about.

Of course, the history books show that monads were invented *after* it was decided that Haskell would be a lazy language. Talk about selection bias.

True, but I am not quite sure how that is relevant to _|_...

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[MigMit]

Отправлено с iPhone

Dec 20, 2011, в 14:40, Jesse Schalken <[hidden email]> написал(а):

On Tue, Dec 20, 2011 at 9:34 PM, Gregory Crosswhite <[hidden email]> wrote:

On Dec 20, 2011, at 8:30 PM, Jesse Schalken wrote:

On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier <[hidden email]> wrote:

On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote:

> In denotational semantics, every well-formed term in the language must
> have a value. So, what is a value of "fix id"?

There isn't one!

Bottoms will be the null pointers of the 2010's, you watch.

This ×1000. Errors go in an error monad.

Including all possible manifestations of infinite loops?

Definitely.

If you think a value might not reduce, return an error in an error monad. Then the caller is forced to handle the case of an error, or propagate the error upwards. The error can also be handled in pure code this way, whereas bottom can only be handled within the IO monad.

So... this imaginary language of yours would be able to solve the halting problem?

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Jesse Schalken]

On Tue, Dec 20, 2011 at 9:47 PM, Gregory Crosswhite <[hidden email]> wrote:

On Dec 20, 2011, at 8:40 PM, Jesse Schalken wrote:

If you think a value might not reduce, return an error in an error monad.

Okay, I'm completely convinced!  Now all that we have to do is to solve the halting problem to make your solution work...  :-)

Why do you have to solve the halting problem?

Consider integer division by 0.

intDiv x y = if y > x then 0 else 1 + (intDiv (x - y) y)

This is correct, but does not reduce with y = 0. The Prelude version returns bottom in this case. Here is a version that returns an error in an Either String.

intDiv :: (Ord a, Num a) => a -> a -> Either String a

intDiv _ 0 = Left "Division by 0!"

intDiv x y = if y > x then Right 0 else intDiv (x - y) y >>= (Right . (1 +))

This is all I was talking about.

 

Cheers,

Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe