Why guess when we could test this? This is a bit of syntax and it has equivalents in other programming languages, so there's no reason in principle why we couldn't just make a multiple choice quiz. Have programmers that haven't ever used Haskell before declare what languages they know, take the quiz, then we see what does and doesn't confuse them.

On Sat, Jun 6, 2015 at 8:29 PM, Anthony Cowley <acowley@seas.upenn.edu> wrote:
On Sat, Jun 6, 2015 at 8:25 PM, Alexander Kjeldaas
<alexander.kjeldaas@gmail.com> wrote:
> On Sat, Jun 6, 2015 at 10:26 AM, Vlatko Basic <vlatko.basic@gmail.com>
> wrote:
>>
>> Maybe a slightly changed syntax like this could be less confusing
>>
>>
>> import Data.Map (Map) andAs M (...)
>>
>> or
>>
>> import Data.Map (Map) and as M (...)
>>
>>
>> It is clear (IMHO) what is coming from where, and both lists are at the
>> end of their part, so can be written nicely in several rows, if needed.
>>
>>
>> import Data.Map (Map)
>>  andAs M (lengthy,
>>           list)
>>
>> Parser can also easily distinguish between the current and the new syntax
>> so they can coexist, so no backward compatibility problem.
>>
>
>
> I much prefer a syntax with a bit more words, like this one.  The original
> proposal is simply impossible to understand without reading a manual.  It
> has at least two equally valid interpretations.
>
> Adding one or two words like in this examples makes it possible, without
> reading a manual, to distinguish between possible interpretations.  I think
> that must be a minimal requirement for such a syntax extension.  Nobody
> needs to hire a language lawyer to understand a python import statement.
> That shouldn't be needed for Haskell either.
>
> Alexander

Thanks for the feedback, Vlatko, Alexander, and Kosyrev! I would like
the syntax to avoid being overly hostile to newcomers, so some tweaks
are certainly possible.

So that I understand, you believe that a newcomer could read

import Data.Map (Map) andAs M (lengthy)

and infer which names are qualified and which aren't without
consulting a manual, whereas without the "and" it would be "impossible
to understand"? I confess I find that hard to believe, but I'll bear
it in mind in case this option picks up wider support. There are
already three of you on board, so it's off to a good start.

Anthony
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



--
Chris Allen
Currently working on http://haskellbook.com