Quantcast

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

classic Classic list List threaded Threaded
99 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gregory Crosswhite

On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote:

Why do you have to solve the halting problem?

You have to solve the halting problem if you want to replace every place where _|_ could occur with an Error monad (or something similar), because _|_ includes occasions when functions will never terminate.

Consider integer division by 0.  [...]
This is all I was talking about.

But imagine there was an occasion where you *knew* that the divisor was never zero --- say, because the divisor was constructed to be a natural number.  Now there is no point in running in the Error monad because there will never such a runtime error;  in fact, it is not clear what you would even *do* with a Left value anyway, short of terminating the program and printing and error, which is what would have happened anyway.  Furthermore, it is easy to imagine circumstances where you have now forced your entire program to run in the Error monad, which makes everything incredibly inconvenient with no benefit at all.

This is the problem with arguments against partial functions;  they don't solve any problems at all except in the case where you have untrusted data in which case you should be using a different function or manually checking it anyway, and they add a lot of wasted overhead.

Cheers,
Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ben Lippmeier-2
In reply to this post by Gregory Crosswhite

On 20/12/2011, at 21:52 , Gregory Crosswhite 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.

I agree, but I'd like to have more control over my situation. Right now we have boxed and lifted Int, and unboxed and unlifted Int#, but not the boxed and unlifted version, which IMO is usually what you want.


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 _|_...

I meant to address the implicit question "why doesn't Haskell use monads to describe non-termination already". The answer isn't necessarily "because it's not a good idea", it's because "that wasn't an option at the time".


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

Including all possible manifestations of infinite loops?

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

All type systems are incomplete. The idea is to do a termination analysis, and if the program can not be proved to terminate, then it is marked as "possibly non-terminating". This isn't the same as deciding something is "*definitely* non-terminating", which is what the halting problem is about. This "possibly non-terminating" approach is already used by Coq, Agda and other languages.

Ben.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Heinrich Apfelmus
In reply to this post by Tillmann Rendel-5
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.

I think this is a very good point. The things I would like to see:

* Better syntax for observable sharing. Doaitse Swierstra proposed a
"grammer" construct that is basically a  let  statement where the binder
names can be observed. I'm not entirely sure whether that is the most
general or sufficient syntax, but something along these lines.

* Meta-programming / partial evaluation. When designing a DSL, it is
often the case that you know how to write an optimizing compiler for
your DSL because it's usually a first-order language. However, trying to
squeeze that into GHC rules is hopeless. Having some way of compiling
code at run-time would solve that. Examples:
** Conal Elliott's image description language Pan
** Henning Thielemann's synthesizer-llvm



Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jesse Schalken
In reply to this post by Gregory Crosswhite
On Tue, Dec 20, 2011 at 10:43 PM, Gregory Crosswhite <[hidden email]> wrote:

On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote:

Why do you have to solve the halting problem?

You have to solve the halting problem if you want to replace every place where _|_ could occur with an Error monad (or something similar), because _|_ includes occasions when functions will never terminate.

I think we're talking about different things. By "bottom" I mean the function explicitly returns "error ..." or "undefined". In those cases, it should go in an error monad instead. In cases where there is an infinite loop, the function doesn't return anything because it never finishes, and indeed this separate problem will never be solved while remaining Turing complete because it is the halting problem.
 

Consider integer division by 0.  [...]
This is all I was talking about.

But imagine there was an occasion where you *knew* that the divisor was never zero --- say, because the divisor was constructed to be a natural number.

Then use a separate type for natural numbers excluding 0. Then you can define a total integer division function on it (although the return value may be zero and so needs a different type).
 
Now there is no point in running in the Error monad because there will never such a runtime error;  in fact, it is not clear what you would even *do* with a Left value anyway, short of terminating the program and printing and error, which is what would have happened anyway.

What you do with a Left value is up to you - that's the point, you now have a choice. In fact, the value might not even be being handled by you, in which case someone else now has a choice.  Handling of the error is done in the same place as handling of the result, no IO needed.
 
Furthermore, it is easy to imagine circumstances where you have now forced your entire program to run in the Error monad, which makes everything incredibly inconvenient with no benefit at all.

This "inconvenience" I imagine is the extra code required to compose functions which return values in a monad as opposed to straight values. To me this is a small price to pay for knowing my code won't randomly crash, and I would rather this be handled syntactically to make composing monadic values more concise.

