Подскажите ЯП.

у плюсов тоже нет: внезапно, всё приводится к void*, а больше ни для чего base class не нужен

ну, ещё base class нужен для горожения синтаксиса с килограммами ненужных конструкций, это да, но топик-то про синтаксический сахар

Семантически разные вещи: если первое — то же, что и 1 + 1 + 2 в J, то второе — аналог +/ 1 2 3.

ты не понял

пролог с его синтаксисом парсился реплом лиспа т.е хочеш безскобочек макрами обмазывайся и вперёд.

ты опять не понял.

модификация родителя ( в части добавления полей) - вообще не требует пересборки детей - отчасти от того что трансляция отложена и делается тока когда НАДО - отчасти от того что в жабке не регламентируется эталонное расположение полей у обьекта.

чем примечательны тулзы sam|acme - наличием компактного языка управления и расширяемостью :)

Будь у sam управление курсором стрелками, хоткеи и возможность перейти к вводу команд одной клавишей — цены бы ему не было.

хочеш безскобочек

я не без скобочек хочу, я без этого хочу:

макрами обмазывайся

парсился реплом лиспа

какой именно лисп?

я очень рад, но мне это не нужно, вопрос в топике про синтаксический сахар, а не про удобства сборки проекта

sam давно в сырцах можно «чистую комнату» запилить со своими свестелками|важными_добавками

думаю что как минимум редактор (всё+курсорчик) с mit-лицензией можно на выходе получить. вперёд.

зы. про vim - не нуна.

да чхать на скобочки, чему они там изоморфны, это просто пример того от чего в лиспе не избавиться

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

вопрос не в этом: вопрос в том, как в лиспе избавиться от функций, макросов и префиксной нотации?

А зачем от них избавляться? Префиксная нотация и функции вообще везде есть.

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

Как и в практически любом языке программирования (кроме эзотерического говна), да.

не пользоваться ими, ваш кэп

Ну так и в лиспе не пользуйся.

требует для записи больше символов, чем 1+1+2, этого достаточно

Достаточно для чего?

ну если пропатчить ридер лиспа для парсинга некоторых инфиксный и многоарных операций/операторов - ага.

Да там парсить нечего. 30-строчный макрос - и вот тебе инфиксные операторы.

Лево/право и голова/остальное - семантически сильно разные вещи.

Нет, не разные.

Ну не используй макросы, кто тебе мешает? Вон архимаг пишет на CL без макросов, почитай, и ничего.

http://paulgraham.com/diff.html

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

Так, для начала, давайте уяснним: я правильно понимаю, что вы позиционируете, в частности, racket как универсальный язык, который является надмножеством практически над любым другим языком? Т.е., вот это, в теории, может быть валидной конструкцией на racket, если я напишу на нём соотв. языковой модуль:

while a < b {

do_something(a);
do_something(b);

}

Я правильно вас понял?

вы позиционируете

Так авторы позиционируют.

Я правильно вас понял?

Примеры кода на racket:

#lang datalog

edge(a, b). edge(b, c). edge(c, d). edge(d, a).
path(X, Y) :- edge(X, Y).
path(X, Y) :- edge(X, Z), path(Z, Y).
path(X, Y)?

#lang sml

structure fact =
    struct
        fun factorial n = let
            fun fac (0, acc) = acc
            | fac (n, acc) = fac (n-1, n*acc)
        in
            if (n < 0) then raise Fail "negative argument"
            else fac (n, 1)
        end
    end

#lang scribble/base
 
@title{On the Cookie-Eating Habits of Mice}
 
If you give a mouse a cookie, he's going to ask for a
glass of milk.
 
@section{The Consequences of Milk}
 
That ``squeak'' was the mouse asking for milk. Let's
suppose that you give him some in a big glass.
 
He's a small mouse. The glass is too big---way too
big. So, he'll probably ask you for a straw. You might as
well give it to him.
 
@section{Not the Last Straw}
 
For now, to handle the milk moustache, it's enough to give
him a napkin. But it doesn't end there... oh, no.

Вот еще кстати:

#lang honu

require prefix xml_ xml;
require "linq.rkt";

class Xml(data){
  Descendants(name){
    [new Xml(element): element = find_descendants(data, name)]
  }

  Element(name){
    new Xml(get_element(data, name))
  }

  Value(){
    get_text(data)
  }

  getData(){ data }
}

function read_xml(){
  xml_permissive_xexprs(true)
  xml_xml_to_xexpr(xml_document_element(xml_read_xml()))
}

function loadXml(file){
  withInputFromFile(file){
    new Xml(read_xml())
  }
}

function starts_with(start, what){
  substring(what, 0, string_length(start)) string_equal start
}

