Great. Erling, how does your proposal differ from the above (glossing over specifics like using [, ] etc.)?
On Wed, Sep 27, 2017 at 9:06 AM, Henry Rich <[email protected]> wrote: > You have my proposal right. It is like d-fns. There is no new added > functionality - in fact there can't be, because every (. ). function is > converted to an explicit definition. > > The benefit is ease of creating explicit entities, even if they are > anonymous, multiline, or nested within other entities. > > Henry Rich > > > On 9/27/2017 11:31 AM, Marc Simpson wrote: >> >> 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 > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