The point is your program shouldn't be able to make assumptions about values without proving them with types. It's often easier not to make the assumption and propagate some error in an error monad instead, but that's better than getting away with the assumption and having the program crash or behave erratically because the assumption turned out false.

This is the problem with arguments against partial functions;  they don't solve any problems at all except in the case where you have untrusted data in which case you should be using a different function or manually checking it anyway, and they add a lot of wasted overhead.

The whole term "untrusted data" baffles me. How often can you actually "trust" your data? When you send your software out into the wild, what assumptions can you make about its input? What assumptions can you make about the input to a small part of a larger program which is millions of lines? You can often deduce that certain values do/do not occur in small parts of code, but the difficulty of such deductions increases exponentially with the size of the codebase, and is a job done much better by a type system.

Also I would like to think this "wasted overhead" can be optimised away at some stage of compilation, or somehow removed without the programmer needing to think about it. Maybe I'm just dreaming on those fronts, however.

Cheers,
Greg


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Thiago Negri
What I think to be the hard part to do is to put this on the type system, e.g.:

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

Should not compile. Otherwise you will need the bottom value.

Am I missing something?

Thiago.


2011/12/20 Jesse Schalken <[hidden email]>:

> On Tue, Dec 20, 2011 at 10:43 PM, Gregory Crosswhite <[hidden email]>
> wrote:
>>
>>
>> On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote:
>>
>> Why do you have to solve the halting problem?
>>
>>
>> You have to solve the halting problem if you want to replace every place
>> where _|_ could occur with an Error monad (or something similar), because
>> _|_ includes occasions when functions will never terminate.
>
>
> I think we're talking about different things. By "bottom" I mean the
> function explicitly returns "error ..." or "undefined". In those cases, it
> should go in an error monad instead. In cases where there is an infinite
> loop, the function doesn't return anything because it never finishes, and
> indeed this separate problem will never be solved while remaining Turing
> complete because it is the halting problem.
>
>>
>>
>> Consider integer division by 0.  [...]
>> This is all I was talking about.
>>
>>
>> But imagine there was an occasion where you *knew* that the divisor was
>> never zero --- say, because the divisor was constructed to be a natural
>> number.
>
>
> Then use a separate type for natural numbers excluding 0. Then you can
> define a total integer division function on it (although the return value
> may be zero and so needs a different type).
>
>>
>> Now there is no point in running in the Error monad because there will
>> never such a runtime error;  in fact, it is not clear what you would even
>> *do* with a Left value anyway, short of terminating the program and printing
>> and error, which is what would have happened anyway.
>
>
> What you do with a Left value is up to you - that's the point, you now have
> a choice. In fact, the value might not even be being handled by you, in
> which case someone else now has a choice.  Handling of the error is done in
> the same place as handling of the result, no IO needed.
>
>>
>> Furthermore, it is easy to imagine circumstances where you have now forced
>> your entire program to run in the Error monad, which makes everything
>> incredibly inconvenient with no benefit at all.
>
>
> This "inconvenience" I imagine is the extra code required to compose
> functions which return values in a monad as opposed to straight values. To
> me this is a small price to pay for knowing my code won't randomly crash,
> and I would rather this be handled syntactically to make composing monadic
> values more concise.
>
> The point is your program shouldn't be able to make assumptions about values
> without proving them with types. It's often easier not to make the
> assumption and propagate some error in an error monad instead, but that's
> better than getting away with the assumption and having the program crash or
> behave erratically because the assumption turned out false.
>
>> This is the problem with arguments against partial functions;  they don't
>> solve any problems at all except in the case where you have untrusted data
>> in which case you should be using a different function or manually checking
>> it anyway, and they add a lot of wasted overhead.
>
>
> The whole term "untrusted data" baffles me. How often can you actually
> "trust" your data? When you send your software out into the wild, what
> assumptions can you make about its input? What assumptions can you make
> about the input to a small part of a larger program which is millions of
> lines? You can often deduce that certain values do/do not occur in small
> parts of code, but the difficulty of such deductions increases exponentially
> with the size of the codebase, and is a job done much better by a type
> system.
>
> Also I would like to think this "wasted overhead" can be optimised away at
> some stage of compilation, or somehow removed without the programmer needing
> to think about it. Maybe I'm just dreaming on those fronts, however.
>
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gregory Crosswhite
In reply to this post by Jesse Schalken

On Dec 20, 2011, at 11:21 PM, Jesse Schalken wrote:

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