var xml = loadXml("test.xml")
printf("xml ~a\n", xml)
printf("data: ~a\n", xml->getData())
printf("table1: ~a\n", xml->Descendants("Table1"))

struct test{name, address}

var addresses = linq from add in xml->Descendants("Table1")
                     where true
                     orderby add->Element("familyName")->Value()
                     select test(add->Element("familyName")->Value(),
                                 add->Element("address")->Value())

printf("addresses ~a\n", addresses)

for add in addresses do {
  printf("name ~a address ~a\n", add.name, add.address)
}

for xs in linq from foo in xml->Descendants("Table1")
               where starts_with("x", foo->Element("familyName")->Value())
               select foo->Element("familyName")->Value() do {
  printf("only x: ~a\n", xs)
}

ну, если дело обстоит таким образом, то конечно, racket несомненно заслуживает ознакомления, в таком случае, он станет 2-м языком, с которым я ознакомлюсь после скалы, а там уже начну выбирать, что удобнее

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

Во-первых, вокруг исторически сформировавшихся языков существует определённая инфраструктура: готовые реализации подсветки синтаксиса, автодополнения и прочего; сам язык может оригинальным и напишите, а библиотеки к нему откуда возьмёте? из других языков, ага, с соглашениями и недостатками присущими тем языкам

Во-вторых, кто кроме вас, будет понимать ваш же ЯП? готовый алгоритм уже не нагуглишь

В-третьих, а какова скорость компиляции такого ЯП? и как организована заточка оптиммизации под ваш самописный внутри_рэкета язык?

в-четвёртых, идеальный язык в теории имеет вполне определённый синтаксис, ибо эргономика, например циклы while должны, в идеале записываться только так и никак иначе:

while a < b {

do_something(a)
do_something(b)

}

//на крайняк так:

while a < b {

(do_something a)
(do_something b)

}

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

Во-первых, вокруг исторически сформировавшихся языков существует определённая инфраструктура: готовые реализации подсветки синтаксиса, автодополнения и прочего;

Оно будет работать для всех дслей.

а библиотеки к нему откуда возьмёте?

Библиотеки хост-языка

Во-вторых, кто кроме вас, будет понимать ваш же ЯП?

А и не надо, чтобы кто-то понимал. Этот язык будет использоваться только в рамках одной единственной задачи. А скорее - части этой задачи. На практике никто не пишет именно новые полноценные языки - пишут ДСЛи.

В-третьих, а какова скорость компиляции такого ЯП?

it's depend. Но вообще не существенно дольше кода на самом хост-языке, если реализовано все правильно.

и как организована заточка оптиммизации под ваш самописный внутри_рэкета язык?

Он раскрывается в код на Racket и, соответственно, не может быть быстрее, чем Racket.

но при этом они мешают парсить код человеку

Ничего подобного. Они в этом случае помогают парсить код, т.к. отделяют для глаза условие от ключевого слова. И, да, поскольку написание кода - это даже не проценты, а десятые и сотые проценты работы программиста, то даже если пистаь надо в 10 раз дольше - это несущественная цена даже по сравнению с небольшим выигрышем в читабельности, который дают скобки.

Точки с запятой тоже не нужны.

Очень даже нужны. Мне в скале, например, сильно не хватает их.

Мне в скале, например, сильно не хватает их.

Кто мешает ставить?

это в CL-то нет ООП?

А зачем оно там?

кури про циклы с выходом из середины ,

ну и циклы с пред /пост действием ( частный случай - питоновская else-ветка у циклов)

и что будет? я и в плюсах умею из середины цикла брейком выходить

Оно будет работать для всех дслей.

правильно, поэтому предметно-ориентированные языки сливают языкам общего назначения, если предметная область применения затрагивается не слишком часто

Библиотеки хост-языка

и поимеете все недостатки хост-языка, не пронаследовав все его достоинства

А и не надо, чтобы кто-то понимал. Этот язык будет использоваться только в рамках одной единственной задачи.

В рамках этой задачи может потребоваться реализовать известный алгоритм и вместо того, чтобы заюзать готовое решение, придётся городить велосипед

не может быть быстрее, чем Racket.

вопрос: насколько просядет производительность, по сравнению с самим Racket: для С есть полно языков, которые раскрываются в его код, но ни один из них и близко не подобрался к эффективности С-шки

Но вообще не существенно дольше кода на самом хост-языке, если реализовано все правильно.

вообще-то, должно, если мы говорим о более-менее далёком уходе от хост-языка, впрочем, это проблема проявится только на крупных проектах, а в контексте треда это не рассматривается

т.к. отделяют для глаза условие от ключевого слова.

