Re: Phoenix language

[Gregory Casamento]

Nikolaus,

On Thu, Oct 23, 2014 at 3:39 AM, Dr. H. Nikolaus Schaller
<hns@computer.org> wrote:
> Hi,
>
> Am 23.10.2014 um 00:22 schrieb Gregory Casamento <greg.casamento@gmail.com>:
>
>> Dr. Schaller,
>>
>> On Wed, Oct 22, 2014 at 6:06 PM, Dr. H. Nikolaus Schaller
>> <hns@computer.org> wrote:
>>>
>> [ snipped.. ]
>
> [reinserted to have the real context]
>
>>>> There was, in fact, some discussion on these lines.  There were
>>>> postings to the list about swift when the language was first
>>>> announced.   The decision at that time was to write one if Apple
>>>> didn’t open theirs.
>
>>>
>>> I remember some discussion but wasn’t aware that such a decision was taken.
>>
>> That's because I'm doing it because I am interested in doing it.   I'm
>> not sure that we needed a discussion or decision by committee on this.
>
> You can of course always decide what you do privately (and I do the same).
> IMHO it is a little different when a project is represented.

Yes, I agree that I should be able to do what I want.  I, however, was
unaware that I was representing the GNUstep project in this case. I
never said "we" as a project were working on it or that it was being
done by the GNUstep project as I didn't feel as though I should do
that as I don't see myself as having the power to speak for the
actions of others.  It was, however,  made very clear that I am doing
it because I feel it is the right thing to do.  While I wasn't
explicit about it being part of GNUstep I made it clear that it is
very important to GNUstep on more than a few occasions.

For the record, I still don't think that it's fair to say that I
should have asked permission since I already did on the list months
ago.  So, I'm, frankly confused, but this discussion, however, is
unproductive.

>> Here was the announcement of our position, which I shared with the
>> list:
>>
>> http://heronsperch.blogspot.com/2014/06/gnusteps-position-on-swift.html
>
> I apparently missed that. Wetware shows exponential decay of information.
> Unless it is refreshed regularily… This is what we engineers tend to leave
> to “marketing people”.

LOL, indeed.

>>
>>> It looks like a “I, GC” project rather than a “we, GNUstep”. So you should 
>>> not
>>> be astonished about some reactions here.
>>
>> Seriously?  And here I was under the impression that when I say
>> something is for this project, then it is.  What other reason would I
>> have for doing it?   We have soooo much stuff in our repository, does
>> it seem appropriate to put a compiler in there as well?  I mean if you
>> guys think it's appropriate to put it there on top of everything else,
>> I certainly can if that would make you feel more comfortable.  I know
>> that it would facilitate people helping me with it as we wouldn't have
>> to go through the issues of adding people to the repo at
>> source.ind.ie.
>
> That is indeed an argument to make it part of GNUstep. Almost nobody
> knows these ind.ie activities - while GNUstep is known (I don’t know the
> number of subscribers on this list but it must be many).

I will place a copy in the GNUstep repo, in that case.

>>
>> I am, honestly, astonished with how good intentions can be stretched
>> and distorted by others to be something else.    What I don't
>> understand, quite frankly, is that when I first joined this project
>
> which project are you talking about? GNUstep or Phoenix?

The GNUstep project as we are on the GNUstep list. :)

>> we
>> were all very much in the spirit of doing things that we enjoyed.
>> Lately it seems like everyone has to go through committee and I have
>> to tell you I'm getting very very tired of that approach.  Mainly
>> because it hasn’t worked very well for us.
>
> My POV on this is that it does not need a committee but developers who
> tell the group (represented e.g. by the gnustep lists) what they plan to do
> and why - (but only if they want help and support from the community).
>
> And listen to comments and suggestions from peers. This is not a decision
> committee (which is IMHO only needed if it is about distributing money).

Agreed with respect to the money part.

> But a lively community.
>
> Riccardo, Fred and myself did have several such workshops (and sometimes
> others joined as well). These were very fruitful moves forward.

I heard about the workshops.   Very cool.

> Call this team a “development committee” instead of “decision committee”
> and it has worked very well for us (and fixed many bugs).

As far as I'm aware I was telling people what I planned to do and why.
This is why I posted to the list.  The fact that no one objected led
me to believe that no one had a problem with it.

> <ignore>
<DELETED SINCE IGNORING IT WAS REQUESTED>
> </ignore>
>
>> [snipped]
>>>> Swift, as I see it, is important for our future.  Also, I wasn't sure
>>>> if it was a good idea to put it into GNUstep's repo.  I may still put
>>>> a version of it there if needed.
>>>
>>> This makes me even more puzzled. Are there two versions planned?
>>
>> I can have the same code in two places.   This is not a new concept.
>>
>>> Anyways it is a good initiative.
>>
>> Thanks, at least one thing positive here.
>
> Let me add some more questions to better understand the details of the
> Phoenix project. So that I am enabled (and maybe others) to positively
> contribute on the technical side:
>
> * what is the target of the compiler output? I could imagine Obj-C,
>    Assembler, C++, Java or JavaScript but don’t know.

Currently it's Objective-C, but I would like to move to LLVM IR.

> * could you take the AST code from the ObjCKit.framework of mySTEP?

Yes, I would.  Is it under GPL/LGPL?

> * could you make it compatible to use the same pipeline, i.e. make Phoenix
>   a frontend for a common AST framework/library and backends?

Certainly.

> * what is the rationale to write it in Obj-C if Swift tries to supersede it?

What other language would you suggest.  I selected Obj-C since it is
the language I know the best.

> * what is the problem with lex/bison (I didn’t understand David’s concerns)?

The bison/lex parser generator/lexicographical scanner don't generate
code which is easily reusable and they don't report errors very well.
This is one of the principal reasons why GCC moved away from using
bison/lex and why LLVM has never utilized them.    They are certainly
still useful, but they don't make things much easier in the long run,
so I understand his objection to it.

The reason I chose it is for two main reasons: 1) I have used bison
extensively in the past, so I know it very well..  2) the grammar.y is
from a project known as swift2js which is a transpiler that compiles
swift to JS code.  It used a scraper to pull the grammar directly from
Apple's documentation.  This has the advantage of always being up to
date and easy to regenerate.

The alternative to using these technologies is to write a hand-written
recursive descent parser, which I've also done before when I wrote the
parser for Gorm.   The disadvantage is obvious... it's harder and
slower and can't be automatically regenerated when/if the language
changes.

> BR,
> Nikolaus
>

Thanks GC

-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com