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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
99 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

Alexander Solla


On Tue, Dec 20, 2011 at 1:46 AM, 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!


Indeed, that is my point.  "Bottom" is the representation of a computation which cannot be computed.  It does not have a semantic in anything less than the first infinite ordinal.  It should be treated as essentially unique.  It exists as a syntactic construct, but it cannot be given an interpretation in Haskell.

In particular, we cannot compare "distinct" (or even indistinct) bottoms, because of the halting problem.  There is no consistent logic in which (forall x, x = x) does not hold.  Treating bottom the same way we treat 1, "abc", (Just 10), and the other (in principle) comparable values introduces contradiction to Haskell, as a logic.  (That is why bottom has the syntactic symbol _|_, the syntax for /the/ unique contradiction)

Denotational semantics is nice, but it goes way out of the realm of realistic computation to deal with infinite ordinals just to have a complete semantic.  (We can't run computations even up to the first infinite ordinal in real life)

I would rather have an incomplete semantic, and have all the incomplete parts collapsed into something we call "bottom".  We can then be smart and stay within a total fragment of the language (where bottom is guaranteed to not occur).  Or we may have to move into the non-total fragment of the language for performance reasons.  That's fine, but we shouldn't treat things like 'seq' as if they produce values.  'seq', 'unsafeCoerce', and many others are literally compiler magic, and as such, should be used with extreme care not warranted when dealing with "regular" values.

I have used the phrase "proto-value" for describing these magical objects.  I just wish the documentation made the distinction between a "proto-value" and a real value more clear.


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

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

MigMit

On 21 Dec 2011, at 08:24, Alexander Solla wrote:

> I would rather have an incomplete semantic, and have all the incomplete parts collapsed into something we call "bottom".

I don't see the reason to limit ourselves to that. Of course, in total languages like Agda there is no need for (_|_). But in a turing-complete lazy language like Haskell we really need it. Of course, it makes not much sense to write "fix id" anywhere in your program; but, for example, lists like "1:2:3:4:5:_|_" can be really useful.

And denotational semantics is not just nice. It is useful. It's the best way to understand why the program we just wrote doesn't terminate.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Gregory Crosswhite
In reply to this post by scooter.phd@gmail.com
<base href="x-msg://2168/">
On Dec 21, 2011, at 2:14 PM, [hidden email] wrote:

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. 

I super-agree with you on this point;  just because something is modeled by a particular mathematical structure doesn't mean that it should be named *after* that structure unless said structure is a commonly known one.  In a programming language names should be chosen to maximize clarity, and the term "Monad" conveys absolutely no sense of what it is to anyone who isn't already well-versed in category theory.

I would go further and say that there is a problem in a lot of the documentation surrounding such concepts as Monads which is that they start with a mathematical definition --- i.e., a type with a return and bind method --- and then proceed from there, which obfuscates what Monads are all about.  It would be much better of a typical tutorial instead started by describing what problem exists that they solve.


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.

Honest question here:  what exactly do you mean by being "relegated to Scala status"?  Scala seems pretty alive and kicking to me, with the added bonus that it runs on the JVM which gives it an advantage in many respects over Haskell.  Is there something I am mising?  :-)

Cheers,
Greg

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

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

Gregory Crosswhite
In reply to this post by Alexander Solla

On Dec 21, 2011, at 2:24 PM, Alexander Solla wrote:

I would rather have an incomplete semantic, and have all the incomplete parts collapsed into something we call "bottom".  We can then be smart and stay within a total fragment of the language (where bottom is guaranteed to not occur).

But part of the whole point of including bottom in our semantics in the first place is *exactly* to *enable* us to be smart enough to know when we are staying within a total fragment of the language.  For example, including bottom in our semantics allows us to make and prove statements like

fst (42,_|_) = 42

and

fst _|_ = _|_

That is, as long a you know that the pair is total and that the first element is total, calling fst on it is also total regardless of whether the second value is total.

