Possible to update Haskell syntax

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

Possible to update Haskell syntax

cm
I'm very interested in learning Haskell, but one frustration is that lists
always require commas.  As an example [1,2,3,4] is a valid expression, but
[1 2 3 4] is not.

In this ideal world, another example would be that [(fun1 3 4) 7] would be a
valid expression and be a two-element list equivalent to [fun1 3 4, 7].

If what I am suggesting is syntactically possible and doesn't break more
advanced features of the language that I (as a beginner) am unaware of, I'm
interested in patching the open source for my own use (as well as others who
might want it).

Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Steven Ashley
Hi cm,

An ambiguity arises when you have a list containing functions. For
instance consider:

fmap ($3) [id id id id]

Cheers,

Steven


2008/11/23 cm <[hidden email]>:

> I'm very interested in learning Haskell, but one frustration is that lists
> always require commas.  As an example [1,2,3,4] is a valid expression, but
> [1 2 3 4] is not.
>
> In this ideal world, another example would be that [(fun1 3 4) 7] would be a
> valid expression and be a two-element list equivalent to [fun1 3 4, 7].
>
> If what I am suggesting is syntactically possible and doesn't break more
> advanced features of the language that I (as a beginner) am unaware of, I'm
> interested in patching the open source for my own use (as well as others who
> might want it).
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/beginners
>
Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Brent Yorgey-2
In general, the point is that there is already a 'whitespace operator'
in Haskell corresponding to function application.  So it would be
ambiguous for whitespace to also indicate separation of list elements.

Also, I rarely need to write explicit lists of any length, so I think
you will find that having to write an explicit comma in between
elements is not that much of an annoyance.

With all that said, you may also find the new 'quasiquoting'
functionality in GHC 6.10.1 to be of interest.  Quasiquoting allows
you to specify arbitrary parsers for specially quoted strings.  In
particular, you could implement a list quasiquoter so that you could
write something like

  [ls| 1 2 3 4 |]

which could parse to the list [1,2,3,4].  I haven't had a chance to
play around with the quasiquoting stuff myself yet, however, so I
don't have a good idea of how difficult this would be.

-Brent

On Sun, Nov 23, 2008 at 06:00:17PM +1300, Steven Ashley wrote:

> Hi cm,
>
> An ambiguity arises when you have a list containing functions. For
> instance consider:
>
> fmap ($3) [id id id id]
>
> Cheers,
>
> Steven
>
>
> 2008/11/23 cm <[hidden email]>:
> > I'm very interested in learning Haskell, but one frustration is that lists
> > always require commas.  As an example [1,2,3,4] is a valid expression, but
> > [1 2 3 4] is not.
> >
> > In this ideal world, another example would be that [(fun1 3 4) 7] would be a
> > valid expression and be a two-element list equivalent to [fun1 3 4, 7].
> >
> > If what I am suggesting is syntactically possible and doesn't break more
> > advanced features of the language that I (as a beginner) am unaware of, I'm
> > interested in patching the open source for my own use (as well as others who
> > might want it).
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://www.haskell.org/mailman/listinfo/beginners
> >
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Brandon S Allbery KF8NH
On 2008 Nov 24, at 12:12, Brent Yorgey wrote:
> In general, the point is that there is already a 'whitespace operator'
> in Haskell corresponding to function application.  So it would be
> ambiguous for whitespace to also indicate separation of list elements.


The other generality I'd add is that Haskell isn't Scheme, and it's  
best to get used to it.  (Although there is Liskell if you're feeling  
weird.)

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Tillmann Rendel-2
In reply to this post by cm
cm wrote:
> In this ideal world, another example would be that [(fun1 3 4) 7] would
> be a valid expression and be a two-element list equivalent to [fun1 3 4,
> 7].

But [(fun1 1 3 4) 7] already is a valid expression, equivalent to [(fun1
1 3 4 7)] and [fun1 1 3 4 7]. The "whitespace operator" can have only
one meaning.

Haskell, being a functional language, makes function application as easy
as possible. Lisp, being a list processing language, makes construction
of lists as easy as possible.

   Tillmann
cm
Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

cm
The logic of making "function application as easy as possible" in Haskell is
compelling, yet I can't help but wonder if an alternate context dependent
syntax would be desribable?  Specifically, when inside a pair of brackets
make construction of lists as easy as possible as opposed giving priority to
functions.

There was an earlier reply also about mapping of a "$" construct, but I
don't quite understand that issue yet.

I appreciate the answers by Haskell experts to my somewhat unusual question.

----- Original Message -----
From: "Tillmann Rendel" <[hidden email]>
To: "cm" <[hidden email]>
Cc: <[hidden email]>
Sent: Tuesday, November 25, 2008 3:10 AM
Subject: Re: [Haskell-beginners] Possible to update Haskell syntax


> cm wrote:
>> In this ideal world, another example would be that [(fun1 3 4) 7] would
>> be a valid expression and be a two-element list equivalent to [fun1 3 4,
>> 7].
>
> But [(fun1 1 3 4) 7] already is a valid expression, equivalent to [(fun1 1
> 3 4 7)] and [fun1 1 3 4 7]. The "whitespace operator" can have only one
> meaning.
>
> Haskell, being a functional language, makes function application as easy
> as possible. Lisp, being a list processing language, makes construction of
> lists as easy as possible.
>
>   Tillmann
>

Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Tillmann Rendel-2
cm wrote:
> The logic of making "function application as easy as possible" in
> Haskell is compelling, yet I can't help but wonder if an alternate
> context dependent syntax would be desribable?  Specifically, when inside
> a pair of brackets make construction of lists as easy as possible as
> opposed giving priority to functions.

