Maybe there is a nice way to do this that I don't know of. The best I
can come up with is this:
DropRedundantBlanks
3 : 0
NB. Deletes repeated, leading and training blanks from a string.
NB. Right argument: String
NB. Result: String.
BetweenConsecutiveAM=. 1 : '[: u/ }. ,: }:'
nonBlankM=.' ' ~: ]
nonBlankOrFirstInBlankGroupM=.$ {. 1 , [: +.BetweenConsecutiveAM nonBlankM
DropLeadingBlankM=. (' ' = {.) }. ]
DropTrailingBlankM=. (_1 * ' ' = {:) }. ]
DropRedundantBlanksM=: [: DropLeadingBlankM [: DropTrailingBlankM
nonBlankOrFirstInBlankGroupM # ]
DropRedundantBlanksM=: DropRedundantBlanksM f.
y
)
DropRedundantBlanks''
a=:' ert t yyy yy '
DropRedundantBlanksM a
ert t yyy yy
In the development environment I would like it to be easy to find the
definition wherever I see the symbol.
See comments below.
/Erling
On 2014-07-15 00:52, Björn Helgason wrote:
If you read the phrases they have short names for easy use and good
comments.
I know this already exists and that short names is more handy for this
kind of frequently used functions. I'm thinking about how to document
and write tacit code in general.
I like to use clear names for global nouns but short local names.
I'm playing with the idea of using long names to make the program more
self-documented.
Good to use locales to separate names.
Yes. If possible I would even like to hide many symbols in the
definition, like above.
On Jul 14, 2014 8:49 PM, "Erling Hellenäs" <[email protected]>
wrote:
Like this?
BetweenConsecutiveAM=: 1 : '[: u/ }. ,: }:'
nonBlankM=:' ' ~: ]
nonBlankOrFirstInBlankGroupM=:$ {. 1 , [: +.BetweenConsecutiveAM
nonBlankM
DropLeadingBlankM=: (' ' = {.) }. ]
DropTrailingBlankM=: (_1 * ' ' = {:) }. ]
DropRedundantBlanksM=: [: DropLeadingBlankM [: DropTrailingBlankM
nonBlankOrFirstInBlankGroupM # ]
a=:' ert t yyy yy '
DropRedundantBlanksM a
ert t yyy yy
/Erling
On 2014-07-14 22:09, Erling Hellenäs wrote:
Typo. Excuse me. Like this.
debm=:[: ((' ' = {.) }. ]) ([: (] +. $ {. ([: >bc ]), 0:) (' ' ~: ])) # ]
/Erling
On 2014-07-14 21:10, Erling Hellenäs wrote:
Another version without & och @. Now even without f~. Skipping leading
and trailing blanks.
bc=: 1 : '[: u/ }. ,: }:'
debm=:[: ((' ' = {.) }. ]) ([: (] +. $ {. ([: >.bc ]), 0:) (' ' ~: ])) #
]
debm a
ert t yyy yy
/Erling
On 2014-07-14 18:52, Ian Clark wrote:
Thanks @Raul. As you discreetly point out, I was wrong to suggest r0
and s0
could be eliminated by simply replacing left rotate |. by left shift
|.!.0
The resulting verb:
debXA=: monad define
]Notspace=. (' ') ~: y
]LeftshiftedNotspace=. 1 |.!.0 Notspace
or=. +.
]Keep=. Notspace or LeftshiftedNotspace
]Keep # y
)
cannot remove a (residual) leading space.
So LeftshiftedNotspace is strictly speaking misnamed.
On Mon, Jul 14, 2014 at 5:29 PM, Raul Miller <[email protected]>
wrote:
I'd probably call s0 "Firstchar" (its actually the first non-blank
character but you have to allow a certain amount of ambiguity in naming
conventions).
I'd also probably call r0 "RelevantShadow" (since it's what's going to
be
rotated left to catch the non-extraneous spaces).
Thanks,
--
Raul
On Mon, Jul 14, 2014 at 12:25 PM, Ian Clark <[email protected]>
wrote:
Thanks Linda. Yes, there is a better explicit version than:
f=: 13 :'(#~[:(+. 1 |. (> </\)) '' ''~:])y'
Addon: tte makes heavy weather of deb, but handles deb2 a lot better,
now
that you've replaced @ by a capped fork, since it breaks down the
tacit
phrase into intermediate pronouns only, avoiding intermediate
proverbs.
These work-pronouns can then be renamed meaningfully.
Here's my "explication" (=deconstruction?) of your deb2 ...
require 'debug/tte'
deb2 tte
3 : 0
NB. (deb2): #~ ([: (+. (1 |. (> </\))) ' ' ~: ])
] t0=: (' ') ~: y NB. fork: ' ' ~: ]
] s0=: </\ t0 NB. main: h-: ,'\'
] r0=: t0 > s0 NB. hook: > </\
] q0=: 1 |. r0 NB. fork: 1 |. (> ((</)\))
] p0=: t0 +. q0 NB. hook: +. (1 |. (> </\))
NB. atco: (+. (1 |. (> </\)))@:(' ' ~: ])
] z0=: p0 # y NB. swap: #~
NB. hook: #~ ([: (+. (1 |. (> </\))) ' ' ~: ])
:
NB. (dyad irrelevant, so I have omitted it here)
)
Now all I have to do is set up a test value of y and re-execute lines
one-by-one ...
y=: ' able baker '
] t0=: (' ') ~: y NB. Notspace
0 1 1 1 1 0 0 0 1 1 1 1 1 0 0
] s0=: </\ t0
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
] r0=: t0 > s0
0 0 1 1 1 0 0 0 1 1 1 1 1 0 0
] q0=: 1 |. r0 NB. LeftshiftedNotspace
0 1 1 1 0 0 0 1 1 1 1 1 0 0 0
] p0=: t0 +. q0 NB. Notspace or LeftshiftedNotspace
0 1 1 1 1 0 0 1 1 1 1 1 1 0 0
] z0=: p0 # y NB. KeepOnes
able baker
I've replaced the comments with suggested names on the basis of what
each
line appears to do. I haven't bothered with names for s0 and r0
because
the
3 lines concerned seem to be an elaborate way of turning rotate-left
into
shift-left, which could have been done using (!.) as shown in
http://www.jsoftware.com/jwiki/Vocabulary/bardot#monadicfit
This lets me rewrite (deb2 tte) as follows:
debX=: monad define
Notspace=. (' ') ~: y
s0=. </\ Notspace
r0=. Notspace > s0
LeftshiftedNotspace=. 1 |. r0
or=. +.
Keep=. Notspace or LeftshiftedNotspace
Keep # y
)
... which is more in the spirit of
http://www.jsoftware.com/jwiki/Vocabulary/Unreadability .
As you see, the above is a largely automatic procedure well within the
capability of a typical beginner.
IanClark
On Mon, Jul 14, 2014 at 7:18 AM, Linda Alvord <
[email protected]>
wrote:
Here's deb without @ and &
deb
#~ (+. (1: |. (> </\)))@(' '&~:)
deb2
#~ ([: (+. (1 |. (> </\))) ' ' ~: ])
However it seems as though there should be a better explicit version
than:
f=: 13 :'(#~[:(+. 1 |. (> </\)) '' ''~:])y'
Linda
-----Original Message-----
From: [email protected] [mailto:
[email protected]] On Behalf Of Linda Alvord
Sent: Sunday, July 13, 2014 11:43 PM
To: [email protected]
Subject: Re: [Jprogramming] Design goals readability and
writeability?
I enjoyed your article:
<"1 toupper"0>"0;:'alpha beta gamma'
┌─────┬─────┬─────┐
│ALPHA│BETA │GAMMA│
└─────┴─────┴─────┘
Linda
-----Original Message-----
From: [email protected] [mailto:
[email protected]] On Behalf Of Ian Clark
Sent: Sunday, July 13, 2014 9:40 PM
To: [email protected]
Subject: Re: [Jprogramming] Design goals readability and
writeability?
"The alleged unreadability of J - and what to do about it"
http://www.jsoftware.com/jwiki/Vocabulary/Unreadability
On Sun, Jul 13, 2014 at 11:43 PM, Don Kelly <[email protected]> wrote:
Absolutely!!
J suffers from the same problem as its precurser APL- in spades..
One
can
write very terse code because of its power. Often, 6 moths later the
original writer has to spend time interpreting what was written. I
have
come up with some terse code and , more often terse code from others-
all
of which has been put in a utility script wrapped in comments so
that
when
I want to use it-I do have such guidance. This is something one has
to
do
to a great extent with any programming language. It is even more
important
with J tacit.
Don Kelly
On 12/07/2014 11:44 AM, Don Guinn wrote:
Readability depends on a person's background. I can't read Chinese.
Does
that mean it's not a readable language?
When writing a program or a document one must assume some level of
knowledge of the reader. J tends to assume readers have a greater
knowledge
of mathematics than most other programming languages require.
But readability is a real problem. What is usually missing from
many
programs, especially J tacit, is the intent of something. Say I see
something like this:
< @ (({. + i.@{:)@[ { ] )
It would certainly help to have some idea what this is supposed to
do.
What
its arguments are and what it returns. Documentation really helps.
But J expressions can be intimidating. It has always bothered me
that
I
could attack a FORTRAN program spanning several pages comfortably.
But
a J
program of just a few lines which do exactly the same thing is hard
for
me
to get into.
On Sat, Jul 12, 2014 at 12:23 PM, Erling Hellenäs <
[email protected]>
wrote:
Hi all !
Yes, maybe we should all be concerned about writing readable code
instead
of the shortest and most cryptic code? Maybe we should also write
writeable
code? Find a way to write that allows us to get the expressions
right
the
first time?
J is more of a notation than a language? The value of a notation
is
determined by clarity, but also readability? Maybe readability and
writeability, in the sense I explained above, should get higher
priority
as
design goals for our future J?
Cheers,
Erling Hellenäs
On 2014-07-12 07:40, Raul Miller wrote:
I would not generalize to higher rank arrays without a model of
why
I'd
be
using them.
In other words, v=: {"_1 |:~&0 2 is probably good enough.
There are some interesting contradictions here - while one needs
to
be
comfortable thinking mathematically to get decent performance out
of a
system, usually what we are building is a mix of instant and
delayed
gratification and we usually assume our audience has no direct
interest
in
the math we are performing (indirect interest, yes - sometimes).
Often I think we go overboard, and we should throw back in some
exposure
to
some of the more robust concepts (especially for the kids, so
they
have
something interesting to play with). But professional adults tend
to
be
under a lot of time pressure, and as a result their needs often
seem
to
be
a mix of the very basic and the childish.
Meanwhile, it seems like anything worthwhile takes time and
effort.
Anyways, professional software design often centers around use
cases
and
similar models which are aimed at extracting the important
concepts
about
what people need to get done and how they want to work. And that
kind
of
information is what you need if you are going to properly
generalize
application code.
Thanks,
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
------------------------------------------------------------
----------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/
forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/
forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/
forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/
forums.htm
------------------------------------------------------------
----------
For information about J forums see http://www.jsoftware.com/forums.htm
------------------------------------------------------------
----------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
