Simple question (avoiding the tacit-v, tacit-t etc. terminology so that we're all on the same page): Are you essentially proposing something akin to Dyalog's d-fns? See, for example, https://www.dyalog.com/uploads/documents/Papers/dfns.pdf. (We don't have lexical scope in J, so the comparison isn't exact.)
As far as I can tell, the proposal is to provide a syntax for more easily abstracting over explicit expressions without requiring transformations to tacit form. (In other words, an improved '4 :'.) If this is the case, would you mind expanding on how your proposal relates to existing explicit definitions? Are there significant functional differences, or is this mainly a syntactic proposal? One thing that springs to mind is that a d-fn style approach makes nesting explicit definitions far more readable and concise. /M On Wed, Sep 27, 2017 at 7:43 AM, Erling Hellenäs <[email protected]> wrote: > It's hard to understand what could possibly remain to explain. Well, lets > see if something more happens in the discussion. I'll give up on the second > and third question. /Erling > > > On 2017-09-27 16:23, Henry Rich wrote: >> >> I am sorry, but I have not been able to make sense of the last several >> messages. JWithATwist is outside my area of interest. If you can describe >> this idea fairly precisely, and explain why it should be implemented, I will >> try to understand it. >> >> To me, yes, what you can do with a language is the only thing that counts. >> >> Henry Rich >> >> On 9/27/2017 10:13 AM, Erling Hellenäs wrote: >>> >>> So it would be relevant to discuss this request in terms of programmer >>> productivity? >>> Any opinions? /Erling? >>> >>> On 2017-09-27 16:01, Don Guinn wrote: >>>> >>>> If you want the most powerful programming language it has to be >>>> assembly. >>>> It can do everything that every other programming language can do and so >>>> much more. But what is the purpose of languages like J and C++? They are >>>> to >>>> make people more productive, not computers. >>>> >>>> On Sep 27, 2017 7:34 AM, "Erling Hellenäs" <[email protected]> >>>> wrote: >>>> >>>> Hi all ! >>>> >>>> See comments below. >>>> >>>> There are still two unanswered questions. You are not required to answer >>>> them, of course. >>>> >>>> Cheers, >>>> >>>> Erling Hellenäs >>>> >>>> >>>> On 2017-09-27 13:36, Henry Rich wrote: >>>> >>>>> The syntax is that of explicit J but missing some things, like control >>>>> words and assignment, and perhaps the ability to write multiline >>>>> expressions. If it produces tacit J, it's also not going to be able to >>>>> define modifiers. >>>>> >>>>> I don't know what question this answers. JWithATwist handles modifiers >>>> >>>> during interpretation, in the same way I think tacit J does. To set them >>>> at >>>> runtime you might have to use the same tricks as normal tacit J. Yes, I >>>> imagine the tacit-v expressions to have the same functionality as normal >>>> tacit J. No control words and no assignment. >>>> >>>> I just don't see that having a new way to write tacit verbs is a change >>>>> >>>>> worth making, if it doesn't allow something that the old way didn't. >>>>> >>>> And what you can do with a language is the only thing that counts? C++ >>>> is a >>>> million times better than J? >>>> To discuss other arguments for and against the different notations would >>>> be >>>> of no use? >>>> >>>> >>>>> Henry Rich >>>>> >>>>> On 9/27/2017 6:25 AM, Erling Hellenäs wrote: >>>>> >>>>>> Hi all ! >>>>>> >>>>>> See comments below. >>>>>> >>>>>> Henry, you answered one of three questions. >>>>>> >>>>>> Cheers, >>>>>> Erling >>>>>> >>>>>> On 2017-09-27 11:09, Henry Rich wrote: >>>>>> >>>>>>> I have trouble contributing to this because I don't understand your >>>>>>> proposal as written. One thing I don't understand is why you call >>>>>>> your new >>>>>>> verbs 'tacit'. It appeared to me that they used ] and [ as tokens >>>>>>> indicating the input arguments. That would make them explicit, by >>>>>>> the >>>>>>> definition of that word. >>>>>>> >>>>>> We can call them something different, I just choose tacit-v >>>>>> expressions >>>>>> for the purpose of my request. >>>>>> They are very similar to tacit expressions. They have exactly the same >>>>>> functionality, just different syntax, and that syntax is the syntax of >>>>>> explicit J. >>>>>> >>>>>>> >>>>>>> The tacit language shows up inside lines of code. When you write >>>>>>> >>>>>>> sortedbycol1 =: (/: 1&{"1) array >>>>>>> >>>>>>> there a little tacit code there. We wouldn't want to lose that. >>>>>>> >>>>>>> >>>>>>> The tacit-v expression would be >>>>>> >>>>>> sortedbycol1 =: (: ] /: 1 {"1 ] ): >>>>>> if we choose the (: ): brackets. The brackets are needed here as long >>>>>> as >>>>>> present tacit J is the default. >>>>>> The tacit-t version can be written like this. >>>>>> sortedbycol1 =: /: 1&{"1 >>>>>> Brackets are automatically added, creating the hook. If we directly >>>>>> compare the notation, >>>>>> ] /: 1 {"1 ] is equivalent to >>>>>> ( /: 1&{"1 )@] if we write code that can be moved between a monadic >>>>>> and >>>>>> dyadic context without rewrite. >>>>>> However, as I said, the easiest implementation probably is to continue >>>>>> allowing the present tacit expressions in tacit-v expressions. >>>>>> In the long run you would probably not want both ways to express >>>>>> exactly >>>>>> the same thing, you would want to let the new tacit-v expressions >>>>>> replace >>>>>> the present tacit expressions as I see it. There is a question about >>>>>> how it >>>>>> could be done. One way is to not allow them in tacit-v expressions >>>>>> from the >>>>>> beginning, as I propose, but there are other ways. To block them from >>>>>> the >>>>>> beginning would make the first implementation much harder. >>>>>> sortedbycol1 =: (/: 1&{"1) >>>>>> >>>>>> sortedbycol1 i. _3 4 >>>>>> >>>>>> 0 1 2 3 >>>>>> >>>>>> 4 5 6 7 >>>>>> >>>>>> 8 9 10 11 >>>>>> >>>>>> >>>>>>> All the uninflected delimiters are taken, and {. }. and {: }: and <. >>>>>>> >. >>>>>>> and <: >:; but (. ). and (: ): are available. >>>>>>> >>>>>>> It seems out of the question to redefine any of { } [ ] as they are >>>>>>> used in so much existing J code. >>>>>>> >>>>>>> Henry Rich >>>>>>> >>>>>>> On 9/27/2017 4:33 AM, Erling Hellenäs wrote: >>>>>>> >>>>>>>> Hi all! >>>>>>>> >>>>>>>> It seems like fast function definitions is only for creating >>>>>>>> explicit J >>>>>>>> verbs, adverbs and conjunctions? >>>>>>>> >>>>>>>> This means it is only vaguely related to my proposal of tacit verbs >>>>>>>> with explicit J syntax? >>>>>>>> >>>>>>>> Maybe the fast function definition discussion should therefore have >>>>>>>> it's own thread? >>>>>>>> >>>>>>>> Let's say we wanted to implement tacit-v verbs. >>>>>>>> >>>>>>>> -Is there a construct like { ... } or (. ... ). that could possibly >>>>>>>> be >>>>>>>> used for a new kind of bracket notation? >>>>>>>> >>>>>>>> -Would x and y or [ and ] be suitable as symbols of the left and >>>>>>>> right >>>>>>>> arguments? If so, which of them ? If not, what would be a suitable >>>>>>>> representation of the left and right argument ? >>>>>>>> >>>>>>>> -Could the interpreter be easily modified to allow the explicit J >>>>>>>> syntax in this new bracket construct, or would it be difficult or >>>>>>>> impossible to achieve? >>>>>>>> >>>>>>>> In the JWithATwist interpreter the difference between how brackets >>>>>>>> with >>>>>>>> explicit J code are handled and how tacit-v brackets are handled is >>>>>>>> about >>>>>>>> four lines of code. It think this indicates that this might not be >>>>>>>> such a >>>>>>>> revolutionary change in terms of actual code changes. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Erling >>>>>>>> >>>>>>>> On 2017-09-26 22:34, Henry Rich wrote: >>>>>>>> >>>>>>>>> Good point, colorization. I never thought about that. >>>>>>>>> >>>>>>>>> The big difference between Fast Functions and 3 : functions is that >>>>>>>>> Fast Functions are recognized when a script is loaded, instead of >>>>>>>>> when the >>>>>>>>> 3 : is executed. It is the fact that 3 : is executed like any >>>>>>>>> other >>>>>>>>> conjunction that prevents nesting of multiline verbs: the nested >>>>>>>>> verb can't >>>>>>>>> be defined until it is executed, and by then its definition is long >>>>>>>>> gone. >>>>>>>>> >>>>>>>>> The innermost (. ). is analyzed and replaced by (m : string). The >>>>>>>>> process continues for all nesting levels. This completes the >>>>>>>>> prepass. >>>>>>>>> >>>>>>>>> The generated verbs - (m : string) forms - are handled as they are >>>>>>>>> now, when the : is executed. That means nested verbs are not >>>>>>>>> processed >>>>>>>>> until they are encountered during execution. >>>>>>>>> >>>>>>>>> Linear representation is used to make the (3 : string) form atomic. >>>>>>>>> >>>>>>>>> Yes, you would need to balance (. . >>>>>>>>> >>>>>>>>> Henry Rich >>>>>>>>> >>>>>>>>> On 9/26/2017 4:02 PM, Raul Miller wrote: >>>>>>>>> >>>>>>>>>> Prepass means essentially that this happens after word formation >>>>>>>>>> but >>>>>>>>>> before parsing. That does eliminate some problems, but creates new >>>>>>>>>> ones. It also suggests that you would be supporting explicit >>>>>>>>>> control >>>>>>>>>> words. But it also means that you need to put a lot more thought >>>>>>>>>> into >>>>>>>>>> how these would be represented (and stored) - there's no inherent >>>>>>>>>> point to using linear representation to "unparse" here. >>>>>>>>>> >>>>>>>>>> (Do inner (. ). definitions get reparsed every time the outer >>>>>>>>>> expression gets evaluated? That might be the simplest approach, >>>>>>>>>> but >>>>>>>>>> does require significant changes in explicit handling.) >>>>>>>>>> >>>>>>>>>> Multiline means that you get into behavior somewhat like you get >>>>>>>>>> when >>>>>>>>>> m :0 appears on a line. But getting out of that might be more >>>>>>>>>> complicated than it is now (because you might not know if you need >>>>>>>>>> ). >>>>>>>>>> or a sequence of them or ) to end it - for example after pasting >>>>>>>>>> something big into your session). >>>>>>>>>> >>>>>>>>>> The complexities introduced by multi-line probably means that >>>>>>>>>> interactive environments would want to colorize (. ). definitions >>>>>>>>>> (especially incomplete definitions while being entered) based on >>>>>>>>>> the >>>>>>>>>> presence/absence of mnuvxy seen so far (probably not the current >>>>>>>>>> line >>>>>>>>>> though). >>>>>>>>>> >>>>>>>>>> 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