On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote:

Why do you have to solve the halting problem?

You have to solve the halting problem if you want to replace every place where _|_ could occur with an Error monad (or something similar), because _|_ includes occasions when functions will never terminate.

I think we're talking about different things. By "bottom" I mean the function explicitly returns "error ..." or "undefined". In those cases, it should go in an error monad instead. In cases where there is an infinite loop, the function doesn't return anything because it never finishes, and indeed this separate problem will never be solved while remaining Turing complete because it is the halting problem.

Then honestly you should choose a different term because I am pretty certain that my use of the term "bottom" is the commonly accepted one which (among other places) appears in denotation semantics.


Consider integer division by 0.  [...]
This is all I was talking about.

But imagine there was an occasion where you *knew* that the divisor was never zero --- say, because the divisor was constructed to be a natural number.

Then use a separate type for natural numbers excluding 0. Then you can define a total integer division function on it (although the return value may be zero and so needs a different type).

That would certainly be a lovely idea *if* we were programming in Agda, but I was under the assumption that this conversation was about Haskell.  :-)

 
Now there is no point in running in the Error monad because there will never such a runtime error;  in fact, it is not clear what you would even *do* with a Left value anyway, short of terminating the program and printing and error, which is what would have happened anyway.

What you do with a Left value is up to you - that's the point, you now have a choice.

Yes, but it is a pointless choice because if you had any reason to believe that your value was an invalid input to a function you would have checked it by now or used an alternative non-partial function that did run in an Error monad for that specific purpose.

In fact, the value might not even be being handled by you, in which case someone else now has a choice.  Handling of the error is done in the same place as handling of the result, no IO needed.

Yes, but all that the user of your library knows at this point is that there is a bug somewhere in your library that violated an invariant.  Nearly all of the time there is no way to recover from this in a useful way and so all the user will end up doing in response to your Left value is to abort anyway.

The point is your program shouldn't be able to make assumptions about values without proving them with types.

I agree but, again, we aren't talking about Agda here, we are talking about Haskell.  :-)

The whole term "untrusted data" baffles me. How often can you actually "trust" your data?

All the time!  For example, if I create a counter that starts at 1, only increase it, and give nobody else access to it, then I can be as certain as it is possible to be can be that it is not 0.

Also, there are occasionally times when I essentially check that a Maybe value is Just in one part of the code, and then in another part of the code need to extract the value from the Just;  in such cases there is no point in using method *other* than simply fromJust to extract the value.

