Мое видение того как можно разработать новый язык для дотнет - Открытые проекты

Здравствуйте, Glоbus, Вы писали:

G>Твое видение того как можно разработать новый язык для дотнет -> А на кой ляд он нужен. какие в нем будут преимущества перед уже существующими. Для каких задач будет применятся. Или это просто милое упражнение по теории компиляторов после прочтения книжки Ахо. Не сочтите вышеприведенную фразу за оскорбление — не хотел вас обидеть, клянусь — но действительно непонятна цель. То есть какждый язык для чего-то нужен. Как пример: пролог, лисп, С и все остальное. У каждого своя ниша. А какую нишу ваш займет?

здесь

Здравствуйте, Dr_Sh0ck, Вы писали:

D_S>Здравствуйте, Glоbus, Вы писали:

G>>Твое видение того как можно разработать новый язык для дотнет -> А на кой ляд он нужен. какие в нем будут преимущества перед уже существующими. Для каких задач будет применятся. Или это просто милое упражнение по теории компиляторов после прочтения книжки Ахо. Не сочтите вышеприведенную фразу за оскорбление — не хотел вас обидеть, клянусь — но действительно непонятна цель. То есть какждый язык для чего-то нужен. Как пример: пролог, лисп, С и все остальное. У каждого своя ниша. А какую нишу ваш займет?

D_S>здесь

Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2. Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.

Здравствуйте, Glоbus, Вы писали:

G>Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2. Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.

Не согласен. Во-первых этих вещей в спецификации нет. И врядли будут.
А что что в МС не лохи, это бесспорно так.
Но то, что в шарпе дейтсвительно отсутствуют некоторые удобные вещи, в принципе никак не конфликтующие с идеологией шарпа и CLR в целом, это факт.
И ведь если этого не сделано, это ж не значит, что МС — лохи

Если ты еще этого не заметил, то обращаю твое внимание, на факт, что МС порой ведет очень своеобразную политику...

Здравствуйте, Dr_Sh0ck, Вы писали:

D_S>Здравствуйте, Glоbus, Вы писали:

G>>Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.

D_S>И ведь если этого не сделано, это ж не значит, что МС — лохи

D_S>Если ты еще этого не заметил, то обращаю твое внимание, на факт, что МС порой ведет очень своеобразную политику...

Как хотите, а для меня очевидно, что отсутствие параметров по умолчанию в Си-шарпе — явный признак заговора против человечества!

Да здравствует ИМХО!

Вот исходные послки http://www.rsdn.ru/Forum/Message.aspx?mid=471659 там не полный фича-лист. Но в подветках можно найти и остальные расширения.

Вот эта тема это расширенное (но не окончательное) видение пункта 3 из первой ссылки.

... << RSDN@Home 1.1.2 beta 1 >>

Здравствуйте, Glоbus, Вы писали:

G>Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2.

1. Потому что их нет в Шпрп 2.
3. Потому что когда МС их реализует рак на горе свистеть разучится.

G> Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.

Это их проблемы. И лично я не хочу разгребать их проблемы.

... << RSDN@Home 1.1.2 beta 1 >>

Здравствуйте, VladD2, Вы писали:

Какая жалость, что в C# нельзя применять атрибуты к фрагментам кода. Тогда бы все эти модные ключевые слова вводились бы вот так:

void MySomeHack(int i)
{
  i++;
    [msil]
    {
      ldloc.0
      ldloc.0
      add
      ...
    }
    ...
        [Atomic] // == transaction 
        {
          //some code
        }
        
        [If(conditionExpression)]
        {
        }
        [Else]
        {
        }
}

... << RSDN@Home 1.1.2 beta 2 >>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:

S>Какая жалость, что в C# нельзя применять атрибуты к фрагментам кода. Тогда бы все эти модные ключевые слова вводились бы вот так:

А между прочим прикольно, по крайне мере не надо писать __msil {}, да и расширяемость. Кстати, Андрей, мы говорили о запоминании имен, опять же конфликты имен. Вдруг кодогенератор использует несколько "ItemType" слов. А я в коде задействую только несколько, а другие будут мои, но совпадать с кодогенерационными.

Может я чего не так понял, но по моему это

... << RSDN@Home 1.1.0 stable, слушаю — звезды >>

Здравствуйте, Sinclair, Вы писали:

S>Какая жалость, что в C# нельзя применять атрибуты к фрагментам кода. Тогда бы все эти модные ключевые слова вводились бы вот так:

Для написания кода нужны ключевые слова. Атрибуты лучше подходят для управления генерацией кода. Использование их вместо ключевых слов приведёт только к замусориванию языка.

Здравствуйте, IT, Вы писали:
IT>Для написания кода нужны ключевые слова.
Это верно.
IT>Атрибуты лучше подходят для управления генерацией кода.
Тоже верно.
IT>Использование их вместо ключевых слов приведёт только к замусориванию языка.
Просто атрибут msil — неудачный пример.

... << RSDN@Home 1.1.2 beta 2 >>