правильно, но если есть подсветка синтаксиса, условие уже будет отделено, а дефолтные скобки помешают парсить внутренние скобки, если таковые будут присутствовать

речь про «идеальный» эталонный синтаксис цикла ( и вайла в частности) как тогда(если вообще) выделять выходы из середины - ведь есть лица считающие , что выход(ы) из середины должен быть как то описан(обьявлен) - в заголовке цикла

А зачем оно там?

а зачем оно в других языках с поддержкой ООП?

правильно, поэтому

Почему, по-этому? Потому что подсветка будет работать для всех дслей?

и поимеете все недостатки хост-языка, не пронаследовав все его достоинства

С чего вдруг? Не могу придумать ни одного недостатка хост-языка, который наследуется из-за использования библиотеки. Более того - у вас вообще нету никакого способа узнать, нах ост-языке или на дсле написана библиотека, если вы не загляните в исходники.

В рамках этой задачи может потребоваться реализовать известный алгоритм и вместо того, чтобы заюзать готовое решение, придётся городить велосипед

Ну и не надо велосипеда, используйте известный алгоритм. Кто вам мешает?

вопрос: насколько просядет производительность, по сравнению с самим Racket:

Когда хост-язык достаточно выразителен (а в Racket это так) то языковые конструкции раскрываются достаточно «прямо». Ну то есть как я уже сказал - при правильной реализации проседание будет пренебрежимо малым.

вообще-то, должно

Нет, не должно. У вас и в обычном коде на Racket макросов дохрена и вклад вносимый дслем будет не слишком существенен.

правильно, но если есть подсветка синтаксиса, условие уже будет отделено

Но так оно отделено еще лучше.

а дефолтные скобки помешают парсить внутренние скобки, если таковые будут присутствовать

Нет, не мешают.

А это не принято в скале, точки с запятой ставить. Такие дела.

А это не принято в скале, точки с запятой ставить.

Ну ошибок синтаксиса-то не будет, так что если не хватает - ставь. В некоторых случаях, между прочим, точка с запятой там обязательна.

едь есть лица считающие , что выход(ы) из середины должен быть как то описан(обьявлен) - в заголовке цикла

нет, такой подход неверен — лишняя инфа в заголовке ни к чему

Потому что подсветка будет работать для всех дслей?

а как насчёт автодополнения?

Более того - у вас вообще нету никакого способа узнать, нах ост-языке или на дсле написана библиотека, если вы не загляните в исходники.Более того - у вас вообще нету никакого способа узнать, нах ост-языке или на дсле написана библиотека, если вы не загляните в исходники.

ну если библиотека состоит из одних ф-ций — да, а если там классы, шаблоны и много других интересных вещей? Сумеете ли вы грамотно состыковать 2 разных дсл внутри рэкета, др. словами?

Ну и не надо велосипеда, используйте известный алгоритм. Кто вам мешает?

то, что внутри самописного дсля этот алгоритм может внезапно сильно поменять форму реализации

Когда хост-язык достаточно выразителен (а в Racket это так) то языковые конструкции раскрываются достаточно «прямо».

ага, до тех пор, пока далеко от хост-языка не ушли

У вас и в обычном коде на Racket макросов дохрена

ну если только так

Нет, не мешают.

в синтаксисе лиспов - почти не мешают, в традиционном синтаксисе - вполне мешают

а как насчёт автодополнения?

А какая разница?

ну если библиотека состоит из одних ф-ций — да, а если там классы, шаблоны и много других интересных вещей? Сумеете ли вы грамотно состыковать 2 разных дсл внутри рэкета, др. словами?

Экспортировать из модуля можно только идентификаторы. А они везде - идентификаторы, в любом дсле. Может приведешь более конкретный пример, в чем ты видишь проблему?

то, что внутри самописного дсля этот алгоритм может внезапно сильно поменять форму реализации

Не понял. Еще раз - зачем тебе вообще писать этот алгоритм на самописном дсле, если у нас уже есть готовая, невелосипедная реализация?

ага, до тех пор, пока далеко от хост-языка не ушли

Дальность ухода совершенно несущественна.

в синтаксисе лиспов - почти не мешают, в традиционном синтаксисе - вполне мешают

Противоречишь сам себе. В синтаксисе лиспа _еще больше_ скобок, которые теоретически могут мешаться. Если мешается в традиционном - в лиспе должно мешаться еще сильнее. Но на практике ничего не мешается.

циклы Дейкстры не?

у цикла (конкретно while) -в «заголовке» инвариант исполнения - так шта если используем выход из середины по некоторому условию то цикл завершается даже когда инвариант всё ещё «ок» - что несколько майндбайдинг.