I guess that would be possible, but there are some technical problems,
e.g. what to do with binary operators. Would [a + b c] mean [(+) a (b
c)], [(+) a b, c], [a, (+), b, c], [a, (+), b c] or something else?
Currently, it means the first of these choices.

However, I don't see why it would be a good idea. The obvious
disadvantage is making the syntax more complicated, and more fragile.
For example, you no longer could move an expression inside a brackets
while refactoring your code.

Regarding possible advantages: Do you have a specific use case in mind,
which could be written easier or cleaner with this list syntax?

   Tillmann
cm
Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

cm
From: "Tillmann Rendel" <[hidden email]>
[...]
>
> However, I don't see why it would be a good idea. The obvious disadvantage
> is making the syntax more complicated, and more fragile. For example, you
> no longer could move an expression inside a brackets while refactoring
> your code.
>
> Regarding possible advantages: Do you have a specific use case in mind,
> which could be written easier or cleaner with this list syntax?

I would just like as simple an input syntax as possible (minimum of
punctuation) for interactive use, for both lists and tuples.  For instance,
if all entries in a list or tuple are numbers, then I think eliminating the
commas would be convenient and look nicer.

As a use case, one might have
  " permute (2 3 4) [7 9 11 0 1 5]", which would be a function which
cyclically permutes elements 2 3 4 of a list.

Regarding your question of what [a + b c] in "altered consciousness syntax"
would resolve to in real world Haskell, it would be [a, (+), b, c].  [(a +
b) c] would resolve to [a + b, c].  The rule would be that whitespace inside
a bracket becomes a comma delimiter.  If there are parentheses inside the
bracket, then the expression inside the parentheses reverts to normal
syntax.

These are probably not workable ideas.  I'm just annoyed by extra
punctuation which I consider to be visual clutter.



Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Brent Yorgey-2
On Tue, Nov 25, 2008 at 09:09:47PM -0800, cm wrote:

> From: "Tillmann Rendel" <[hidden email]>
> [...]
>>
>> However, I don't see why it would be a good idea. The obvious disadvantage
>> is making the syntax more complicated, and more fragile. For example, you
>> no longer could move an expression inside a brackets while refactoring
>> your code.
>>
>> Regarding possible advantages: Do you have a specific use case in mind,
>> which could be written easier or cleaner with this list syntax?
>
> I would just like as simple an input syntax as possible (minimum of
> punctuation) for interactive use, for both lists and tuples.  For instance,
> if all entries in a list or tuple are numbers, then I think eliminating the
> commas would be convenient and look nicer.

I can probably count on one hand the number of times I've had to
literally type in an explicit list of more than three or four elements
-- mostly because Haskell has so many easy ways to algorithmically
construct lists (list comprehensions, Prelude functions like
filter, map, unfoldr, replicate, repeat, etc.).  But I can see how
this would be annoying when doing certain things.

Why not use a lightweight custom list-parser function? Something like this:

  l = map read . words

Then you could type
 
  permute (2,3,4) (l "7 9 11 0 1 5")

which is still a little extra clutter, but surely much nicer than
typing all the commas.

-Brent
Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Michael Snoyman
In reply to this post by cm
On Tue, Nov 25, 2008 at 9:09 PM, cm <[hidden email]> wrote:

> I would just like as simple an input syntax as possible (minimum of
> punctuation) for interactive use, for both lists and tuples.  For instance,
> if all entries in a list or tuple are numbers, then I think eliminating the
> commas would be convenient and look nicer.
>
> As a use case, one might have
>  " permute (2 3 4) [7 9 11 0 1 5]", which would be a function which
> cyclically permutes elements 2 3 4 of a list.
>

You might be interested in this article I saw on variadic functions in
Haskell: http://okmij.org/ftp/Haskell/vararg-fn.lhs. The first example shows
how you could create a build function to create a list.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20081126/ed64a00b/attachment.htm
cm
Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

cm
Thanks to Tillman Rendel for describing some of the philosphy behind Haskell syntax and for Brent Yorgey and Michael Snoyman for suggesting how the Haskell language itself could be used to produce a cleaner input syntax.  The multi-variable input functions are definitely of interest (but I have to understand how they work).

On another line of thought, I've always liked the syntax of the old PostScript language.  It then ocurred to me to search on the words "haskell postfix notation", and, naturally, someone in the Haskell world has considered this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20081126/176e4937/attachment.htm
Reply | Threaded
Open this post in threaded view
|

Possible to update Haskell syntax

Brandon S Allbery KF8NH
On 2008 Nov 26, at 15:27, cm wrote:
> On another line of thought, I've always liked the syntax of the old  
> PostScript language.  It then ocurred to me to search on the words  
> "haskell postfix notation", and, naturally, someone in the Haskell  
> world has considered this.

Have you ever looked at Forth?

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20081127/42981e15/attachment.htm