Refusing to use bottom in our semantics doesn't make life better by forcing us to stay within a total fragment of the language, it actually makes life harder by removing from us a useful tool for knowing *how* to stay within a total fragment of the language.

Cheers,
Greg

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

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

Jason Dusek
In reply to this post by Robert Clausecker
Support for long binary data sections would be nice.

--
Jason Dusek
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

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 21, 2011, at 8:52 AM, Jesse Schalken wrote:

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. ;) 

Okay, then suffice it to say that most of what you said *is* implemented in real languages like Coq and Agda so you should check them out.  :-)  Unfortunately there are two hurdles one faces when using these languages:  first, it is often very cumbersome to actually prove all of the invariants you want to prove to make your code total, and second, there is not yet a nice way of doing I/O actions and/or interfacing with external libraries written in other languages.

However, until we have solved the problems that make working entirely in dependently-typed languages a pain, we will need to stick with languages with weaker type systems like Haskell, which means that we can't get around _|_ since we cannot encode all of our invariants into the type system.

Incidentally, I would highly recommend learning more about Coq and Agda.  There is a great textbook to start from available here:


It is valuable because it is not Coq-specific but rather is a good general introduction to, exactly as the title promises, certified programming with dependent types.

You should also really check out Agda;  the main difference between it and Coq is the language in which proofs are written.  To make a long story short, in Coq proofs are often easier to write because they use a specialized language for that purpose but this often makes them a bit of a black box, whereas in Agda the proofs are fully explicit which makes them much more transparent but also more verbose and often harder to write.  Unfortunately the documentation for Agda tends to be sparse and split over several kinds of documents (such as theses, papers, etc.) so isn't an obvious guide for me to recommend to you, but if you look around you should find enough information to get you started.  The home page is


For me part of the most exciting part was reading through the Agda standard libraries, which you can download from


Just reading through their code is enlightening because it shows you just how much power is available from dependent types;  the standard library also covers a lot more than Coq's does.  Unfortunately it also showcases one of the limitations of Agda, which is things can often get cryptic and arcane very quickly, especially since Agda makes you work with "universes" explicitly (Coq handles them implicitly) which adds another layer of complexity.  :-)  (FYI, the universes are a hierarchy such that values are at the bottom, types of values one rung up, types of types two rungs up, types of types of types three rungs up, etc.  Haskell is limited in only having a three-level hierarchy, with values, types, and kinds.)

Cheers,
Greg

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

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

Hans Aberg-2
In reply to this post by Brandon Allbery
On 21 Dec 2011, at 04:15, Brandon Allbery wrote:

