[erlang-questions] json to map

[Hugo Mills]

On Fri, Aug 28, 2015 at 09:20:51PM +0200, Roelof Wobben wrote:
> 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 ?

   ASCII 10 is a newline character, usually rendered as \n

   You passed a list containing the single number 10. In erlang,
strings are lists of integers, with each integer being the code
(a Unicode code point) of a character of the string.

   Hugo.

> 
> 
> 
> 
> 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
> >
> >
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-- 
Hugo Mills             | Hey, Virtual Memory! Now I can have a *really big*
hugo@REDACTED carfax.org.uk | ramdisk!
http://carfax.org.uk/  |
PGP: E2AB1DE4          |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150828/736116ae/attachment.bin>