Re: Perl6 shell, Was: command auto-completion in perl6 shell

[Patrick R. Michaud]

On Wed, May 31, 2017 at 09:33:59AM -0400, Brock Wilcox wrote:
> One of my dreams is to adopt a client/server + middleware model from nREPL
> (clojure) which I think works really well, and likely to do that in
> userspace as a regular module. Moving everything into REPL.pm (perl6
> instead of nqp) lets us use de-facto interfaces and easily override it in a
> user module.

FWIW, the idea has always been that NQP provides a simple, default REPL for 
tools/languages being built using NQP, and then languages can then 
override/augment that REPL as desired.

Pm

Re: Perl6 shell, Was: command auto-completion in perl6 shell

[Parrot Raiser]

> Do you have something specific in mind?

I don't know enough about the internals to have any particular suggestions.

Keeping functions properly local is just one of those "motherhood and
apple pie" principles that is much easier to follow if it is done
consistently from the start.

Re: Perl6 shell, Was: command auto-completion in perl6 shell

[Brock Wilcox]

Some progress on this has already been made, which is how it got as close
to standalone as it is now -- previously the REPL was more NQP than Rakudo.
Do you have something specific in mind?

One of my dreams is to adopt a client/server + middleware model from nREPL
(clojure) which I think works really well, and likely to do that in
userspace as a regular module. Moving everything into REPL.pm (perl6
instead of nqp) lets us use de-facto interfaces and easily override it in a
user module.

--Brock


On Wed, May 31, 2017 at 9:05 AM, Parrot Raiser <1parr...@gmail.com> wrote:

> I was not proposing that the REPL was to be invoked in any other way
> than at present. By "reducing the coupling", I mean arranging
> functions and interfaces in a way that prevents a change in one
> function affecting the other. Essentially, implementing standard
> interfaces between complete functions.
>
> A REPL has multiple parts; a code editing function, the UI to manage
> that, an execution environment, and the language being executed. The
> interfaces between them should be such that any one of them can be
> extended and improved without having an impact on the others.
> Minimising coupling is a fundamental design requirement for easy
> development and maintenance of a complex system. For example, new
> functions in the language shouldn't need changes to the editor.
>
> On 5/30/17, Richard Hainsworth  wrote:
> >   Please do not weaken the link between REPL and perl6 !
> >
> > The ability to test perl6 snippets very quickly is something I find very
> > useful. And to get this I type 'perl6'. Easy to remember.
> >
> > (I have been following perl6 since the very beginning, and installed
> > 'pug'. Since perl6 has been evolving, I always check syntax with REPL
> > first. Without it I would be lost as I still find sequences, arrays,
> > .slip, .flat, '|' etc incredibly difficult to master.)
> >
> > 'rakudo' is not perl6, but an implementation of perl6. Even so, it is
> > called using 'perl6 [options] '.
> >
> > To insist, for the sake of purity, that REPL is called by some other
> > name than 'perl6' would require for the sake of purity that 'rakudo' is
> > called using the command 'rakudo' and not 'perl6'. If a computer guru
> > wants to do that on a system that he/she controls, what is stopping them?
> >
> > However, I would argue it is best, at present and in order to facilitate
> > adoption of perl6, that we keep to the current naming scheme and make it
> > easy for newcomers to perl6.
> >
> > Finanalyst
> >
> >
> > On Wednesday, May 31, 2017 12:34 AM, Parrot Raiser wrote:
> >> The REPL's almost an independent project.
> >>
> >> Can it be made modular, to reduce the coupling between it and the
> >> language?
> >
>

Re: Perl6 shell, Was: command auto-completion in perl6 shell

[Parrot Raiser]

I was not proposing that the REPL was to be invoked in any other way
than at present. By "reducing the coupling", I mean arranging
functions and interfaces in a way that prevents a change in one
function affecting the other. Essentially, implementing standard
interfaces between complete functions.

A REPL has multiple parts; a code editing function, the UI to manage
that, an execution environment, and the language being executed. The
interfaces between them should be such that any one of them can be
extended and improved without having an impact on the others.
Minimising coupling is a fundamental design requirement for easy
development and maintenance of a complex system. For example, new
functions in the language shouldn't need changes to the editor.

On 5/30/17, Richard Hainsworth  wrote:
>   Please do not weaken the link between REPL and perl6 !
>
> The ability to test perl6 snippets very quickly is something I find very
> useful. And to get this I type 'perl6'. Easy to remember.
>
> (I have been following perl6 since the very beginning, and installed
> 'pug'. Since perl6 has been evolving, I always check syntax with REPL
> first. Without it I would be lost as I still find sequences, arrays,
> .slip, .flat, '|' etc incredibly difficult to master.)
>
> 'rakudo' is not perl6, but an implementation of perl6. Even so, it is
> called using 'perl6 [options] '.
>
> To insist, for the sake of purity, that REPL is called by some other
> name than 'perl6' would require for the sake of purity that 'rakudo' is
> called using the command 'rakudo' and not 'perl6'. If a computer guru
> wants to do that on a system that he/she controls, what is stopping them?
>
> However, I would argue it is best, at present and in order to facilitate
> adoption of perl6, that we keep to the current naming scheme and make it
> easy for newcomers to perl6.
>
> Finanalyst
>
>
> On Wednesday, May 31, 2017 12:34 AM, Parrot Raiser wrote:
>> The REPL's almost an independent project.
>>
>> Can it be made modular, to reduce the coupling between it and the
>> language?
>

Perl6 shell, Was: command auto-completion in perl6 shell

[Richard Hainsworth]

 Please do not weaken the link between REPL and perl6 !

The ability to test perl6 snippets very quickly is something I find very 
useful. And to get this I type 'perl6'. Easy to remember.


(I have been following perl6 since the very beginning, and installed 
'pug'. Since perl6 has been evolving, I always check syntax with REPL 
first. Without it I would be lost as I still find sequences, arrays, 
.slip, .flat, '|' etc incredibly difficult to master.)


'rakudo' is not perl6, but an implementation of perl6. Even so, it is 
called using 'perl6 [options] '.


To insist, for the sake of purity, that REPL is called by some other 
name than 'perl6' would require for the sake of purity that 'rakudo' is 
called using the command 'rakudo' and not 'perl6'. If a computer guru 
wants to do that on a system that he/she controls, what is stopping them?


However, I would argue it is best, at present and in order to facilitate 
adoption of perl6, that we keep to the current naming scheme and make it 
easy for newcomers to perl6.


Finanalyst


On Wednesday, May 31, 2017 12:34 AM, Parrot Raiser wrote:

The REPL's almost an independent project.

Can it be made modular, to reduce the coupling between it and the language?