> 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.
> http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#unicode-syntax
>
> (≠ 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 one on the list is not a mathematical symbol. It should be ⋆ STAR OPERATOR U+22C6 or ∗ ASTERISK OPERATOR U+2217.

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

There is
  http://www.stixfonts.org/
For typesetting with Xe[La]TeX or Lua[La]TeX, use XITS (in the TeXLive package).

> (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.)

This is the big problem right now: how to enter these symbols efficiently.

Hans



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

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

Hans Aberg-2
In reply to this post by Ashok Gautham-4
On 21 Dec 2011, at 04:27, Ashok Gautham wrote:

> 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

I have some books from the 1980s which does not use monospace; it seems to be a later movement. Using it for all symbols would be awkward.

Hans



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

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

Brandon Allbery
In reply to this post by Hans Aberg-2
On Wed, Dec 21, 2011 at 04:51, Hans Aberg <[hidden email]> wrote:
The one on the list is not a mathematical symbol. It should be ⋆ STAR OPERATOR U+22C6 or ∗ ASTERISK OPERATOR U+2217.

...except, at least in my current font, the former is microscopic and the latter not a whole lot better. The advantage of the one they chose is it's big and readable.  (That's part of why I assume it's intended for kinds, actually.)

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

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

Jesse Schalken
In reply to this post by Hans Aberg-2
IIRC, Scite's default configuration is with non-monospace font. I actually found it quite appealing, and in fact forgot about it entirely after some usage. It is much easier on the eyes to read. The difference is really whether you care about aligning things mid-line or not, not to mention editor support (i.e. not Vim or other terminal-based editor).

On Wed, Dec 21, 2011 at 8:58 PM, Hans Aberg <[hidden email]> wrote:
On 21 Dec 2011, at 04:27, Ashok Gautham wrote:

> 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

I have some books from the 1980s which does not use monospace; it seems to be a later movement. Using it for all symbols would be awkward.

Hans



_______________________________________________
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
|

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

Hans Aberg-2
In reply to this post by Brandon Allbery
On 21 Dec 2011, at 11:03, Brandon Allbery wrote:

> On Wed, Dec 21, 2011 at 04:51, Hans Aberg <[hidden email]> wrote:
>> The one on the list is not a mathematical symbol. It should be ⋆ STAR OPERATOR U+22C6 or ∗ ASTERISK OPERATOR U+2217.
>>
> ...except, at least in my current font, the former is microscopic and the latter not a whole lot better. The advantage of the one they chose is it's big and readable.  (That's part of why I assume it's intended for kinds, actually.)

This problem is in my editor for unstyled text due to that if it a symbol is not available in the font selected, it just chooses a glyph from the next font available in alphabetical order.

Hopefully such problem will be resolved in the future.

Hans



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

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

Andrew Coppin
In reply to this post by Robert Clausecker
On 19/12/2011 07:20 PM, 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?

1. Remove special treatment for lists.

That is, remove the standard list type from the Prelude and make it into
just another container library. The type is trivially definable; it
doesn't need to be hard-wired into the language. I would name it "List"
rather than "[]" too, and give its constructors sensible names rather
than ":" and "[]".

I would also make the current literal list syntax overloaded, so it can
be used to construct any type of container. (Much the way numeric
literals are overloaded.)

2. Add special treatment for arrays.

That is, have strict, unboxed arrays hard-wired into the language. For
every user type, not just ones which are members of a special type.
Fully parametric. You know, like how they are in almost every other
programming language known to Man, except Haskell. Also, the base array
library would have zero-based integer indicies, and if you want
arbitrary index values, that would be a library on top. Also, primitives
for fast copying of array chunks.

3. Fix the Typeclassopedia.

By which I mean things like removing "fail" from Monad, making
Applicative a superclass of Monad, etc. You know, the usual stuff
everybody complains about for being horribly broken.

4. Do something sane with the numerical classes.

Unfortunately, this one is a Hard Problem. I doubt you can "solve" this
without rampant language changes. But it should be possible to /improve/
on what exists currently.

5. Miscelaneous consistency changes.

Haskell has a number of minor glitches which are irritating though not
catastrophic. Things like type signatures being allowed in expressions
but not patterns. Value constructors can be operators, but type
constructors cannot. Negation is the only unary operator. And so forth.
Nothing radical here.

6. Experimental stuff.

I have a number of other, more radical ideas, but I probably wouldn't
put those in, because the resulting language would be so drastically
different that it wouldn't be "Haskell" any more. (That said, most of
the stuff above would pretty much be hard breaking changes...)

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

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

Gregory Crosswhite
In reply to this post by Heinrich Apfelmus

On Dec 20, 2011, at 11:18 PM, Heinrich Apfelmus wrote:

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

I am not disagreeing with anything that you have said here, but in a way it seems like the problem is more fundamental than all of these things since metaprogramming and type-programming in Haskell is not first-class, so it really isn't a language that is designed for DSLs even though people get a surprisingly long way abusing it for this purpose.  :-)  Really what we need is a language built from the ground up for this purpose, such as Lisp, but without the parts of Lisp that cause us to use Haskell instead.  :-)

Cheers,
Greg

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

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

Andrew Coppin
In reply to this post by Jesse Schalken
On 21/12/2011 10:09 AM, Jesse Schalken wrote:
> IIRC, Scite's default configuration is with non-monospace font. I
> actually found it quite appealing, and in fact forgot about it entirely
> after some usage. It is much easier on the eyes to read. The difference
> is really whether you care about aligning things mid-line or not, not to
> mention editor support (i.e. not Vim or other terminal-based editor).