(Of course, it would be better to have condensed all of this into a single case statement in the first place, but sometimes --- say, when interfacing with others' libraries --- this ends up not being an available option.)

When you send your software out into the wild, what assumptions can you make about its input?

None, which is why in that case you need to test your input in that case.

Also I would like to think this "wasted overhead" can be optimised away at some stage of compilation, or somehow removed without the programmer needing to think about it.

I was thinking in terms of overhead from the coder's point of view, not from the compiler's point of view.

Cheers,
Greg

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Fox-7
In reply to this post by Robert Clausecker
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

One thing that concerns me is the use of capital letters to distinguish type and class names and constructors from values.  If I was doing it over I would use a typographical distinction like italics for types, bold for classes.  That way we could have a constructor named ∅, a function named ∈, a class named ℝ.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Wong
> One thing that concerns me is the use of capital letters to distinguish type
> and class names and constructors from values.  If I was doing it over I
> would use a typographical distinction like italics for types, bold for
> classes.  That way we could have a constructor named ∅, a function named ∈,
> a class named ℝ.

It's Algol all over again! Will we have to typeset our keywords in bold too?

> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Strake
In reply to this post by David Fox-7
With GHC 7.0.3:

$ cat test.hs
class ℝ a where {
  test :: a;
};

(∈) :: Eq a => a -> [a] -> Bool;
x ∈ (y:ys) = x == y || x ∈ ys;

main = putStrLn "Two of three ain't bad (^_~)";
$ runhaskell test.hs
Two of three ain't bad (^_~)
$

On 20/12/2011, David Fox <[hidden email]> wrote:

> 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
>>
>
> One thing that concerns me is the use of capital letters to distinguish
> type and class names and constructors from values.  If I was doing it over
> I would use a typographical distinction like italics for types, bold for
> classes.  That way we could have a constructor named ∅, a function named ∈,
> a class named ℝ.
>


Cheers,
Matthew Farkas-Dyck

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hans Aberg-2
In reply to this post by Chris Wong
On 20 Dec 2011, at 22:51, Chris Wong wrote:

>> One thing that concerns me is the use of capital letters to distinguish type
>> and class names and constructors from values.  If I was doing it over I
>> would use a typographical distinction like italics for types, bold for
>> classes.  That way we could have a constructor named ∅, a function named ∈,
>> a class named ℝ.
>
> It's Algol all over again! Will we have to typeset our keywords in bold too?

There are in fact Unicode symbols for that, see
  http://unicode.org/charts/PDF/U1D400.pdf
The monospace characters U+1D670-1D6A3 might be used for keywords. Font:
  http://www.stixfonts.org/

Not hard to add.

Hans



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jesse Schalken
In reply to this post by Gregory Crosswhite


On Wed, Dec 21, 2011 at 1:09 AM, Gregory Crosswhite <[hidden email]> wrote:

On Dec 20, 2011, at 11:21 PM, Jesse Schalken wrote:

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

On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote:

Why do you have to solve the halting problem?

You have to solve the halting problem if you want to replace every place where _|_ could occur with an Error monad (or something similar), because _|_ includes occasions when functions will never terminate.

I think we're talking about different things. By "bottom" I mean the function explicitly returns "error ..." or "undefined". In those cases, it should go in an error monad instead. In cases where there is an infinite loop, the function doesn't return anything because it never finishes, and indeed this separate problem will never be solved while remaining Turing complete because it is the halting problem.

Then honestly you should choose a different term because I am pretty certain that my use of the term "bottom" is the commonly accepted one which (among other places) appears in denotation semantics.


I apologize if I was using the wrong terminology. I've seen "error ..." shown as, and understood it to be, _|_, but it seems _|_ refers to either a value that does not reduce or Haskell's "error" function depending on the context.

Consider integer division by 0.  [...]
This is all I was talking about.

But imagine there was an occasion where you *knew* that the divisor was never zero --- say, because the divisor was constructed to be a natural number.

Then use a separate type for natural numbers excluding 0. Then you can define a total integer division function on it (although the return value may be zero and so needs a different type).

That would certainly be a lovely idea *if* we were programming in Agda, but I was under the assumption that this conversation was about Haskell.  :-)


I don't have experience with proof assistants, but maybe my answer to this thread can be summed up as giving Haskell that kind of capability. ;) 
 
Now there is no point in running in the Error monad because there will never such a runtime error;  in fact, it is not clear what you would even *do* with a Left value anyway, short of terminating the program and printing and error, which is what would have happened anyway.

What you do with a Left value is up to you - that's the point, you now have a choice.

Yes, but it is a pointless choice because if you had any reason to believe that your value was an invalid input to a function you would have checked it by now or used an alternative non-partial function that did run in an Error monad for that specific purpose.

In fact, the value might not even be being handled by you, in which case someone else now has a choice.  Handling of the error is done in the same place as handling of the result, no IO needed.

Yes, but all that the user of your library knows at this point is that there is a bug somewhere in your library that violated an invariant.  Nearly all of the time there is no way to recover from this in a useful way and so all the user will end up doing in response to your Left value is to abort anyway.

What if for example the program is a server which is always running. If you use "error ...", the server will crash, and someone has to go start it up again. The person who wrote the server has to remember to wrap each request in a try...catch block in the IO monad in the outer layer to make sure the server doesn't crash due to errors in pure code. What if they forget? If you use an error monad, they can't forget, because the type system forces them to handle the error. Maybe they will choose to "exit" in the case of an error, but at least then the program is crashing because they've explicitly told it to rather than because they forgot something. More likely they will respond to the request with an "error" response, allowing the server to continue running, but either way the type system has forced them to make a decision.


The point is your program shouldn't be able to make assumptions about values without proving them with types.

I agree but, again, we aren't talking about Agda here, we are talking about Haskell.  :-)

Now I really want to look at proof assistants!
 

The whole term "untrusted data" baffles me. How often can you actually "trust" your data?

All the time!  For example, if I create a counter that starts at 1, only increase it, and give nobody else access to it, then I can be as certain as it is possible to be can be that it is not 0.

