[Haskell-cafe] Proposal: Shorter Import Syntax

Vlatko Basic vlatko.basic at gmail.com
Sat Jun 6 08:26:25 UTC 2015


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.


br,
vlatko


-------- Original Message  --------
Subject: Re: [Haskell-cafe] Proposal: Shorter Import Syntax
From: Malcolm Wallace <malcolm.wallace at me.com>
To: haskell-cafe <haskell-cafe at haskell.org>
Date: 05/06/15 07:52

> I agree with everything Richard says here.  Not only is the proposed syntax bad, but I don't see any good motivation for the general idea of making minor tweaks to the imports section.  I don't find it at all annoying to use a couple of lines to be completely explicit about which names are always qualified, which are optionally qualified, and the qualifier to use; and indeed I am a heavy user of the 'as' form, both with and without 'qualified'.
>
> I think there is a burden on the proposer to demonstrate a decent power-to-weight ratio for the change, and saving a few characters at the expense of introducing considerable confusion just does not seem right to me.  "The new syntax does not let us do anything we cannot do now."  On the other hand, I could imagine a different import system altogether being attractive, perhaps a higher-order one like ML modules, although someone would have to flesh out the details.
>
> Regards,
>      Malcolm
>
>> On 5 Jun 2015, at 05:23, "Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
>>
>>
>>> On 4/06/2015, at 5:15 am, Anthony Cowley <acowley at seas.upenn.edu> wrote:
>>> The idea is that rather than writing,
>>>
>>> import Data.Map (Map)
>>> import qualified Data.Map as M
>>>
>>> you could instead write,
>>>
>>> import Data.Map (Map) as M
>>
>> This puts the list (Map) in the wrong place.
>> You know how in English, "heavy" parts of a sentence go at the end?
>> The "heavy" part of an import declaration is the impspec.
>>
>>> The Map identifier would imported unqualified, while M would be
>>> introduced as an alias for the qualified import of Data.Map.
>>
>> I find that confusing.  I expected it to mean that
>> only Data.Map.Map would be available and that it would
>> have to be referred to as M.Map.  The core problem is
>> that this is a bit too close to English syntax, where
>> the placement of "as M" after (Map) suggests that it
>> refers to (Map), rather than to Data.Map.
>>
>> The new syntax does not let us do anything we cannot do now.
>>
>> It is also asking too much to ask people to distinguish
>> between
>>
>> import Full as Local (thingy)  --  current
>> import Full (thingy) as Local  --  proposed
>>
>> Whatever its faults, the current scheme at least makes
>> it obvious that 'as Local' refers to 'Full', not '(thingy)'.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>


More information about the Haskell-Cafe mailing list