Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Writing a Parser with attoparsec that reads from a list of
tokens (Norbert Melzer)
2. parser frontend (Maurizio Vitale)
3. Re: Writing a Parser with attoparsec that reads from a list
of tokens (Henk-Jan van Tuyl)
4. Re: Writing a Parser with attoparsec that reads from a list
of tokens (Benjamin Edwards)
5. Re: Maybe and Just (Joel Neely)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Mar 2015 13:31:03 +0100
From: Norbert Melzer <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: [Haskell-beginners] Writing a Parser with attoparsec that
reads from a list of tokens
Message-ID:
<ca+bcvsuc6f2zm3vb8ac0s27tob1knydnmuodpc8pca2xekj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi there!
I want to write some small toy language using attoparsec.
So I thought, first step tokenize. Let attoparsec consume the input stream
and produce a list of tokens.
Second step, parse tokens and produce the AST.
Using parsec this would be possible easily and is documented. But I want to
use attoparsec for this task, because I am interested in attoparsecs
capability to have the input in chunks.
TIA
Norbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150327/032053f4/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 27 Mar 2015 09:38:50 -0400
From: Maurizio Vitale <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: [Haskell-beginners] parser frontend
Message-ID:
<caaelbq+42zh3srhgvc5e6xgif5zp1vprx5m_npsvu57zguq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
G'day,
I'm trying to decide how to architect the frontend of a compiler I'm
using as an excuse for learning Haskell.
Suppose we have a language (SystemVerilog) that has the notion of
multi-file compilation units.
This means that specific subset of files form separate scopes for certain
things.
For instance if we represent with lists of lists compilation units:
[[a,b,c], [d], [e,f]]
a macro definition in file b, would affect the rest of the file and file c,
but wouldn't have effect on files d,e or a.
Furthermore, if a toplevel construct is split between two files, say c and
d, the compiler should treat the original compilation unit specification as
if it was:
[[a,b,(c,d)][e,f]], where (c,d) means we're compiling the logical
concatenation of c and d.
If (c,d) is also incomplete, (c,d,e) should be tried and so on.
Now in well designed systems, all files can actually be compiled in
parallel and so I'd like to optimize for that case and recompile files
(either because we need side effects from files before them or because
they're incomplete. So I'm not to concerned if wasted work is done for the
degenerate cases.
Any suggestion on how to go about this?
Le's assume that parsing a file is done with a function:
p :: file -> Either Error (ast, [defs], [use]) where the [defs] are things
that might affects files down the line and [use] are things that, if
defined by some prior file, cause recompilation.
I'm interested in both a sequential and parallel solution and it would be
sweet if they where similar, with the proper abstractions.
Thanks a lot for any insight/ideas,
Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150327/e7f1e63b/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 27 Mar 2015 16:08:45 +0100
From: "Henk-Jan van Tuyl" <[email protected]>
To: "The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell" <[email protected]>,
"Norbert Melzer" <[email protected]>
Subject: Re: [Haskell-beginners] Writing a Parser with attoparsec that
reads from a list of tokens
Message-ID: <op.xv5wc0b4pz0j5l@alquantor>
Content-Type: text/plain; charset=iso-8859-15; format=flowed;
delsp=yes
On Fri, 27 Mar 2015 13:31:03 +0100, Norbert Melzer <[email protected]>
wrote:
> Hi there!
>
> I want to write some small toy language using attoparsec.
>
> So I thought, first step tokenize. Let attoparsec consume the input
> stream
> and produce a list of tokens.
> Second step, parse tokens and produce the AST.
>
> Using parsec this would be possible easily and is documented. But I want
> to
> use attoparsec for this task, because I am interested in attoparsecs
> capability to have the input in chunks.
You can use the list of reverse dependencies for attoparsec
http://packdeps.haskellers.com/reverse/attoparsec
to find usage examples.
Regards,
Henk-Jan van Tuyl
--
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://folding.stanford.edu/
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
------------------------------
Message: 4
Date: Fri, 27 Mar 2015 15:20:37 +0000
From: Benjamin Edwards <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>,
Norbert Melzer <[email protected]>
Subject: Re: [Haskell-beginners] Writing a Parser with attoparsec that
reads from a list of tokens
Message-ID:
<can6k4ng7rnnub5zk0m0phevt2hjv_m3aupydw_ouycciafp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The thing is you can write parsers for tokens, then write parsers that
consume those tokens by exclusively using the token parsers as the building
blocks rather than the raw steam, all using the same combinators and
mechanisms. This is much more flexible.
Ben
On Fri, 27 Mar 2015 at 15:08 Henk-Jan van Tuyl <[email protected]> wrote:
> On Fri, 27 Mar 2015 13:31:03 +0100, Norbert Melzer <[email protected]>
> wrote:
>
> > Hi there!
> >
> > I want to write some small toy language using attoparsec.
> >
> > So I thought, first step tokenize. Let attoparsec consume the input
> > stream
> > and produce a list of tokens.
> > Second step, parse tokens and produce the AST.
> >
> > Using parsec this would be possible easily and is documented. But I want
> > to
> > use attoparsec for this task, because I am interested in attoparsecs
> > capability to have the input in chunks.
>
> You can use the list of reverse dependencies for attoparsec
> http://packdeps.haskellers.com/reverse/attoparsec
> to find usage examples.
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Folding@home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150327/b9f420e8/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 27 Mar 2015 14:01:56 -0500
From: Joel Neely <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Maybe and Just
Message-ID:
<CAEEzXAiSY4_5q7NACWU2s_cfr-Nx95Wy8iT1f1Xc=khtkgl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Shishir,
Would I be right to guess that you're coming from an OO background? If so,
I'd suggest thinking about the difference between declaring a constructor
and invoking it.
I suggest that you can read the Haskell declaration
data Maybe tp = Just tp | Nothing
as declaring ?a data type and specifying two constructors that can return
an instance (in the OO sense of the word) of that data type. But when the
expression
Just "FOO"
is invoking one of those constructors on a value of type String, so the
resulting value has type Maybe String.
Because Maybe is an instance of Show (in the Haskell sense of the word),
there's a show function that can be applied to that value to produce
something that looks like the line above. That's roughly equivalent to
having a toString method on a Java class that returns a string that looks
like a constructor call that could produce the actual object.
-jn-
On Fri, Mar 27, 2015 at 5:14 AM, Shishir Srivastava <
[email protected]> wrote:
> Thanks Corentin. I think it makes more sense now that you've mentioned the
> fact that '*Just*' in the type definition of '*Maybe*' is only a *tag*.
>
> So would it be correct to re-define Maybe data type as follows -
>
> data Maybe tp = Justin tp | Nothing
>
> and then create the type value of *Maybe *as -
>
> *Just 3*
>
> *?*
>
>
>
> Shishir Srivastava
> +44 (0) 750 127 5019
>
>
> On Fri, Mar 27, 2015 at 10:05 AM, Corentin Dupont <
> [email protected]> wrote:
>
>>
>> You're right, "Just" is used at two different levels, it's just that it
>> have the same name is both cases.
>> One is at type level, the other at value level.
>> Since this is two separated levels, there is no risk of confusion and
>> having the same name is fine.
>>
>> To be clear, you can write:
>>
>> data Maybe = Just Int | Nothing
>>
>> Then use it as:
>>
>> my_value = Just 3
>>
>> It the first case, "Just" is a tag in the type definition, in the second
>> case it's a function constructing a value.
>> They just happen to have the same name (a choice of Haskell language).
>>
>>
>> On Fri, Mar 27, 2015 at 10:44 AM, Shishir Srivastava <
>> [email protected]> wrote:
>>
>>> Sorry, but I still have some grudges so to say with the way 'Maybe' is
>>> defined.
>>>
>>> By definition '*Maybe*' takes a type parameter which I will denote here
>>> as '*tp*' for the sake of clarity like below -
>>>
>>> data Maybe tp = Just tp | Nothing
>>>
>>> Therefore '*tp*' is not representing a value perse such as '3' or 'XYZ'
>>> etc but a data type such as '*Int*', '*Char*' etc.
>>>
>>> But when we have to create a data type of '*Maybe*' we write '*Just 3*'
>>> and not '*Just Int*' or '*Just Char*' which is how it's defined in the
>>> definition (i.e. '*Just tp*' ) .
>>>
>>> It is this discrepancy in definition and the actual value creation which
>>> is slightly troubling me.
>>>
>>> Thanks,
>>> Shishir
>>>
>>> Shishir Srivastava
>>> +44 (0) 750 127 5019
>>>
>>>
>>> On Thu, Mar 26, 2015 at 5:31 PM, Corentin Dupont <
>>> [email protected]> wrote:
>>>
>>>> Not really, when you define the type "Maybe a":
>>>>
>>>> data Maybe a = Just a | Nothing
>>>>
>>>> Haskell is creating automatically two functions for you:
>>>>
>>>> Just :: a -> Maybe a
>>>> Nothing :: Maybe a
>>>>
>>>> In the first case, you can think of "Just" and "Nothing" as a sort of
>>>> tag identifying which element of the sum you have.
>>>> It the second case it's a function, with the same name.
>>>> A more informed person than me could say if they are indeed separated
>>>> of if they are the same thing in GHC...
>>>>
>>>>
>>>> On Thu, Mar 26, 2015 at 5:34 PM, Shishir Srivastava <
>>>> [email protected]> wrote:
>>>>
>>>>> isn't that then cyclic dependency between 'Maybe' and 'Just' ...where
>>>>> the first one is defined in terms of second and vice-versa...?
>>>>>
>>>>> Shishir
>>>>>
>>>>>
>>>>> On Thu, Mar 26, 2015 at 3:48 PM, Corentin Dupont <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Shishir,
>>>>>> I think that's a legitimate question.
>>>>>>
>>>>>> By writing
>>>>>>
>>>>>> data Maybe a = a | Nothing
>>>>>>
>>>>>> you are saying that the type of the left hand side of the = is the
>>>>>> same that right hand side (you are defining a type basically).
>>>>>> Also you can only sum things of the same type.
>>>>>> So you are saying:
>>>>>> type "Maybe a" = type "a"
>>>>>> Which is wrong.
>>>>>> That's why "a" should be wrapped into something:
>>>>>> type of "Just a" is indeed "Maybe a".
>>>>>>
>>>>>> "Just" is a type constructor:
>>>>>> Just :: a -> Maybe a
>>>>>> It allows you to build the Maybe.
>>>>>>
>>>>>> Said that, "Just" is a vocabulary choice.
>>>>>> Personally I prefer the name choices of OCaml, Rust, Scala etc.:
>>>>>> Option a = None | Some a
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 26, 2015 at 4:26 PM, Shishir Srivastava <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> ok..but what's with using the keyword 'Just' ? why cannot 'Maybe' be
>>>>>>> defined like this
>>>>>>>
>>>>>>> data Maybe a = a | Nothing
>>>>>>>
>>>>>>> what's the point in having 'Just' keyword ?
>>>>>>>
>>>>>>> Shishir
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 26, 2015 at 10:26 AM, Michael Alan Dorman <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Shishir Srivastava <[email protected]> writes:
>>>>>>>> > After reading and re-reading the haskell tutorials I don't happen
>>>>>>>> to
>>>>>>>> > see a very convincing or appealing reason for having these data
>>>>>>>> > types.
>>>>>>>>
>>>>>>>> To be clear: Maybe is the data *type*. Just and Nothing are its
>>>>>>>> data
>>>>>>>> *constructors*.
>>>>>>>>
>>>>>>>> > Can anyone please explain where Maybe and Just provide the sort of
>>>>>>>> > functionality that cannot be achieved in other languages which
>>>>>>>> don't
>>>>>>>> > have these kind.
>>>>>>>>
>>>>>>>> The functionality can be achieved in other languages, certainly.
>>>>>>>> The
>>>>>>>> question is whether the clarity and safety is also achieved.
>>>>>>>>
>>>>>>>> When I see (as a totally contrived example):
>>>>>>>>
>>>>>>>> fopen :: Maybe FileHandle
>>>>>>>>
>>>>>>>> I know that that function may not be able to return a FileHandle
>>>>>>>> value
>>>>>>>> all the time. The compiler will, in fact, nag me if I do not write
>>>>>>>> the
>>>>>>>> code that calls it in such a way that it acknowledges that
>>>>>>>> possibility.
>>>>>>>>
>>>>>>>> When I see:
>>>>>>>>
>>>>>>>> FILE * fopen ( const char * filename, const char * mode );
>>>>>>>>
>>>>>>>> It is not immediately clear whether that can fail. Sure, we can
>>>>>>>> make
>>>>>>>> that inference, based on what we know about filesystems, etc., but
>>>>>>>> the
>>>>>>>> compiler is never going to complain if I ignore the possibility.
>>>>>>>>
>>>>>>>> In my experience, programmers in many languages end up resorting to
>>>>>>>> convention to try and work around these sorts of ambiguities. Large
>>>>>>>> projects have strategies for naming functions that try to pass along
>>>>>>>> information out of band, or languages have a pervasive culture of
>>>>>>>> "lint"
>>>>>>>> tools that try to use heuristics to make up for what the type system
>>>>>>>> doesn't make simple.
>>>>>>>>
>>>>>>>> That said, I know that doing Maybe sorts of things in languages that
>>>>>>>> don't have, say, pattern matching, or the idea of a "failure monad",
>>>>>>>> gets to be a drag very quickly---manually unwrapping things is at
>>>>>>>> best
>>>>>>>> awkward, having to re-wrap them just to unwrap them again in a
>>>>>>>> sequence
>>>>>>>> of computations quickly leads one to believe "it's just not worth
>>>>>>>> it"---or you resort to exception handling, which has its own
>>>>>>>> challenges
>>>>>>>> to do well.
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Beginners mailing list
>>>>>>> [email protected]
>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
--
Beauty of style and harmony and grace and good rhythm depend on simplicity.
- Plato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150327/04700875/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 81, Issue 69
*****************************************
