Yes, it is complete. I didn't write it or test it as it was already posted
to rosettacode. I will explain how it works assuming there is interest
It uses some uncommon tricks. It leverages the read function which is the
same function used in the repl to read input characters. So the goal is to
take the file and skip any comments and then pass it on to set the variable
with the key and value.
(pipe (in File (while (echo "#" ";") (till "^J")))
Reads the file and echos until it encounters a comment character and then
reads til EOL
while (read)
> (skip)
> (set @ (or (line T) T)) ) ) )
Then read those echoed characters. read gets the first symbol, the key.
Skip moves the input stream ahead by the space or nothing. Set assigns the
variable @ which is the result from the last operation (read - which is the
key) with the value from the rest of the line or T if it is blank (for
boolean example in the config)
My brain has been trained to think of parens as whitespace. It didn't start
that way. I can see why you may consider them tokens. I was also counting
unique function/operation tokens, not characters. The idea being if I only
have 4 english words with 3 characters each on a line, that is easier for
my brain to parse than 5 operations using 2 ascii symbols that I don't
recognize the meaning.
However as my J vocabulary improves it becomes less of an issue. I can
parse i. or e. As fast as a function called idx or el?
Line length is still important I think. Also a functional style with
splitting up the train may help reusability, comprehension, and may help
identify small areas to refactor. Those small topics like "filter out
lines starting with a comment character" can get lost to me in a long line
of compound operations. Again, some balance and personal perference and
familiarity
I became interested in picolisp for its speed, conciseness and
expressiveness. Many of the same attributes as J. It is almost always in
the shortest solutions on rosettacode too. Happy to help resolve your build
issue off the list if you are interested.
On Jan 13, 2014 10:28 PM, "Raul Miller" <rauldmil...@gmail.com> wrote:
> On Mon, Jan 13, 2014 at 8:32 PM, Joe Bogner <joebog...@gmail.com> wrote:
> > PicoLisp
> >
> > (de rdConf (File)
> > (pipe (in File (while (echo "#" ";") (till "^J")))
> > (while (read)
> > (skip)
> > (set @ (or (line T) T)) ) ) )
>
> Is that complete?
>
> I learned lisp back in highschool, and I've used drracket and emacs
> and other such lisp environments, but never learned picolisp. I tried
> to install picolisp but it would not build for me and I do not feel
> like debugging the source for picolisp just for this message.
>
> My impression, though, is that a J implementation like what you have
> written would look something like this:
>
> conf=: a:-.~(#~ 1 -.&e. '#;'&e.S:0)<;._2 fread file
>
> In other words, read the file as lines, removing blank lines and comment
> lines.
>
> If all you are doing is saving the unparsed lines then we should
> expect simpler code. But maybe I have missed a subtlety of picolisp?
>
> I get that @ is a wild card, but I do not understand the mechanism
> well enough to say whether your implementation is correct, nor do I
> know whether (while (read) .. is stashing the read result somewhere or
> what. Nor do I know if your skip is assuming a rigid file structure or
> is allowing free-form comments in the config file.
>
> > If I compare that to the your J implementation
> >
> >> deb L:0@:(({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&'
> =')&>@(#~
> >> a:&~: > ';#'e.~{.&>)@:(dlb&.>)@:(LF&cut)
> >
> > This J implementation feels more like code golf or a compressed
> > string. How many tokens/operations are included in it? I won't count,
> > but I am fairly sure it's more than the (pipe, in, while, echo, till,
> > read, skip, set, or, line) 9 in the PicoLisp example.
>
> I count 64 tokens in the J implementation and 54 tokens in your
> PicoLisp example. I'm not sure why you have implied that parentheses
> are not tokens but I do not think they qualify as whitespace?
>
> We could get further into parsing and punctuation issues, but I'm not
> sure whether that would be relevant.
>
> > When reading a long J string or an entry in the obfuscated C code
> > contest, I try to recognize patterns or operations. Having used J for
> > about 6 months, I can recognize probably about half the operations in
> > that string without having to look them up. That's progress. It still
> > feels like a "run on sentence" which is harder to read than short
> > sentences.
>
> I also usually prefer shorter sentences. Not always, but I'd probably
> try to split Dan's code into two or three lines. Posting a fair bit of
> code to email has been an influence there.
>
> I imagine I would also favor a shorter implmentation than what Dan has
> done here. For example, in his code I see the phrase e.&' =' but I see
> no equals signs in the config file nor in the specification on the
> companion task (whose J entry should perhaps be simplified?).
>
> > I think there's a fine balance between tacit expressions and clarity.
> > It may be my level of inexperience with the language. However, I
> > wonder if I've put as much time on it as any intro-level APL
> > programmer. Are there any conventions in the language for # of tokens,
> > trains, etc for a readable sentence?
>
> Personal taste?
>
> Thanks,
>
> --
> Raul
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
