# [erlang-questions] problem making my first parser

Roelof Wobben <>
Sat Sep 26 10:18:52 CEST 2015

```Op 26-9-2015 om 10:07 schreef Roelof Wobben:
> Op 26-9-2015 om 09:51 schreef zxq9:
>> On Saturday 26 September 2015 09:31:31 Roelof Wobben wrote:
>>> Op 26-9-2015 om 09:08 schreef zxq9:
>>>> On Saturday 26 September 2015 09:01:30 Roelof Wobben wrote:
>>>>> Why do I then see this error message ?
>>>> What happens if you try `[1] >= \$0, [1] =< \$9.`?
>>>>
>>>> How about `[1] =:= "+".` ?
>>>>
>>>> What are you actually comparing here?
>>> A list with a string/char.   But I check the tail of a list which
>>> contains a char with + or 0 - 9.
>>>
>>>> Do you care about plus signs as strings, or do you care about plus
>>>> as a symbol that represents an operation?
>>> At this point I only care about the plus sign as a string. Later on the
>>> parse function I will make a operation based on this.
>> You care about the plus sign as a token, not a string. There is a
>> difference.
>>
>> What is the difference among the following?
>>
>> scan([H|R], L) when H =:= "+" -> scan(R, [plus|L].
>>
> This one is broken. Apperently you cannot compare this way because a
> string is a list of integers.
>
>> scan([H|R], L) when H =:= \$+ -> scan(R, [H|L]).
>
> This one works fine but can be improved.
>> scan([\$+|R], L) -> scan(R, [fun plus/2|L]).
>
> This one cannot work because when reading the + it's not know what the
> next will be.
>
>
>> Three different ways to decide what you received, and three different
>> ways to continue on. Think about which combination might be most
>> useful to you, and which might be difficult to deal with (or even
>> broken).
>>
>> In other words:
>>    Since you are going to have to deal with the resulting list later,
>> which list will be the easiest to deal with?
>
> The second one mixed with the thirth. like this scan([\$+ | R], L) ->
> scan (R, [\$+ | L]).
>
>> But that is forward thinking about the output. What might be the most
>> useful way to define the *input* that you are going to accept? Maybe
>> "1+1" all crunched together isn't the friendliest way to receive this
>> input? Simple delimitation like "1 + 1" or even "1,+,1" certainly
>> allows more opportunities for "tokenize-or-reject/crash" on bad
>> input. What about the ordering of the symbols? After all "1" is not
>> actually 1, it is a character that represents 1 (hence the conversion
>> from a character to an integer), the same way that neither "+" nor \$+
>> are actually `plus(A, B) -> A + B`.
>>
>> Hm... that's interesting, when writing functions we write
>> function(Thingy1, Thingy2) -- which is not infix notation. So infix
>> "1 + 1" would look like infix "1 plus 1" but converted to a function
>> would look like "plus(1, 1)" which as an S-expression would look like
>> "(plus 1 1)" or "(+ 1 1)", which in Reverse Polish notation would
>> look like "1 1 +" and as a list might look like [1, 1, plus] or
>
> These problem I try to solve in the parse part.
>
>> Why are these notations useful? Why have they been invented? Why do
>> programming languages have functions written like "plus(A, B)" when
>> there are operators like "A + B"?
>>
>> These are not merely philosophic questions. They are central to
>> understanding how notations, grammars, parsing, etc. work.
>>
>> -Craig
>> _______________________________________________
>> erlang-questions mailing list
>>
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> -----
>> Geen virus gevonden in dit bericht.
>> Gecontroleerd door AVG - www.avg.com
>> Versie: 2015.0.6140 / Virusdatabase: 4419/10702 - datum van uitgifte:
>> 09/26/15
>>
>>
>

Finisched the first complete one

-module(number_parser).

-export([scan/1]).

scan(String) ->
scan(String, []).

scan([], List) ->
parse(List);

scan(Rest, [(Head - 48) | List_parse]);

scan([\$+ | Rest], List_parse) ->
scan(Rest, [\$+ | List_parse] );

scan([32 | Rest], List_parse) ->
scan(Rest, List_parse).

parse([Number1, \$+, Number2]) ->
Number1 + Number2;

parse([\$+, Number1, Number2]) ->
Number1 + Number2;

parse([Number1, Number2, \$+]) ->
Number1 + Number2.

Things I still have to think about is how I deal with numbers above the 10.

Roelof

```