[erlang-questions] json to map

Roelof Wobben r.wobben@REDACTED
Fri Aug 28 21:20:51 CEST 2015


One question where I cannot find the answer to.

So far I have this :

-module(time_parser).

-export([tokens/1]).

tokens([]) ->  [];

tokens ([Head|Rest]) when Head =:= 32 ->
     tokens(Rest);

tokens ([Head|Rest]) when Head >= $0 , Head =< $9 ->
     digits(Head,Rest) ;

%tokens([Head|Rest]) when Head >= "a" , Head =< "z" ->
%   word(Rest, [Head]);

tokens (['/'| Rest]) ->
     [ '/' | tokens (Rest) ];

tokens (['-' | Rest]) ->
     [ '-'  | tokens (Rest)];

tokens ([','| Rest]) ->
     [ '_' | tokens (Rest)].


digits( Number, [Head | Rest]) when Head >= $0 , Head =< $9 ->
     digits(Number * 10 + Head , Rest);

digits(Number, Number2) when Number >= $0 , Number =< $9 ->
     Number + Number2.

so I do this in erl;

7> c(time_parser). {ok,time_parser}
8> time_parser:tokens([10]).
** exception error: no function clause matching time_parser:tokens("\n") 
(time_parser.erl, line 5)

where do the /n come from ?

Roelof




Op 28-8-2015 om 15:18 schreef Roelof Wobben:
> Op 28-8-2015 om 15:11 schreef Hugo Mills:
>> [Roelof, apologies for missing you out on the cc on my last mail -- I
>>   hope you got it through the mailing list. I don't know how that
>>   happened.]
>>
>> On Fri, Aug 28, 2015 at 12:27:14PM +0000, Hugo Mills wrote:
>>>     The best people to listen to here are generally the ones who ask
>>> you the awkward or difficult questions, because they're generally the
>>> ones who are trying to get you to think about the problem in a
>>> particular way. If you can answer those questions for yourself, you
>>> will usually be thinking about the problem in a way that will get you
>>> to the answer. If you can learn to think about problems in that way on
>>> your own, then you will actually be able to write useful code. This
>>> comes with practice, and lots of fiddling and failure on the way, but
>>> it's not something that can be taught directly as a step-by-step
>>> process to follow.
>>     Sorry to drone on here, but I wanted to follow up on this point a
>> bit.
>>
>>     Most problems in CS don't have linear paths to the solution. You
>> don't just start with "here's the input, so I do this, do this, do
>> this, and there's the answer". You have to pick at them around the
>> edges, find the pieces you know how to do. Consider doing something
>> because it looks like it might get you closer to the structure you
>> need. Work from both ends at once: you have some data as input, and
>> you want a particular structure as output; what can you do to the
>> input to simplify it? What's the simplest data that you could use to
>> generate the output, and how would you do it? Do those two meet in the
>> middle? If not, try again and work the edges towards each other. Is
>> there a simpler version of the problem you *can* solve? Do that first,
>> then see if you can modify it to deal with the other pieces.
>>
>>     Example: For this JSON-parsing problem, what's your input? (I'd
>> guess you just read the whole file in as a binary or a string to start
>> with -- pick one, do it; bear in mind what the chapter is trying to
>> teach you, as this may make a difference in which one you pick). Given
>> input in that form, if the first thing in your input is a plain quoted
>> string, can you turn that into an Erlang string and a piece of unused
>> input? Do that. What about a number to an Erlang number? Do that. An
>> unquoted string to an atom? Do that. Can you turn a simple JSON array
>> into an Erlang list of terms (and some unused input)?  Do that. Can
>> you modify that to parse an array of arrays? Do that. Can you turn a
>> simple non-nested JSON map into an Erlang map (or dict, or whatever)?
>> Do that. Can you use those as building blocks to parse a full JSON
>> structure? You're done. It'll be a pretty useless JSON parser for
>> practical purposes, but that's OK, you're just learning. (To repeat my
>> last email, the output of your work is not a program; the output is a
>> programmer).
>>
>>     Try writing down (in your own language) a problem description for
>> each of the stages above, and treat it as a self-contained problem.
>> Some of them will be trivial. Some will be a bit more complicated. The
>> later ones will build on the earlier ones. Write code (or modify
>> existing code) for each one. Being able to do this -- break a problem
>> down into separate pieces you know how to solve -- is the essence of
>> writing software, and it's the hardest thing to learn how to do well.
>>
>>     Hugo.
>
> Thanks for the advise.
>
> Roelof
>
>




More information about the erlang-questions mailing list