headers
Jecel Assumpcao Jr | 10 Oct 1999 08:28
Picon
Picon

Re: alisp

Rafael Kaufmann wrote:
> 
> I'd appreciate any thoughts, comments, suggestions, etc. that any of you
> might have on the design and implementation and design of alisp (no
> project website yet), a general-purpose, fully reflective language of
> the Lisp family, and its accompanying interactive compiler. I intend to
> start out by following the Scheme specification (R5RS), and
> incrementally add features.

That is certainly one way to do it. I prefer to start with a
specification like that and then see what features I can remove...

-- Jecel
Permalink | Reply |
headers
Brian Rice | 10 Oct 1999 21:02

Re: alisp

At 03:28 AM 10/10/99 -0300, Jecel Assumpcao Jr wrote:
>Rafael Kaufmann wrote:
>> 
>> I'd appreciate any thoughts, comments, suggestions, etc. that any of you
>> might have on the design and implementation and design of alisp (no
>> project website yet), a general-purpose, fully reflective language of
>> the Lisp family, and its accompanying interactive compiler. I intend to
>> start out by following the Scheme specification (R5RS), and
>> incrementally add features.
>
>That is certainly one way to do it. I prefer to start with a
>specification like that and then see what features I can remove...
>
>-- Jecel
>

I'd have to agree with Jecel here.  It seems against the grain of designing
reflective systems to give them more hoops to jump through to make
reflection workable.  This is certainly the case when you decide to
implement more features than are absolutely necessary, or include any
services that are not as simple to describe as possible for the core
language.  You'll just be adding unneeded complexity in the long run, IMHO.

To provide contrast, I am developing an interface to my Arrow prototype
from a Lisp interpreter written in Smalltalk.  Most of the design changes
involve simplifying the features of the parser, so that the more
complicated translation issues can be made by using the interpreter itself.
 But then, most of the issues involve conceptual shifts that programmers
haven't before addressed.  The point is that it seems to be a much simpler
feat to implement features within the reflective framework than to develop
(Continue reading)

Permalink | Reply |
headers
Rafael Kaufmann | 11 Oct 1999 20:04
Picon

Re: alisp

Brian Rice wrote:

> 
> I'd have to agree with Jecel here.  It seems against the grain of designing
> reflective systems to give them more hoops to jump through to make
> reflection workable.  This is certainly the case when you decide to
> implement more features than are absolutely necessary, or include any
> services that are not as simple to describe as possible for the core
> language.  You'll just be adding unneeded complexity in the long run, IMHO.
> 
> To provide contrast, I am developing an interface to my Arrow prototype
> from a Lisp interpreter written in Smalltalk.  Most of the design changes
> involve simplifying the features of the parser, so that the more
> complicated translation issues can be made by using the interpreter itself.
>  But then, most of the issues involve conceptual shifts that programmers
> haven't before addressed.  The point is that it seems to be a much simpler
> feat to implement features within the reflective framework than to develop
> the framework to support the feature set.
> 
>         Brian

Definitely, I agree with you. I expressed myself poorly in the original
message; I intend to make the core as simple as possible, and implement
all additional functionality within the framework already provided by
the interpreter. By 'features', I really meant changes in the language
core's design - with the ultimate goal of making it fully reflective.

Anyway, I'll soon be sending out some design ideas I've had for the
alisp implementation. Criticism is expected and required, as always :)
(Continue reading)

Permalink | Reply |
headers
Brian Rice | 13 Oct 1999 00:28

Re: alisp

At 04:04 PM 10/11/99 -0200, you wrote:
>Brian Rice wrote:
>
>> 
>> I'd have to agree with Jecel here.  It seems against the grain of designing
>> reflective systems to give them more hoops to jump through to make
>> reflection workable.  This is certainly the case when you decide to
>> implement more features than are absolutely necessary, or include any
>> services that are not as simple to describe as possible for the core
>> language.  You'll just be adding unneeded complexity in the long run, IMHO.
>> 
>> To provide contrast, I am developing an interface to my Arrow prototype
>> from a Lisp interpreter written in Smalltalk.  Most of the design changes
>> involve simplifying the features of the parser, so that the more
>> complicated translation issues can be made by using the interpreter itself.
>>  But then, most of the issues involve conceptual shifts that programmers
>> haven't before addressed.  The point is that it seems to be a much simpler
>> feat to implement features within the reflective framework than to develop
>> the framework to support the feature set.
>> 
>>         Brian
>
>Definitely, I agree with you. I expressed myself poorly in the original
>message; I intend to make the core as simple as possible, and implement
>all additional functionality within the framework already provided by
>the interpreter. By 'features', I really meant changes in the language
>core's design - with the ultimate goal of making it fully reflective.
>
>Anyway, I'll soon be sending out some design ideas I've had for the
>alisp implementation. Criticism is expected and required, as always :)
(Continue reading)

Permalink | Reply |
headers
Laurent Martelli | 10 Oct 1999 22:45
Picon
Picon
Picon

Arrow news ?

>>>>> "Brian" == Brian Rice <water <at> tscnet.com> writes:

  Brian> To provide contrast, I am developing an interface to my Arrow
  Brian> prototype from a Lisp interpreter written in Smalltalk.  

Do you something useable yet ? 

--

-- 
Laurent Martelli
martelli <at> iie.cnam.fr
Permalink | Reply |

Gmane