Здравствуйте, Sinclair, Вы писали:

IT>>Использование их вместо ключевых слов приведёт только к замусориванию языка.
S>Просто атрибут msil — неудачный пример.

Ключевое слово __msil ещё более неудачный

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:

S>Какая жалость, что в C# нельзя применять атрибуты к фрагментам кода.

Эээ... Амы то тут причем? Ничего не стоит выпарсивать атрибуты и выкидывать из из кода. Вопрос только в читабельности и поддержке студией. На такой код студия будет материться и комплит-ворд не будет работать.

S>

S>        [If(conditionExpression)]
S>        {
S>        }
S>        [Else]
S>        {
S>        }
S>}
S>

А зачем тут атрибуты? Это и так прокатит. Если будет метапеременная, то ее ничего не стоит обработать:

[MetaVar]
bool isCondition = MetaConditionCall();
...
if (isCondition)
{
  // Если isCondition == true - этот блок скомпилируется...
}
else
{
    // Если isCondition == true - этот блок будет выброшен перед компиляцией...
}

Вместо атрибутов можно использовать синтаксис обычного кода. Нам ничего не стоит распознать в коде некотрый метод как атрибут. Но опять же проблемы с понятностью таких конструкций:

...
msil();
{
 ...
}

Что же касается мсил-а, то его можно будет получить только в полноценном компиляторе. Препроцессор этого не позволит.

... << RSDN@Home 1.1.2 beta 1 >>

Hello, "Sinclair"

> IT>Использование их вместо ключевых слов приведёт только к замусориванию языка.
> Просто атрибут msil — неудачный пример.

Наверное, идея с добавление msil вставок сама по себе не самая лучшая.
Хотя, возможно, использования нескольких языков в рамках одного compilation unit была-бы очень удобной.
Все задачи одним языком не охватишь. Например, C# и VB.NET | JScript — первый достаточно удобен и традиционен, а во втором есть возможность использования позднего связывания. Конечно, в С# можно использовать reflection, но это избыточно и не удобно.
Собственно, эта задача решается и сейчас, но в целом, когда на вход компилятора подается много-языковой код, а на выходе мы имеем единую сборку — это удобно. Для того-же msil можно использовать концепцию partial классов из C# — класс описывается в нескольких файлах, а каждый из них уже может быть представлен своим языком.

Posted via RSDN NNTP Server 1.8 beta

Hello, "VladD2"

> Итак. Сначала о средствах разработки...
>

Вот о средствах разработки. Может стоит определить в целом программу максимум и программу минимум?
Из программы минимум — на первом этапе можно получить гибкое средство рефакторинга исходного кода — получение метрик, проверка на best practices.
Да, в Whidbey уже что-то подобное встроено, но всегда есть возможности для улучшения.

По крайней мере это может привлечь людей с разными целями — кому-то достаточно рефакторинга, а кто-то будет продолжать разрабатывать язык.

Posted via RSDN NNTP Server 1.8 beta

Здравствуйте, TK, Вы писали:

TK>Вот о средствах разработки. Может стоит определить в целом программу максимум и программу минимум?

Вроде бы и так определились. Программа максимум — это компилиятор.

Программа минимум... Да нет ее. Есть этапы. На первом этапе создание парсера в некое синтаксическое дерево (гибрид рефлекшода и абстрактного синтаксического дерева (AST)). Причем как отдельного компонента. Далее разработка АПИ модификации этого дерева. Ну, а там уже не за горами сначала препроцессор, а потом и компилятор.

TK>Из программы минимум — на первом этапе можно получить гибкое средство рефакторинга исходного кода — получение метрик, проверка на best practices.

Все это можно делать как ответвление от проекта сразу после создания парсера в дерево и АПИ по модификации этого дерева.

TK>Да, в Whidbey уже что-то подобное встроено, но всегда есть возможности для улучшения.

В Видби как всегда парсер скрыт, доступен не польностью и как всегда только вместе со студией.

TK>По крайней мере это может привлечь людей с разными целями — кому-то достаточно рефакторинга, а кто-то будет продолжать разрабатывать язык.

Возможно. Нужно более конкретно обрисовать кортину. Включить туда бенефиты, фичи, и план разработки с промежуточными этапами.

... << RSDN@Home 1.1.2 beta 1 >>

Здравствуйте, TK, Вы писали:

TK>Наверное, идея с добавление msil вставок сама по себе не самая лучшая.
TK>Хотя, возможно, использования нескольких языков в рамках одного compilation unit была-бы очень удобной.

Одно другому не противоричит. Идея с использованием нескольких языков здравая. Но сложно реализуемая. Для каждого языка нужен свой парсер.

МСИЛ же доступен, да и нужен только в компиляторе. Пока что про него нужно забыть... до проры... до времени...

TK>Все задачи одним языком не охватишь. Например, C# и VB.NET | JScript — первый достаточно удобен и традиционен, а во втором есть возможность использования позднего связывания. Конечно, в С# можно использовать reflection, но это избыточно и не удобно.