SciTE's default binding /is/ proportional, not mono-space. I find it
ever so irritating. Then again, I'm sure this one comes squarely down to
personal preference, so it seems pointless to debate it.

LaTeX offers the possibility of mid-line alignment even if you don't use
monospace - a feature which I haven't seen in any other text processing
system. It's a pitty this isn't more widespread...

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

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

Hans Aberg-2
In reply to this post by Jesse Schalken
On 21 Dec 2011, at 11:09, Jesse Schalken wrote:

> IIRC, Scite's default configuration is with non-monospace font. I actually found it quite appealing, and in fact forgot about it entirely after some usage. It is much easier on the eyes to read. The difference is really whether you care about aligning things mid-line or not, not to mention editor support (i.e. not Vim or other terminal-based editor).

Right, ASCII code that relies on monospace for such midline alignments can be quite unreadable, but otherwise it has nothing really to contribute. Non-monospace might in fact be more readable, taking away the fact that it may take some time to get used to it, since monospace has been used so much.

For such alignments, one would either to write to code so it does not depend on it, or find some other means to do it.

Hans

> On Wed, Dec 21, 2011 at 8:58 PM, Hans Aberg <[hidden email]> wrote:
> On 21 Dec 2011, at 04:27, Ashok Gautham wrote:
>
> > 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
>
> I have some books from the 1980s which does not use monospace; it seems to be a later movement. Using it for all symbols would be awkward.
>
> Hans



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

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

Hans Aberg-2
In reply to this post by Andrew Coppin
On 21 Dec 2011, at 11:22, Andrew Coppin wrote:

> On 21/12/2011 10:09 AM, Jesse Schalken wrote:
>> IIRC, Scite's default configuration is with non-monospace font. I
>> actually found it quite appealing, and in fact forgot about it entirely
>> after some usage. It is much easier on the eyes to read. The difference
>> is really whether you care about aligning things mid-line or not, not to
>> mention editor support (i.e. not Vim or other terminal-based editor).
>
> SciTE's default binding /is/ proportional, not mono-space. I find it ever so irritating. Then again, I'm sure this one comes squarely down to personal preference, so it seems pointless to debate it.
>
> LaTeX offers the possibility of mid-line alignment even if you don't use monospace - a feature which I haven't seen in any other text processing system. It's a pitty this isn't more widespread...

Monospace isn't used in math (except in the days when one used typewriters), but alignments are of course used in matrices and multiline formulas, for example, which may correspond to uses in computer code.

A problem is that LaTeX is used for rendering typeset pages, and not really suitable for writing direct computer code, though Unicode characters can improve the readability of LaTeX source code. The link below shows an example.

Hans


http://www.charlietanksley.net/philtex/the-unicode-math-package-for-xelatex-and-the-stix-fonts/



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

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

Ivan Perez
In reply to this post by Robert Clausecker
In general, I like haskell the way it is, but there are a few things
that I would like to see:
(I am no language designer, so I don't know about the theoretical
implications that these
might have. Also, let me know if there exists a clean way to do any of
the following):

- Using subranges of instances of Ord in type definitions, a la Ada.
For instance, saying:

type MyNumber = [2..6]