Start your counter at 0 then. Then if you really don't want to deal with 0, treat 0 as 1 and 1 as 2 etc - hence a type for non-zero naturals. I think structuring code such that the types you use contain no useless or impossible values is often easy with a little thought, and worth it because the compiler is now verifying the assumptions you made. In cases where that isn't possible (or you can't be bothered), I'd rather just propagate an error in a monad than resort to Haskell's "error ..." for above reasons.
 
Also, there are occasionally times when I essentially check that a Maybe value is Just in one part of the code, and then in another part of the code need to extract the value from the Just;  in such cases there is no point in using method *other* than simply fromJust to extract the value.

If you checked that a Maybe is a Just, then continued to pass on the Maybe to a function which assumed it is Just, then you should have just passed on the value in the Just instead. If it's Maybe, you must handle Nothing. If you've already handled Nothing, it doesn't make sense to keep dealing with a Maybe.
 

(Of course, it would be better to have condensed all of this into a single case statement in the first place, but sometimes --- say, when interfacing with others' libraries --- this ends up not being an available option.)

When you send your software out into the wild, what assumptions can you make about its input?

None, which is why in that case you need to test your input in that case.

Also I would like to think this "wasted overhead" can be optimised away at some stage of compilation, or somehow removed without the programmer needing to think about it.

I was thinking in terms of overhead from the coder's point of view, not from the compiler's point of view.

Cheers,
Greg


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Brandon Allbery
On Tue, Dec 20, 2011 at 17:52, Jesse Schalken <[hidden email]> wrote:
On Wed, Dec 21, 2011 at 1:09 AM, Gregory Crosswhite <[hidden email]> wrote:
That would certainly be a lovely idea *if* we were programming in Agda, but I was under the assumption that this conversation was about Haskell.  :-)

I don't have experience with proof assistants, but maybe my answer to this thread can be summed up as giving Haskell that kind of capability. ;) 

You want to look at Agda:  a proof assistant language whose syntax is similar to Haskell, and which supports dependent types and the like.

--
brandon s allbery                                      [hidden email]
wandering unix systems administrator (available)     (412) 475-9364 vm/sms


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Wong
In reply to this post by Strake
On Wed, Dec 21, 2011 at 10:53 AM, Matthew Farkas-Dyck
<[hidden email]> wrote:

> With GHC 7.0.3:
>
> $ cat test.hs
> class ℝ a where {
>  test :: a;
> };
>
> (∈) :: Eq a => a -> [a] -> Bool;
> x ∈ (y:ys) = x == y || x ∈ ys;
>
> main = putStrLn "Two of three ain't bad (^_~)";
> $ runhaskell test.hs
> Two of three ain't bad (^_~)
> $

Why not expand it even further?

class Monoid m where
    (•) :: m -> m -> m
    (∅) :: m

(∈) :: (Foldable t, Eq a) => a -> t a -> Bool

(∘) :: (b -> c) -> (a -> b) -> (a -> c)

(∧) :: Bool -> Bool -> Bool

etc.

We can write a whole Haskell library full of these aliases --
"syntactic-heroin" perhaps? ;)

(http://www.haskell.org/haskellwiki/Syntactic_sugar/Cons#Syntactic_heroin)

> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Erik de Castro Lopo-34
In reply to this post by Miguel Mitrofanov
MigMit wrote:

> Dec 20, 2011, в 14:40, Jesse Schalken <[hidden email]> написал(а):
>
> > 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?

Depends on what you mean "solve" the halting problem.

Agda and Coq are two languages that will only compile programs that
can be proven to terminate. Non terminating programs are rejected.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martin DeMello
In reply to this post by Chris Wong
On Tue, Dec 20, 2011 at 3:10 PM, Chris Wong
<[hidden email]> wrote:

>
> Why not expand it even further?
>
> class Monoid m where
>    (•) :: m -> m -> m
>    (∅) :: m
>
> (∈) :: (Foldable t, Eq a) => a -> t a -> Bool
>
> (∘) :: (b -> c) -> (a -> b) -> (a -> c)
>
> (∧) :: Bool -> Bool -> Bool
>
> etc.
>
> We can write a whole Haskell library full of these aliases --
> "syntactic-heroin" perhaps? ;)

