RM> That said, describing the purpose of hg (and why one would want to use
RM> hg instead of av) is eluding me at the moment. Maybe when I wake up
RM> some more I would be better prepared to address this.

The hg specification states that the argument for the workhorse verb is the
atomic representation (ar) of hg's argument (which can be a verb or a noun).

   1 2 3 an hg
┌─────────┐
│┌─┬─────┐│
││0│1 2 3││
│└─┴─────┘│
└─────────┘
   *: an hg
┌──┐
│*:│
└──┘


   1 2 3 ] av
1 2 3

   *: ] av
┌──┐
│*:│
└──┘


PQ> The adverb hg is tacit and it is fixed.  Once it is defined one does not
PQ> have to know or remember how it works to use it (that was the main point
PQ> for defining it in the first place).

However, since there is some interest in knowing how hg works, these are a
few clues:

- The hart of hg is av

- The sentence (uN v av) evokes the form ((uN`'')&(v@:[) _) to produce v
(uN`'')
  For example, (1 2 3`'')&(*:@:[) _

- The verb aw fetches the ar of a verb or noun acting on (uN ("_)(`''))
  For example,

   1 2 3 ("_) (`'') aw av
┌─────────┐
│┌─┬─────┐│
││0│1 2 3││
│└─┴─────┘│
└─────────┘
   (%^&*) ("_) (`'') aw av
┌─────────────────┐
│┌─┬─────────────┐│
││2│┌─┬─────────┐││
││ ││%│┌─┬─────┐│││
││ ││ ││&│┌─┬─┐││││
││ ││ ││ ││^│*│││││
││ ││ ││ │└─┴─┘││││
││ ││ │└─┴─────┘│││
││ │└─┴─────────┘││
│└─┴─────────────┘│
└─────────────────┘





On Wed, Oct 25, 2017 at 7:38 AM, Raul Miller <[email protected]> wrote:

> I think you've introduced some false dichotomies here.
>
> First off, it's true that the J implementation is an interpreter, and
> it does not compile J to native code. Instead, it compiles J to an
> intermediate form which includes some ascii and some data structures.
> The displayed form represents those data structures with more
> characters (optionally: pure ascii).
>
> What Jose is doing here is manipulating data structures which J uses
> to represent programs and data. In F# terms, this would be like "AST
> Introspection" and "IL generation". (But, of course, J is not F#, and
> discussions focussed on F# would be best left for other contexts --
> perhaps the chat forum, here?)
>
> Anyways, because the J interpreter compiles to a representation which
> uses (compact) ascii to identify instructions, I think the answer to
> your third question should be "no". Or, maybe "yes, but no".
>
> That said, maybe I can be not just pedantic but useful. I've been
> working on understanding the mechanics of hg, and one approach
> involves replacing adverbs definitions with adverb names. And, if we
> consistently use a name for the (`:6) adverb, we can use that to
> display the progress of gerund evaluation adverbs, as they trigger.
>
> In other words, starting with:
>
>    ar=: 5!:1@:<
>
>    a0=: `''
>    a5=: `:6
>    a1=: (@:[) ((<'&')`) a5
>    a2=: (`(<(":0);_)) a5
>    av=: ((<'a0')`)  (`(<'a1')) (`(<'a2')) a5
>    NB. Adverbing a monadic verb (adv)
> echo 'First test'
>    assert 1 4 9 -: 1 2 3 *: av
>
>    aw=: < @: ((0;1;0)&{::)  NB. Fetching the atomic representation
>    a3=: (@:aw)av
>    a4=: "_
>    a6=: (('a4' ; ] ; 'a3'"_) av) a5
>
>    hg=: `(;:'a6 a5') a5
> echo 'Second test'
>      assert 1 4 9 -: 1 2 3 ((<'*:') ; ]) hg
>
> we can replace the a5 definition with:
>
> glr=:3 :0"0
>   t=. y 5!:0
>   r=. 5!:5<'t'
>   ".'check=.',r
>   if. y-:5!:1<'check' do. r else.
>     'NB. linear representation triggers J bug'
>   end.
> )
>
> gtyp=:3 :0"0
>   t=. y 5!:0
>   typ=. type't'
>   if. typ-:<'noun' do.
>     typ=.<(;typ),': ',datatype t
>   end.
> )
>
> a5=:1 :0
>   echo (<@glr m),(gtyp m),:m
>   m`:6
> )
>
> This displays each evaluated gerund as three rows. The first row is
> (usually) the linear representation of the corresponding gerund
> element. The second row is the type of the corresponding gerund
> element, and the third row is the gerund itself.
>
> You can use the second row, along with the parsing specification
> documented at http://www.jsoftware.com/help/dictionary/dicte.htm to
> determine how the gerund is being interpreted. The first row shows you
> some (hopefully helpful) details about what is being parsed.
>
> Note also that you will get this debugging output each time you use
> this instrumented version of hg. This can be beneficial if you have
> the time to digest what's being displayed but would be a huge
> annoyance in other contexts.
>
> That said, describing the purpose of hg (and why one would want to use
> hg instead of av) is eluding me at the moment. Maybe when I wake up
> some more I would be better prepared to address this.
>
> Thanks,
>
> --
> Raul
>
>
>
> On Wed, Oct 25, 2017 at 6:11 AM, Erling Hellenäs
> <[email protected]> wrote:
> > Hi all!
> >
> > It seems there are some more possibilities with your solutions. You are
> > doing some kind of program generation?
> > It has similarities with having functions as primary citizens, but it is
> not
> > the same because it does not happen at runtime?
> > What is passed is ascii representations of functions, not compiled
> functions
> > or compositions of compiled code?
> > In F# a function can take any  function and any data as arguments and
> > produce any combination of functions and data.
> > As far as I understand it would be similar to allowing verbs, adverbs and
> > conjunctions as data types in our nouns. Not ascii representations, but
> the
> > equivalents to single verbs, compositions of compiled code.
> > Have we considered this solution?
> >
> > See some commants below:
> >
> > Cheers,
> >
> > Erling Hellenäs
> >
> > Den 2017-10-25 kl. 00:46, skrev Jose Mario Quintana:
> >>
> >> Typical explicit adverbs produce the result of a sentence where the
> >> argument replaces its corresponding parameter (usually u).  In that
> sense,
> >> an adverb is similar to a macro but there are other possibilities; for
> >> instance, the adverb t1,
> >>
> >>     t1=. ([ , (<'@:') , ])/o |. o (('';1)&{::)hg
> >>
> >>     u0`u1`u2 t1
> >> u2@:u1@:u0
> >>
> >>     u0`u1`u2`u3`u4 t1
> >> u4@:u3@:u2@:u1@:u0
> >>
> >> (Try to write t1 explicitly, macro-style.)
> >>
> >> The difference between explicit and tacit adverbs is the same difference
> >> between explicit and tacit verbs.  They can produce the same results but
> >> one relies on parameters (named arguments) whereas the other does not,
> >>
> >>     'y + 1 % (1 + y)' (verb :)
> >> 3 : 'y + 1 % (1 + y)'
> >>     'y + 1 % (1 + y)' (verb :) 5
> >> 5.16667
> >>
> >>     (] + 1 % (1 + ]))
> >> ] + 1 % 1 + ]
> >>     (] + 1 % (1 + ])) 5
> >> 5.16667
> >>
> > What I call tacit code is verb trains. I do not call (<'@:') and ('';1)
> > tacit code, even if it contains no named entities.
> > Am I wrong?
> > u0`u1`u2 t1 is with either definition not tacit, since it contains the
> named
> > entity t1? (u0 u1 and u2 just means any verb)
> > When this is parsed I think t1 is replaced by this:
> > (("_)(((`'')(&(([ , (<'@:') ,
> > ])/@:|.@:(('';1)&({::))@:(<@:((0;1;0)&({::)))@:[)))((`_)(`:6))))(`:6)
> > There must be a gerund to the left, assume this:
> >
> > -`-`- (("_)(((`'')(&(([ , (<'@:') ,
> > ])/@:|.@:(('';1)&({::))@:(<@:((0;1;0)&({::)))@:[)))((`_)(`:6))))(`:6) I
> > think this forms a long string together with all other tacit code in the
> > tacit program. Then this is parsed. The long string is executed and then
> > replaced with this string -@:-@:-, which is then in it's turn parsed as
> part
> > of the rest of the program. The result of the tacit expression is then a
> > composition of compiled code, a single verb. This single verb is executed
> > with it's arguments and there is a result. So, at runtime, there is no
> > remnants of t1. In the single verb there is possibly some overhead and
> there
> > is an execution of the three negations.
> > So, at execution time, there is no passing of functions as arguments, not
> > even functions in character representation?
> > Using also explicit code there is of course no limitations of what you
> can
> > do with code in character representation. You can generate programs at
> > runtime as the result of input. How does this way to generate programs at
> > runtime compare to other functional programming languages?
> >
> > PS. I get a problem, but I guess it is not important for the discussion.
> >
> >    t0=: ([ , (<'@:') , ])/o |. o (('';1)&{::)hg
> >    -`-`- t0
> > -@:-@:-
> >    t0
> > (("_)(((`'')(&(([: ([: ([ , (<'@:') , ])/ |.)
> > ('';1)&({::))@:(<@:((0;1;0)&({::)))@:[)))((`_)(`:6))))(`:6)
> >    -`-`- (("_)(((`'')(&(([: ([: ([ , (<'@:') , ])/ |.)
> > ('';1)&({::))@:(<@:((0;1;0)&({::)))@:[)))((`_)(`:6))))(`:6)
> > |domain error
> > |   -`-`-
> > (("_)(((`'')(&(([:([:([,(<'@:'),])/|.)('';1)&({::))@:(<@:((0
> ;1;0)&({::)))@:[)))((`_)(`:6))))(`:6)
> >
> > DS.
> >
> >
> >>
> >>
> >>
> >> On Tue, Oct 24, 2017 at 4:40 AM, Erling Hellenäs
> >> <[email protected]>
> >> wrote:
> >>
> >>> See comments below:
> >>>
> >>>
> >>> Den 2017-10-24 kl. 07:14, skrev Jose Mario Quintana:
> >>>
> >>>> EH> Hi all!
> >>>>
> >>>> Hi
> >>>>
> >>>> EH> All user-written adverbs and conjunctions are something similar to
> >>>> the
> >>>> EH> macros in assembler and C++?
> >>>>
> >>>> I am not familiar with modern macros but if macros have an arbitrary
> but
> >>>> fixed number of parameters then the answer is: not necessarily.
> >>>>
> >>> I am not familiar with those either, but my assumption is that the text
> >>> set in the parameters simply replaces the parameters in the macros.
> >>>
> >>>     abrakadabra t0
> >>> abrakadabra + 1 % 1 + abrakadabra
> >>>
> >>>> EH> There are external interfaces. You  could call C/C++ code for
> >>>> example.
> >>>> I
> >>>> EH> don't know if it is possible for tacit code. I guess not.
> >>>>
> >>>> Tacit code can load libraries (e.g., addons) and execute verbs defined
> >>>> in
> >>>> those libraries which might, or might not, call C/C++ code.  I am not
> >>>> sure
> >>>> if my answer answers your question though. :)
> >>>>
> >>> If you can extend J with adverbs and conjunctions written in C/C++, you
> >>> could possibly generate the source code, compile them, link them and
> call
> >>> them. That would be very different from the current macro-like adverb
> and
> >>> conjunction definitions, it seems.
> >>>
> >>>
> >>>> EH> What you do is to generate programs? In runtime, when running
> tacit
> >>>>
> >>>> Tacit adverbs, in J and Jx and tacit conjunctions in Jx produce
> entities
> >>>> (nouns, verbs, adverbs, and conjunctions); those entities (apart from
> >>>> nouns) can be explicit or tacit but I prefer to keep everything tacit.
> >>>> Explicit adverbs and conjunctions produce the same kind of entities
> and
> >>>> those can be explicit or tacit, but you already know this since your
> >>>> explicit AtTacit below produces tacit verbs.
> >>>>
> >>>> EH> code, there is only the same built in code? Except then for some
> >>>> added
> >>>> EH> functionality in Jx? But using explicit code, you can read user
> >>>> input
> >>>> EH> and generate programs? Like we used to do with Do(".) ? How would
> >>>> you
> >>>> EH> compare the methods you have with this traditional method to
> >>>> generate
> >>>> code?
> >>>> EH>
> >>>> EH> Here my tacit conjunction AtTacit, equivalent with @:
> >>>> EH>     AtTacit=: 2 : '[: u v'
> >>>> EH>
> >>>> EH> The tacit code that actually executes is the second line, as far
> as
> >>>> i
> >>>> EH> understand. AtTacit only remains until I give it verb arguments,
> and
> >>>> EH> that will always happen before the actual tacit code is even
> parsed,
> >>>> as
> >>>> EH> far as I understand.
> >>>> EH>
> >>>> EH>     <AtTacit-
> >>>> EH> [: < -
> >>>> EH>
> >>>> EH> Your t0 can be defined like this?
> >>>> EH>
> >>>> EH>     t0=: 1 : 'u + 1 % 1 + u'
> >>>> EH>     u t0 t0
> >>>> EH> (u + 1 % 1 + u) + 1 % 1 + u + 1 % 1 + u
> >>>> EH>
> >>>>
> >>>> Sure, but t0 defined this way is not a tacit adverb,
> >>>>
> >>>>      t0
> >>>> 1 : 'u + 1 % 1 + u'
> >>>>
> >>>> in contrast (beware of line-wrapping),
> >>>>
> >>>>      t0=.   (] , (+`'') , (an 1) , (%`'') , (an 1) , (+`'') , ]) hg
> >>>>
> >>>>      t0
> >>>> (("_)(((`'')(&((] , (,<,'+') , (<(,'0');1) , (,<,'%') , (<(,'0');1) ,
> >>>> (,<,'+') , ])@:(<@:((0;1;0)&({::)))@:[)))((`_)(`:6))))(`:6)
> >>>>
> >>>> is tacit (it does not  have any named arguments; there are no names
> >>>> whatsoever)
> >>>>
> >>>>      v t0
> >>>> v + 1 % 1 + v
> >>>>
> >>>>      v t0 t0
> >>>> (v + 1 % 1 + v) + 1 % 1 + v + 1 % 1 + v
> >>>>
> >>>> I used hg to show that, even playing by the book, current J tacit
> >>>> adverbial
> >>>> programming is complete but tacit conjunctional programming is absent.
> >>>> I
> >>>> prefer to use its evil twin sibling adv (defined in the J Wicked
> >>>> Toolkit);
> >>>> adv was the model for the Jx version of adv (_1?:0).  I wrote the
> >>>> compliant
> >>>> version of hg because Dan Bron implied that the original version
> cheated
> >>>> which it did and I am proud of that ;)
> >>>>
> >>>> By the way, I wonder where Dan is. I really miss his posts, I learned
> a
> >>>> lot
> >>>> from them.
> >>>>
> >>> The difference still is not clear to me. I think before the resulting
> >>> tacit code actually executes you have to give it an argument, and what
> >>> then
> >>> actually executes is exactly the same.
> >>>     t0EH=: 1 : 'u + 1 % 1 + u'
> >>>     t0JMQ=.   (] , (+`'') , (an 1) , (%`'') , (an 1) , (+`'') , ]) hg
> >>>     t0EH
> >>> 1 : 'u + 1 % 1 + u'
> >>>     t0JMQ
> >>> (("_)(((`'')(&((] , (,<,'+') , (<(,'0');1) , (,<,'%') , (<(,'0');1) ,
> >>> (,<,'+') , ])@:(<@:((0;1;0)&({::)))@:[)))((`_)(`:6))))(`:6)
> >>>     +t0EH
> >>> + + 1 % 1 + +
> >>>     +t0JMQ
> >>> + + 1 % 1 + +
> >>> That t0JMQ, when the available words are replaced, does not contain any
> >>> words does not make it tacit, as far as I understand. It is a mixture
> of
> >>> tacit and explicit code, but before it all executes as a tacit
> >>> expression,
> >>> the replacements must be made in what seems equivalent to a text
> string,
> >>> which can then be parsed by `:6 to another new tacit expression.
> >>> It seems you are in a way handling functions as data, the question is
> in
> >>> what ways it is better than the macro-like adverbs and conjunctions and
> >>> the
> >>> parse string functionality we always had, even in IBM APL/1 1980.
> >>>
> >>>
> >>>> EH> Now you use your o=: @: ?
> >>>> EH>
> >>>> EH>     *:`(+/)`-`j.`(^ %:)t1 1 2 3
> >>>> EH> 2.40034j16.7123
> >>>> EH>      (^ %:) o j. o - o (+/) o *:  1 2 3
> >>>> EH> 2.40034j16.7123
> >>>> EH>
> >>>> EH> The tacit executed code is the same? So it is about saving
> >>>> keypresses
> >>>> EH> and about visual impression?
> >>>> EH>
> >>>>
> >>>> I like to use o instead of @: for the following reasons: it reminds me
> >>>> of
> >>>> the mathematical symbol for function composition  (g º f)(x) =
> g(f(x));
> >>>> @:
> >>>> distracts me; o is easier to write.
> >>>>
> >>>>
> >>>> EH> I admire your work. I'm not critical. I just want to give you the
> >>>> EH> opportunity to explain it.
> >>>>
> >>>> I appreciate your comment and your effort to understand it.  However,
> I
> >>>> must say that "my" work has been heavily influenced by several past
> and
> >>>> present members of the forum; yet the cheating is all mine.
> >>>>
> >>> :)
> >>>
> >>>
> >>>> EH>
> >>>> EH> Cheers,
> >>>> EH>
> >>>> EH> Erling Hellenäs
> >>>>
> >>>>
> >>>> On Sat, Oct 21, 2017 at 3:43 PM, Erling Hellenäs <
> >>>> [email protected]>
> >>>> wrote:
> >>>>
> >>>> Hi all!
> >>>>>
> >>>>> I don't understand the meaning of "tacit adverb". Before parsing of
> the
> >>>>> actual tacit trains, all adverbs and conjunctions are tied to their
> >>>>> arguments? What remains is a verb train to be parsed? A verb train
> >>>>> which
> >>>>> contains some built-in adverbs and conjunctions? These are tied to
> >>>>> their
> >>>>> arguments under the hood? Remains a verb train composed to a single
> >>>>> verb
> >>>>> which executes later?
> >>>>> All user-written adverbs and conjunctions are something similar to
> the
> >>>>> macros in assembler and C++?
> >>>>> Some of the built-in adverbs and conjunctions are compiled code with
> >>>>> verb
> >>>>> arguments, I guess. There is no way I know of for users to add or
> >>>>> define
> >>>>> such compiled adverbs and conjunctions.
> >>>>> There are external interfaces. You  could call C/C++ code for
> example.
> >>>>> I
> >>>>> don't know if it is possible for tacit code. I guess not.
> >>>>> What you do is to generate programs ? In runtime, when running tacit
> >>>>> code,
> >>>>> there is only the same built in code? Except then for some added
> >>>>> functionality in Jx? But using explicit code, you can read user input
> >>>>> and
> >>>>> generate programs? Like we used to do with Do(".) ? How would you
> >>>>> compare
> >>>>> the methods you have with this traditional method to generate code?
> >>>>>
> >>>>> Here my tacit conjunction AtTacit, equivalent with @:
> >>>>>      AtTacit=: 2 : '[: u v'
> >>>>>
> >>>>> The tacit code that actually executes is the second line, as far as i
> >>>>> understand. AtTacit only remains until I give it verb arguments, and
> >>>>> that
> >>>>> will always happen before the actual tacit code is even parsed, as
> far
> >>>>> as I
> >>>>> understand.
> >>>>>
> >>>>>      <AtTacit-
> >>>>> [: < -
> >>>>>
> >>>>> Your t0 can be defined like this?
> >>>>>
> >>>>>      t0=: 1 : 'u + 1 % 1 + u'
> >>>>>      u t0 t0
> >>>>> (u + 1 % 1 + u) + 1 % 1 + u + 1 % 1 + u
> >>>>>
> >>>>> About the verb train. I know earlier there was a performance penalty
> >>>>> for
> >>>>> writing -@:-@:-@:-@:- trains and you generated parenthesis, like
> this i
> >>>>> think: (-@:(-@:(-@:(-@:-)))). I can understand that. However this is
> no
> >>>>> longer necessary, since the performance difference is corrected. It
> was
> >>>>> also always possible to write strawmans([: - [:- [: - ]).
> >>>>> Now you use your o=: @: ?
> >>>>>
> >>>>>      *:`(+/)`-`j.`(^ %:)t1 1 2 3
> >>>>> 2.40034j16.7123
> >>>>>       (^ %:) o j. o - o (+/) o *:  1 2 3
> >>>>> 2.40034j16.7123
> >>>>>
> >>>>> The tacit executed code is the same? So it is about saving keypresses
> >>>>> and
> >>>>> about visual impression?
> >>>>>
> >>>>> *:`(+/)`-`j.`(^ %:)t1
> >>>>>
> >>>>> (^ %:)@:j.@:-@:(+/)@:*:
> >>>>>
> >>>>> (^ %:)o j.o-o(+/)o*:
> >>>>>
> >>>>> (^ %:)@:j.@:-@:(+/)@:*:
> >>>>>
> >>>>>
> >>>>> I admire your work. I'm not critical. I just want to give you the
> >>>>> opportunity to explain it.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Erling Hellenäs
> >>>>>
> >>>>>
> >> ----------------------------------------------------------------------
> >> 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

Reply via email to