(maybe "data MyNumber" would be more appropriate, I don't know).

I really don't want to have to write
data MyNumber = Two | Three | Four | Five | Six
and implement all the necessary operations for them.

- Guards wherever I want, for instance:

myFunction = do
  monadicRes <- monadicOp
  | monadicRes == 1 || monadicRes == 7 = doA
  | monadicRes == 6 || monadicRes == 8 = doB
  | otherwise = doC

This is easily avoidable with an aux function, but sometimes there's just
too many variables in the conditions and you don't want to carry them
all in the aux function's signature. I could (painfully) live with

myFunction = do
  monadicRes <- monadicOp
  if monadicRes == 1 || monadicRes == 7
  then doA
  elseif monadicRes == 6 || monadicRes == 8
  then doB
  else doC

even though it's way too verbose and reminds me of java.

I often end up finding that the following construction is cleaner than
the possible alternatives:

myFunction = do
  monadicRes <- monadicOp
  case () of
   _ | monadicRes == 1 || monadicRes == 7 = doA
      | monadicRes == 6 || monadicRes == 8 = doB
      | otherwise = doC

even though it's very ugly to have those useless () _ there.

Unfortunately, my proposal could give way to slightly ugly nested guards
(which are cleaner than nested ifs, but not very nice anyway).
myFunction arg
  | arg == 1
    | arg == 7 = doA
    | arg == 8 = doB
  | otherwise = doC

- Function overloading without classes. If it's not done, there must
be a good reason for it
(many good reasons, probably), but I really miss it.

Most other features I need, such as easy-to-use nested-record access
methods, my own deriving definitions, compile-time expansion of
expressions, etc. are covered by existing libraries and extensions.

I really have no problems with the monad/functor separation that
somebody mentioned.
Maybe Monad is not the best name for that class if it's not true that
every Monad is a
Functor, but it's not very confusing anyway.

Cheers,
Ivan

On 19 December 2011 20:20, 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
Reply | Threaded
Open this post in threaded view
|

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

Robert Clausecker


Am 21.12.2011 14:10 schrieb "Ivan Perez" <[hidden email]>:
>
> In general, I like haskell the way it is, but there are a few things
> that I would like to see:
> (I am no language designer, so I don't know about the theoretical
> implications that these
> might have. Also, let me know if there exists a clean way to do any of
> the following):
>
> - Using subranges of instances of Ord in type definitions, a la Ada.
> For instance, saying:
>
> type MyNumber = [2..6]
>
> (maybe "data MyNumber" would be more appropriate, I don't know).
>
> I really don't want to have to write
> data MyNumber = Two | Three | Four | Five | Six
> and implement all the necessary operations for them.
>
> - Guards wherever I want, for instance:
>
> myFunction = do
>  monadicRes <- monadicOp
>  | monadicRes == 1 || monadicRes == 7 = doA
>  | monadicRes == 6 || monadicRes == 8 = doB
>  | otherwise = doC
>
> This is easily avoidable with an aux function, but sometimes there's just
> too many variables in the conditions and you don't want to carry them
> all in the aux function's signature. I could (painfully) live with
>
> myFunction = do
>  monadicRes <- monadicOp
>  if monadicRes == 1 || monadicRes == 7
>  then doA
>  elseif monadicRes == 6 || monadicRes == 8
>  then doB
>  else doC
>
> even though it's way too verbose and reminds me of java.
>
> I often end up finding that the following construction is cleaner than
> the possible alternatives:
>
> myFunction = do
>  monadicRes <- monadicOp
>  case () of
>   _ | monadicRes == 1 || monadicRes == 7 = doA
>      | monadicRes == 6 || monadicRes == 8 = doB
>      | otherwise = doC
>
> even though it's very ugly to have those useless () _ there.
>
> Unfortunately, my proposal could give way to slightly ugly nested guards
> (which are cleaner than nested ifs, but not very nice anyway).
> myFunction arg
>  | arg == 1
>    | arg == 7 = doA
>    | arg == 8 = doB
>  | otherwise = doC
>
> - Function overloading without classes. If it's not done, there must
> be a good reason for it
> (many good reasons, probably), but I really miss it.

That does not play well with type inference. Also, see type-directed name resolution (TDNR)
> Most other features I need, such as easy-to-use nested-record access
> methods, my own deriving definitions, compile-time expansion of
> expressions, etc. are covered by existing libraries and extensions.
>
> I really have no problems with the monad/functor separation that
> somebody mentioned.
> Maybe Monad is not the best name for that class if it's not true that
> every Monad is a
> Functor, but it's not very confusing anyway.
>
> Cheers,
> Ivan
>
> On 19 December 2011 20:20, 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
Reply | Threaded
Open this post in threaded view
|

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

Ivan Perez
>> - Function overloading without classes. If it's not done, there must
>> be a good reason for it
>> (many good reasons, probably), but I really miss it.
>
> That does not play well with type inference.

I understand that. But it may be ok in many simple situations,
which is actually where I tend to "need" it. For instance,
the following wouldn't pose a problem, would it?

f  :: Int -> Int -> Int
f = (+)
f :: String -> String -> String
f = (++)

(Not that I would use it for exactly that code, but anyway).
I know that one can write that with classes and instances, but I just
want to save myself the extra-coding when possible. In complex
situations (where it doesn't play well with type inference), that's
when I'd rather create classes and instances. Not for the type-checker,
but for myself.

> Also, see type-directed name resolution (TDNR)
Thanks for that pointer. I found that proposal a few months ago, but had
completely forgotten about it.

I don't really like the proposed syntax; it's very OO-like.
I agree with gabrielrf, who said "[...] I wonder if adding an obj.method
style will be a hinderance to beginners, as it obscures what type
inference can do."

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

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

Robert Clausecker
Am Mittwoch, den 21.12.2011, 20:05 +0100 schrieb Ivan Perez:

> >> - Function overloading without classes. If it's not done, there must
> >> be a good reason for it
> >> (many good reasons, probably), but I really miss it.
> >
> > That does not play well with type inference.
>
> I understand that. But it may be ok in many simple situations,
> which is actually where I tend to "need" it. For instance,
> the following wouldn't pose a problem, would it?
>
> f  :: Int -> Int -> Int
> f = (+)
> f :: String -> String -> String
> f = (++)
>
>(Not that I would use it for exactly that code, but anyway).
> I know that one can write that with classes and instances, but I just
> want to save myself the extra-coding when possible. In complex
> situations (where it doesn't play well with type inference), that's
> when I'd rather create classes and instances. Not for the
type-checker,
> but for myself.

Of course it would! Consider the following code:

    g = f

What is the type of g? Without a typeclass, the compiler is unable to
give a proper type to g since it can't decide between the two matching
instances of f. Of course this example is ridiculous, but similiar but
more convoluted specimens of this problem arise often in production
code.

You may now think: "Hey, why can't the compiler just automatically
generate a typeclass for me in such a case?" This is impossible, since
the compiler can't see your intentions. It can't decide what the
type-variable should be etc. Consider again your f example. You expect
the compiler to generate a typeclass like this:

    class Foo a where
      f :: a -> a -> a

But how can the compiler see that what you want is actually the above
and not the equally sensible typeclass

    class Bar a where
      f :: a

You see, it's not so easy with type-inference. AFAIK TDNR solves this
problem by requiring the first argument to have a monomorphic type. This
type is used to pick an appropriate function. I dislike this approach;
it is too limited in my opinion. The problem is, that you have much more
information about a function in traditional languages, than in Haskell.
Consider this slightly trivial example:

    Java:    x = something(a,obj.toString(),2);
    Haskell: x = something a (show obj) 2

In Java, the compiler knows a lot about the method something from that
single line:

      * something() has three arguments
      * The type of the first argument is known
      * The second argument is a String
      * The third one is an int

In Haskell, most of these assumptions are invalid:

      * something may be curried or member of a strange typeclass (like
        printf). No assumptions about the number of arguments can be
        made
      * It may be possible that we do not yet know the type of a because
        we can't infer it's type without knowing the type of x
      * show obj is definitely a String
      * 2 is of type Num a => a. What if there are two something, one
        with a parameter of type Int and one with a Float?

You see, It's not so easy.

> > Also, see type-directed name resolution (TDNR)
> Thanks for that pointer. I found that proposal a few months ago, but had
> completely forgotten about it.
>
> I don't really like the proposed syntax; it's very OO-like.
> I agree with gabrielrf, who said "[...] I wonder if adding an obj.method
> style will be a hinderance to beginners, as it obscures what type
> inference can do."

Full acknowledge.


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