Может http://dlang.ru/Why-D-is-Better подойдет? Вроде бы все условия выполняются.

я смотрел D и ничего особенного там не обнаружил: да, он интересен, но не более чем С++, сборка мусора по дефолту меня не впечатляет, т.к. никогда в ней не нуждался, особых фич там не добавили и функционального программирования как не было так и нет, зато D ощутимо сливает плюсам в производительности и даже, местами, шарпу под линуксом, что сводит на нет смысл D

нет

вообще-то выход из цикла прекрасно читается благодаря подсветке синтаксиса: это во-первых, а во-вторых детали реализации цикла при беглом просмотре вообще привлекать внимание не должны, даже основное условие, по большому счёту: если я знаю в общих чертах, что цикл делает, мне до фонаря, что внутри и как он реализован: тогда нужно просто пропускаю «парсинг» цикла, вместе с условием, если же, положим, не уверен, что цикл работает правильно, тогда мне всё равно вчитываться

наоборот, чем проще и поверхностнее отражает суть работу цикла условие в скобках, тем проще его читать, и тем больше от него толка в заголовке

Я бы посоветовал GO, правда там слабо выражено ООП.

нормально там выражено обьектное программирование

наследования намеренно нет

остальное - полиморфизм методов (через интерфейсы), сокрытие(через модули) , инкапсуляция ( чере- составные типы)

ну и мультиметоды вполне логично через интерфейсы тоже прикручиваются.

нормально там выражено обьектное программирование
наследования намеренно нет

/0

А какая разница?

очень простая, если я запилю своё, уличное, ООП, под него же автоматом автодополнение не сгенерится

Экспортировать из модуля можно только идентификаторы. А они везде - идентификаторы, в любом дсле. Может приведешь более конкретный пример, в чем ты видишь проблему?

например, допустим, реализована шаблонная система, как в плюсах, ей можно будет грамотно состыковать?

Дальность ухода совершенно несущественна.

как показывает пример с эйфелем и сишкой, не всё так просто, лан, в любом случае, поковыряю, посмотрю, как оно

Противоречишь сам себе. В синтаксисе лиспа _еще больше_ скобок, которые теоретически могут мешаться. Если мешается в традиционном - в лиспе должно мешаться еще сильнее. Но на практике ничего не мешается.

В лиспе всё проще, ибо синтаксис примитивет, префиксная нотация. А в тех же яве, плюсах, шарпе, например, запись операторов встречается префиксная, инфиксная и постфиксная. Плюс пачка приоритетов, поэтому круглые скобки очень сильно влияют на восприятие.

Ладно, с рэкетом я уже начал знакомиться, лучше скажите как там у него с биндингами к Qt.

очень простая, если я запилю своё, уличное, ООП, под него же автоматом автодополнение не сгенерится

Под автодополнением подразумевается нечто вроде объект.метод? Ну так в динамически типизированном языке такое автодополнение в принципе работать не будет.

например, допустим, реализована шаблонная система, как в плюсах, ей можно будет грамотно состыковать?

Что значит «грамотно состыковать», можно на примере? В чем по-твоемубудет проблема со стыковкой?

лучше скажите как там у него с биндингами к Qt.

Никак.

Ну так в динамически типизированном языке такое автодополнение в принципе работать не будет.

это печально. кстати, рэкет же спретензий на статичность путём костылей

Что значит «грамотно состыковать», можно на примере? В чем по-твоемубудет проблема со стыковкой?

ладно, уже не важно, уже начал смотреть racket, сам посмотрю

Никак

тоже печально, ну хоть к гтк биндинги есть?

кстати, рэкет же спретензий на статичность путём костылей

Ну если у тебя дсл статичный, то можешь написать 20-строчник на елиспе и будет атводополнение

тоже печально, ну хоть к гтк биндинги есть?

Где-то внутри самого racket - да, есть, т.к. ракетовский гуй на линуксе сделан через гтк.

Делегирование is fine too.

ты вообще различаеш объектно-ориентированное-программирование ( т.е переориентирование процедурных языков уже имевших в своём составе составные типы(записи/структуру)(как атд) и процедуры(как абстракция кода) - их увязывание друг с другом (для уменьшения общей сложности - что бы иметь гарантии что вот эти данные читаются/пишутся из/в ограниченного числа мест ) и прикручивание к этому наследования обещающего менеджерам экономию через повторное использование) и объектное-программирование( где есть объекты и они взаимодействуют друг с другом через те или иные протоколы( либо передача управления в однонитевых - синхронных , либо через посылку «сообщений»(в этом случае рантайм может быть как одноисполняющим так и конкрурентным))

го как раз позволяет через интерфейсы и каналы получить csp

инкапсуляция, наследование, полиморфизм