Why would you go that far and still not have → ? (:

martin

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Andrew Cowie
In reply to this post by Strake
On Tue, 2011-12-20 at 16:53 -0500, Matthew Farkas-Dyck wrote:
> Two of three ain't bad (^_~)

Now we just need λ to replace \, → to replace ->, and ≠ to replace /=
(which still looks like division assignment no matter how hard I squint
my eyes. 25 years of C and C derived languages is hard to forget).

Hey, forget replacing, wouldn't it be wonderful if the compiler would
just accept them as synonyms?

AfC
Sydney



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Brandon Allbery
On Tue, Dec 20, 2011 at 21:05, Andrew Cowie <[hidden email]> wrote:
Now we just need λ to replace \, → to replace ->, and ≠ to replace /=
(which still looks like division assignment no matter how hard I squint
my eyes. 25 years of C and C derived languages is hard to forget).

Some of it is already supported.

(≠ isn't in that list, but it doesn't need to be; just stick it in the Prelude if it's not there already, since it's not special syntax, it's just another operator.  The * *is* a special case, I suspect, though:  I bet it's only supported in kinds, not as the multiplication operator.)

The problem with λ is that it's a perfectly valid Unicode lowercase letter.  There is 𝛌
MATHEMATICAL BOLD SMALL LAMDA U+1D6CC but font support is often lacking, and it looks like Unicode categorizes *that* also as a lowercase letter.  If you can convince the Unicode Consortium to add a lambda that is of class symbol, Haskell can then make use of it — once there are fonts that support it.  (And then we'll have to deal with folks trying to use the letter, because everyone knows the Roman alphabet is the only one that matters and of *course* Greek letters are symbol characters....  Pfeh.)

--
brandon s allbery                                      [hidden email]
wandering unix systems administrator (available)     (412) 475-9364 vm/sms


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ashok Gautham-4
In reply to this post by Hans Aberg-2
On Tue, Dec 20, 2011 at 11:17:32PM +0100, Hans Aberg wrote:
> The monospace characters U+1D670-1D6A3 might be used for keywords. Font:
>   http://www.stixfonts.org/

I feel that monospace fonts should be used for all of programming. A
language could use Unicode symbols, but if it enforces typography, it
is destined to win an award for being really unusable

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

scooter.phd@gmail.com
In reply to this post by Andrew Cowie
I'd suggest, in addition to the symbols, renaming some of the fundamental types and concepts, like Monad. I would violently agree that Monad is the correct term, but try to communicate with a commodity software developer sometime (or a government acquisition professional). RWH goes a long way to explaining the concepts, as do the countless Web pages dedicated to explaining the monad concept.

Better examples for SYB and arrows would also help.

Haskell is a great language with solid mathematical underpinnings. I'm a big fan of it. But, adoption is the key to success; need to make the ordinary easy to understand unless the community wants to be relegated to Scala status.


-----Original message-----
From: Andrew Cowie <[hidden email]>
To:
[hidden email]
Sent:
Tue, Dec 20, 2011 18:05:18 PST
Subject:
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?

On Tue, 2011-12-20 at 16:53 -0500, Matthew Farkas-Dyck wrote:
> Two of three ain't bad (^_~)

Now we just need λ to replace \, → to replace ->, and ≠ to replace /=
(which still looks like division assignment no matter how hard I squint
my eyes. 25 years of C and C derived languages is hard to forget).

Hey, forget replacing, wouldn't it be wonderful if the compiler would
just accept them as synonyms?

AfC
Sydney



_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

scooter.phd@gmail.com
In reply to this post by Andrew Cowie
I'd suggest, in addition to the symbols, renaming some of the fundamental types and concepts, like Monad. I would violently agree that Monad is the correct term, but try to communicate with a commodity software developer sometime (or a government acquisition professional). RWH goes a long way to explaining the concepts, as do the countless Web pages dedicated to explaining the monad concept.

Better examples for SYB and arrows would also help.

Haskell is a great language with solid mathematical underpinnings. I'm a big fan of it. But, adoption is the key to success; need to make the ordinary easy to understand unless the community wants to be relegated to Scala status.


-----Original message-----
From: Andrew Cowie <[hidden email]>
To:
[hidden email]
Sent:
Tue, Dec 20, 2011 18:05:18 PST
Subject:
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?

On Tue, 2011-12-20 at 16:53 -0500, Matthew Farkas-Dyck wrote:
> Two of three ain't bad (^_~)

Now we just need λ to replace \, → to replace ->, and ≠ to replace /=
(which still looks like division assignment no matter how hard I squint
my eyes. 25 years of C and C derived languages is hard to forget).

Hey, forget replacing, wouldn't it be wonderful if the compiler would
just accept them as synonyms?

AfC
Sydney



_______________________________________________
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
12345
Loading...