То что обсуждется здесь — это компайл-тайм фичи. Использовать VB.NET | JScript в ранмйм можно и так.

TK>Собственно, эта задача решается и сейчас, но в целом, когда на вход компилятора подается много-языковой код, а на выходе мы имеем единую сборку — это удобно. Для того-же msil можно использовать концепцию partial классов из C# — класс описывается в нескольких файлах, а каждый из них уже может быть представлен своим языком.

Нельзя. Мсил не парсится в общее AST. Он низкоуровневый язык. У него свое AST. Без компилятора его не реализовать. А с компилятором оно делается как неучить уроков.

... << RSDN@Home 1.1.2 beta 1 >>

Hello, "VladD2"
>
> TK>Наверное, идея с добавление msil вставок сама по себе не самая лучшая.
> TK>Хотя, возможно, использования нескольких языков в рамках одного compilation unit была-бы очень удобной.
>
> Одно другому не противоричит. Идея с использованием нескольких языков здравая. Но сложно реализуемая. Для каждого языка нужен свой парсер.
> То что обсуждется здесь — это компайл-тайм фичи. Использовать VB.NET | JScript в ранмйм можно и так.

>

Главное, что-бы можно было подключать парсеры дополнительных языков. Тогда можно будет создавать partial классы написанные на разных языках.
Например — основной костяк класса пишется на C#. А там, где нужно поработать с COM или сделать несколько вызовов через reflection просто приписывается пару метолов на VB.

Posted via RSDN NNTP Server 1.8 beta

Здравствуйте, TK, Вы писали:

TK>Главное, что-бы можно было подключать парсеры дополнительных языков. Тогда можно будет создавать partial классы написанные на разных языках.
TK>Например — основной костяк класса пишется на C#. А там, где нужно поработать с COM или сделать несколько вызовов через reflection просто приписывается пару метолов на VB.

Прямо языков нельзя. Но можно вычленить конкретные блоки и уже их парсить упрощенными парсерами. Упрощенными потму как это не полный парсер, а парсер отдельных лексем. Например функций, классов или частей методов. Если речь идет об отдельных исходных файлах, то это легче. Но опять таки процесса создания полноценного парсера для поддерживаемых языков не обойтись.

... << RSDN@Home 1.1.2 beta 1 >>

Здравствуйте, Dr_Sh0ck, Вы писали:

D_S>Здравствуйте, Glоbus, Вы писали:

G>>Н-да, прилюбопытно. Но я вот думаю, а почему не дождаться того, что МС эти вещи реализует, если они есть в спецификации Шарпа 2. Ваще много философских вопросв. Например почему Мс не реализовал дефолтные параметры в настоящей реализации Шарпа. То же про интерфейсы. Наверное есть на то причины. они там тоже не последние лохи.

D_S>Не согласен. Во-первых этих вещей в спецификации нет. И врядли будут.
D_S>А что что в МС не лохи, это бесспорно так.
D_S>Но то, что в шарпе дейтсвительно отсутствуют некоторые удобные вещи, в принципе никак не конфликтующие с идеологией шарпа и CLR в целом, это факт.
D_S>И ведь если этого не сделано, это ж не значит, что МС — лохи

D_S>Если ты еще этого не заметил, то обращаю твое внимание, на факт, что МС порой ведет очень своеобразную политику...

Старик, не в коем разе не хочу оспаривать все выше сказанное тобой, но мне все-таки интересно. Как дефолтные параметры и их отсутсвие увязывается с политикой МС. Ну или интерфейсы. то есть реально я считаю что в шарпе этих фич нехватает. Но вот вопрос к тебе лично — почему их там нет?

Здравствуйте, Glоbus, Вы писали:

G>Старик, не в коем разе не хочу оспаривать все выше сказанное тобой, но мне все-таки интересно. Как дефолтные параметры и их отсутсвие увязывается с политикой МС.

Я ж не имел ввиду их официальную политику

Я имел ввиду "политику" выпустить продукт побыстрей, а потом дорабатывать его бесконечное количество раз. Временами объявляя об очередно "революции".

G>Ну или интерфейсы. то есть реально я считаю что в шарпе этих фич нехватает. Но вот вопрос к тебе лично — почему их там нет?

ИМХО потому что один из "отцов" решил, что раз с ему они не нужны, они, естессно, не нужны никому.

	От:	Dr_Sh0ck
	Дата:	17.12.03 13:27
	Оценка:

	От:	Glоbus
	Дата:	17.12.03 14:27
	Оценка:

	От:	Dr_Sh0ck
	Дата:	17.12.03 14:35
	Оценка:

	От:	achp
	Дата:	17.12.03 14:43
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	17.12.03 20:29
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	20.12.03 10:45
Оценка:	4 (1) +1

От:	beretta	icq: 138726397
Дата:	20.12.03 14:02
Оценка:

От:	IT	linq2db.com
Дата:	20.12.03 14:47
Оценка:	+1

От:	TK	кывт.рф
Дата:	20.12.03 23:02
Оценка: