Вопрос касается скорее "эргономики синтаксиса языка", чем философии... Два варианта:

int func(int x)

vs

def func(int x) int

Второй вариант немного длиннее, но ИМХО более удобен, в частности, для объявления локальных функций (внутри других функций), т.к. функции однозначно выделяются в коде по первому ключевому слову (что особенно удобно для code outline и прочих фич IDE). Еще этот вариант хорош тем, что красиво реализуются всякие множественые возвращаемые значения и т.п.
Ключевое слово "def" — насколько оно отражает суть понятия "функция"? Например в синтаксисе Go используется ключевое слово "func" (а в паскале вообще "function" и "procedure", но это уже ИМХО перебор)
Также, если это метод класса, вместо "def" можно использовать другие ключевые слова типа override, virtual и т.п. по смыслу.
Еще есть всякие варианты использования между списком аргументов и списком возвращаемых значений специальных символов-разделителей типа : -> => но ИМХО в объявлении обычной функции (не лямбды) они избыточны.
Что думаете?

XC>Вопрос касается скорее "эргономики синтаксиса языка", чем философии... Два варианта:
XC>

int func(int x)

XC>vs
XC>

def func(int x) int

XC>Второй вариант немного длиннее, но ИМХО более удобен, в частности, для объявления локальных функций (внутри других функций), т.к. функции однозначно выделяются в коде по первому ключевому слову (что особенно удобно для code outline и прочих фич IDE). Еще этот вариант хорош тем, что красиво реализуются всякие множественые возвращаемые значения и т.п.
XC>Ключевое слово "def" — насколько оно отражает суть понятия "функция"? Например в синтаксисе Go используется ключевое слово "func" (а в паскале вообще "function" и "procedure", но это уже ИМХО перебор)
XC>Также, если это метод класса, вместо "def" можно использовать другие ключевые слова типа override, virtual и т.п. по смыслу.
XC>Еще есть всякие варианты использования между списком аргументов и списком возвращаемых значений специальных символов-разделителей типа : -> => но ИМХО в объявлении обычной функции (не лямбды) они избыточны.
XC>Что думаете?

Думаю, что не стоит разделять объявление лямбд и "обычных" функций. (в кавычках, потому что лямбды это и есть обычные функции, просто слово другое, синоним)

name = def (int x) int — один, универсальный синтаксис для определения функций в любом скопе: хоть глобальном, хоть внутри другой функции.

def будет расшифровываться либо как DEFine, либо как DEfine Function. В первом случае потребуется объяснить почему кроме функций больше ничего не объявляется ключевым словом def, во втором случае сокращение слишком натянуто, правило по которому составлено сокращение слишком сложное, например, почему не DefinE Function. В обоих случаях "def" довольно слабо отражает понятие "функция".

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

XC>Вопрос касается скорее "эргономики синтаксиса языка", чем философии... Два варианта:

int func(int x)

vs

def func(int x) int

XC>Второй вариант немного длиннее, но ИМХО более удобен, в частности, для объявления локальных функций (внутри других функций), т.к. функции однозначно выделяются в коде по первому ключевому слову (что особенно удобно для code outline и прочих фич IDE). Еще этот вариант хорош тем, что красиво реализуются всякие множественые возвращаемые значения и т.п.
XC>Ключевое слово "def" — насколько оно отражает суть понятия "функция"? Например в синтаксисе Go используется ключевое слово "func" (а в паскале вообще "function" и "procedure", но это уже ИМХО перебор)

Третий вариант был бы ещё лучше:

func f1(x: int): int
...
proc f1(x: int): int

Два разных ключевых слова, func — для чистых функций (без сайд-эффектов), proc — для функций с сайд-эффектами. При желании, можно вынести из множества func ещё более строгое подмножество expr (выражение, в котором отсутствует последовательность вычисления, т.е., «нет операторов “;”», но, возможно, присутствуют let-связи). Понятно, что в норме proc-ы не могут использоваться func-ами и expr-ами, а func-и — expr-ами.

Python-овский def, к примеру, соответствовал бы в такой нотации proc-у, а Python-овская lambda — примерно expr-у (с поправкой на то, что Python не запрещает из expr/lambda вызывать proc/def).

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

H>При желании, можно вынести из множества func ещё более строгое подмножество expr (выражение, в котором отсутствует последовательность вычисления, т.е., «нет операторов “;”», но, возможно, присутствуют let-связи).
а зачем?

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

T>Думаю, что не стоит разделять объявление лямбд и "обычных" функций. (в кавычках, потому что лямбды это и есть обычные функции, просто слово другое, синоним)

T>name = def (int x) int — один, универсальный синтаксис для определения функций в любом скопе: хоть глобальном, хоть внутри другой функции.

Согласен.

Вспоминается Автокод Эльбрус:

_ф32 а_плюс_1 := _функ(_ф64 операция, _ф32 лев, _ф32 прав)(операция(лев, прав)) (_функ(_ф32 a, _ф32 b) (a+b), a, 1);

Но конечно можно было и в более традиционном виде:

% описание константы типа процедура:
_функция вызов(_ф64 операция, _ф32 лев, _ф32 прав)(
операция(лев, прав)
);

% присваивание переменной значения типа "изображение процедуры":
_ф64 сложение :=_функ(_ф32 a, _ф32 b) (a+b);

_ф32 а_плюс_1 := вызов(сложение , a, 1);

Для процедур, не возвращающих значения, использовались ключевые слова _процедура и _проц.

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

T>Думаю, что не стоит разделять объявление лямбд и "обычных" функций. (в кавычках, потому что лямбды это и есть обычные функции, просто слово другое, синоним)

T>name = def (int x) int — один, универсальный синтаксис для определения функций в любом скопе: хоть глобальном, хоть внутри другой функции.

Насчет унифицированного определения в любом скопе согласен (такой унификации кстати вроде бы нет в существующих языках), а лямбды и обычные функции все-же стоит разделять: функции (как глобальные так и локальные) просто описываются, а лямбды — как описываются, так и вызываются в месте своего описания.

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

XC>функции (как глобальные так и локальные) просто описываются, а лямбды — как описываются, так и вызываются в месте своего описания.

Это заблуждение становится весьма распространенным.

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

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

XC>Что думаете?
Хорошо, но сильно нехватает ещё синтаксиса для нескольких возвращаемых значений, и имён к возвращаемым значениям. Может так:

def func(x : int, y : double) (a : string, b : bool)
{
}

Тогда возвращаемые значения можно и в коллекцию складывать, рассматривая как структуры с именами, а можно распаковать каким нить удобным синтаксисом, а можно сразу в следующую функцию передать. Гибкость короче.

А ещё забыт обобщённый возврат функциональных типов (делегатов если угодно), может так:

def func2(x : int, y : double) (a : string, b : bool) (m : decimal) //вернёт функцию принимающую (a,b) и возвращающую на них (m)
{  
}

def func3 = func2(1, 1.0);

func3( | /*<- тут умный автокомплит подскажет нам что func3 принимает параметры a : string, и b : bool, и возвращает m : decimal */ )

// ну или даже так:
Console.WriteLine( func3(1, 2.0)("aaa", true) );

В общем нужно параметры приравнять к каким-то структурным типам, и обобщить это всё. Тогда Linq/Функции/Делегаты/Структуры/Встроенные типы, станут чем-то одинаковым и очень удобным.

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

XC>Вопрос касается скорее "эргономики синтаксиса языка", чем философии... Два варианта:
XC>

int func(int x)

XC>vs
XC>

def func(int x) int

XC>Второй вариант немного длиннее, но ИМХО более удобен,

На самом деле второй вариант не логичен. Параметры обявляются в С-ишном стиле, а возвращаемое значение — нет.
Тогда нужно уж быть последовательным и выбрать стиль:

def int func(int x) // стиль C

или:

def func(x int) int // стиль Go

Во втором случае так же имеет смысл определять переменные так же через def:

def x int = 1; // переменная с явно указанным типом
def x = 1; // с выводом типов

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

Ну, а на мой взгляд очень не плох немерловый стиль:

def func(x : int) : int // стиль Nemerle
def x : int = 1; // переменная с явно указанным типом
def x = 1; // с выводом типов

который является смесью ML-ного и С-ишного стиля (от последнего взята скобочная нотация).
Приятной особенностью такого подхода является то, что двоеточие четко указывает, что далее идет описание типа. Такой код очень хорошо читается взглядом, так как не требует распознавания сложных паттернов. Кроме того это позволяет добавить в язык так называемое уточнение типов. Код "выражение : тип" можно использовать в любом месте кода, чтобы указать компилятору что за тип должен быть у выражения. Это очень удобно для языка поддерживающего вывод типов (к каковым на сегодня уже относится C# и почти относится C++). Получается эдакая стройная универсальная система.

Когда я в первый раз увидел Nemerle, то меня покоробило использование такой "паскалевской" нотации. Но со временем я понял, что это действительно удобно и хорошо (и что это не паскалевская, а ML-ная нотация ).

XC> в частности, для объявления локальных функций (внутри других функций), т.к. функции однозначно выделяются в коде по первому ключевому слову (что особенно удобно для code outline и прочих фич IDE).

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

Во-вторых, такое упрощение жизни парсера не особо то нужно в наши дни. Даже не очень продвинутые алгоритмы парсинга с легкостью выделяют конструкции по "заглядыванию вперед". Для рукописных парсеров или основанных на алгоритмах поддерживающих синтаксические предикаты (ANTLR, PEG и т.п.) это вообще не проблема. К тому же, как было указано в "во-первых" ключевое слово все же не всегда позволяет выявить функцию. Тогда уж лучше использовать префикс fun (или его аналог), чтобы четко видеть, что определяется функцию.

XC>Еще этот вариант хорош тем, что красиво реализуются всякие множественые возвращаемые значения и т.п.

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

def int * string func(int x) // стиль C

XC>Ключевое слово "def" — насколько оно отражает суть понятия "функция"?

Да не на сколько.

XC>Например в синтаксисе Go используется ключевое слово "func" (а в паскале вообще "function" и "procedure", но это уже ИМХО перебор)

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

x => x * x
(x, y) => x * y

или Haskell-евский:

\x -> x * x
\x y -> x * y

стиль.
Для С-подобного языка (со скобочной нотацией) лучше подойдет C#-пный стиль (можно с использованием оператора ->, если он еще не занят в языке), так как список параметров можно рассматривать как кортеж (что делает лямбды очень стройными).

XC>Также, если это метод класса, вместо "def" можно использовать другие ключевые слова типа override, virtual и т.п. по смыслу.

В смысле? Вместо "def" или вместе с "def"?

XC>Еще есть всякие варианты использования между списком аргументов и списком возвращаемых значений специальных символов-разделителей типа : -> => но ИМХО в объявлении обычной функции (не лямбды) они избыточны.

Ну, почему? В принципе неплохим решением является унификация лямбд и функций.

()     => z     // лямбда
x      => x * x // лямбда
(x)    => x * x // лямбда
(x, y) => x * y // лямбда

func1()     => z     // именованная функция
func2(x)    => x * x // именованная функция
func3(x, y) => x * y // именованная функция

// или 

def func1()     => z     // именованная функция
def func2(x)    => x * x // именованная функция
def func3(x, y) => x * y // именованная функция

еще варианты:

()     { z }     // лямбда
x      { x * x } // лямбда
(x)    { x * x } // лямбда
(x, y) { x * y } // лямбда

func1()     { z }     // именованная функция
func2(x)    { x * x } // именованная функция
func3(x, y) { x * y } // именованная функция

// или 

def func1()     { z }     // именованная функция
def func2(x)    { x * x } // именованная функция
def func3(x, y) { x * y } // именованная функция

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

XC>Что думаете?

Думаю, что вариантов много и многое будет зависеть от дизайнерского выбора авторов языка.

В данном вопросе влияние будут оказывать как другие конструкции языка (например, может быть конфликт который не даст выбрать тот или иной синтаксис), так и цели авторов.

Если цель быть ближе к С-шному синтаксису, то все эти изыски не очень хороши. Если цель создать унифицированный и удобный для чтения синтаксис, то вариантов очень много.

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

VD>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать.
В чем же их концептуальное различие?

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

VD>>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать.
D>В чем же их концептуальное различие?

У лямбды нет имени и без Y-комбинатора нельзя выполнить рекурсивный вызов.

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

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

VD>>>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать.
D>>В чем же их концептуальное различие?

H>У лямбды нет имени и без Y-комбинатора нельзя выполнить рекурсивный вызов.
inc = x -> x + 1
и вот у нас появилось имя, зачем нужно понятие функции если его можно постоить на базисе лямбды и переменной?

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

VD>>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать.
D>В чем же их концептуальное различие?

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

VD>>>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать.
D>>В чем же их концептуальное различие?

H>У лямбды нет имени и без Y-комбинатора нельзя выполнить рекурсивный вызов.

В свете этого:

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

Зачем их различать?

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

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

VD>>>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать.
D>>В чем же их концептуальное различие?

VD>В назначении. Лямбды, в основном, предназначены для передачи небольших кусков кода в другие функции. Функции же для декомпозиции и инкапсуляции кода. А уж глобальные функции и методы зачастую отличаются еще и семантически.
Как же тогда живется схеме у которой afaik функции — сахар поверх
(define inc (lambda (x) (+ x 1))

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

H>>У лямбды нет имени и без Y-комбинатора нельзя выполнить рекурсивный вызов.
D>inc = x -> x + 1
D>и вот у нас появилось имя, зачем нужно понятие функции если его можно постоить на базисе лямбды и переменной?

В ML языках по сути так и есть let просто связывает лямбду с именем.

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

FR>В ML языках по сути так и есть let просто связывает лямбду с именем.

А чтобы была рекурсия нужен костыль "let rec". Ну-ну.

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

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

FR>>В ML языках по сути так и есть let просто связывает лямбду с именем.

H>А чтобы была рекурсия нужен костыль "let rec". Ну-ну.
Это уже вопрос реализации.

var factorial = function (n){ 
if (n == 0)
   return 1;
  else
   return n * factorial(n-1);
}

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

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

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

FR>>>В ML языках по сути так и есть let просто связывает лямбду с именем.

H>>А чтобы была рекурсия нужен костыль "let rec". Ну-ну.
D>Это уже вопрос реализации.

Это хороший вопрос.

D>

D>var factorial = function (n){ 
D>if (n == 0)
D>   return 1;
D>  else
D>   return n * factorial(n-1);
D>}
D>

А как поступать в этом случае?

var factorial = function (x) { return x; }
var factorial = function (n) { 
if (n == 0)
   return 1;
  else
   return n * factorial(n-1); // на что ссылаемся?
}

ML без сигнатуры rec возьмет первое определение, с rec — второе.

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

FR>>В ML языках по сути так и есть let просто связывает лямбду с именем.

H>А чтобы была рекурсия нужен костыль "let rec". Ну-ну.

В других языках нужен еще больший костыль в виде объявления функции отличного от присваивания (или связывания) переменных, но он привычен поэтому бревно в глазу обычно не видно

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


H>А как поступать в этом случае?

H>

H>var factorial = function (x) { return x; }
H>var factorial = function (n) { 
H>if (n == 0)
H>   return 1;
H>  else
H>   return n * factorial(n-1); // на что ссылаемся?
H>}
H>

Что значит поступить? Открываем браузер и смотрим, логично что второе значение перезапишит первое. Правильно же делать что нибудь типа
immutable factorial =
H>ML без сигнатуры rec возьмет первое определение, с rec — второе.
Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.

VD>>>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать.
D>>В чем же их концептуальное различие?

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

Предполагая, что язык поддерживает ФВП:

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

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

function func1(param){
  print(param);
}

var func2 = func1;

var func3 = function(param){
  printf(param);
}


/* ------------ */


function test_f(func){
    // какая здесь разница, что мы сюда передаем — функцию или лямбду?
    // никакой
    func(1);
}


// какая здесь разница, что мы сюда передаем — функцию или лямбду?
// никакой
test_f(func1);
test_f(func2);
test_f(func3);
test_f(function(param){ print(param); });

Единственная «разница» между ними — это, возможно, желание писать меньше букв в месте определения лямбды.

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

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


H>>А как поступать в этом случае?

H>>

H>>var factorial = function (x) { return x; }
H>>var factorial = function (n) { 
H>>if (n == 0)
H>>   return 1;
H>>  else
H>>   return n * factorial(n-1); // на что ссылаемся?
H>>}
H>>

D>Что значит поступить? Открываем браузер и смотрим, логично что второе значение перезапишит первое. Правильно же делать что нибудь типа
D>immutable factorial =

Возможно это логично с точки зрения JS, что переменная factorial перезапишется (т.е. это будет одна и та же переменная), а вот с точки зрения Nemerle первое определение factorial попадет в замыкание:

def factorial = fun(x) { x }  // (1)
def factorial = fun (n) { 
if (n == 0)
  1
else
  n * factorial(n - 1) // вызов функции (1)
}

H>>ML без сигнатуры rec возьмет первое определение, с rec — второе.
D>Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.

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

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

XC>>функции (как глобальные так и локальные) просто описываются, а лямбды — как описываются, так и вызываются в месте своего описания.

VD>Это заблуждение становится весьма распространенным.
VD>На самом деле лямбды не вызываются в месте описания.

Забавно, я на самом деле конечно знал это и имел в виду... Но написал глупость.
Да, лямбды конечно же не "вызываются", а "передаются".

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

D>>Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.

H>Я лишь пытаюсь показать, что унификация объявления функций и лямбд так или иначе приведет к необходимости дополнительных синтаксических изощрений.
Я пока вижу только надуманые сценарии, для которых нужны синтаксические изощрений. Такое просто не должно компилироваться

Func<int, int> factorial = x => ...
Func<int, int> factorial = x => ... compile error

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

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

D>>>Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.

H>>Я лишь пытаюсь показать, что унификация объявления функций и лямбд так или иначе приведет к необходимости дополнительных синтаксических изощрений.
D>Я пока вижу только надуманые сценарии, для которых нужны синтаксические изощрений. Такое просто не должно компилироваться

D>

D>Func<int, int> factorial = x => ...
D>Func<int, int> factorial = x => ... compile error
D>

А такое?

def x = [1,2,3];
def x = x.Map(_.ToString());

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

H>А такое?
H>

H>def x = [1,2,3];
H>def x = x.Map(_.ToString());
H>

Помоему с этим будет больше проблем при чтении кода чем сомнительных бенефитов, особенно если они идут не последовательно, а разделены кодом.
def x =
def yForSomething =

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


H>>Я лишь пытаюсь показать, что унификация объявления функций и лямбд так или иначе приведет к необходимости дополнительных синтаксических изощрений.
D>Я пока вижу только надуманые сценарии, для которых нужны синтаксические изощрений. Такое просто не должно компилироваться

D>

D>Func<int, int> factorial = x => ...
D>Func<int, int> factorial = x => ... compile error
D>

В ML ноги этого растут из того что let по сути синтаксический сахар для безымянных лямбд, предназначенный для связывания лямбды с именем. Поэтому никаких ограничений по повторному использованию вносить нет смысла, и никаких неоднозначностей (кроме рекурсии которую надо явно указывать) это не вызывает. Кроме того механизм вывода типов в ML использует let-полиморфизм.

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

XC>Что думаете?

Я вот продумываю идею в свободное время набросать компилятор языка, в котором синтаксис функций будет синтаксисом меток:

name(arg:type, arg:type, ...):

При этом вызов функции это просто сохранение контекста, размещение параметров и переход, а восстановление контекста осуществляется по ближайшему return. В таком языке единственным возвращаемым типом был бы int, более сложные передавались бы через out-параметры. Мне кажется что такая идея позволяла бы в императивном стиле очень вкусный data-driven, потому что один return мог бы в зависимости от потока данных возвращать из одной-из-нескольких функций. Кроме того оптимизация такого кода была бы очень интересной -- написать хотя бы loop unrolling и tail-call recursion в таком случае превращается в весьма нетривиальный анализ зависимостей. Ведь разумеется я бы оставил вызов функции по указателю на неё любой косвенности.
Но всё руки не доходят.

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

D>inc = x -> x + 1
D>и вот у нас появилось имя, зачем нужно понятие функции если его можно постоить на базисе лямбды и переменной?

Затем же, зачем в большинстве языков можно кроме переменных описывать и константы. Обычное описание функции — это описание константы.

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

VD>>В назначении. Лямбды, в основном, предназначены для передачи небольших кусков кода в другие функции. Функции же для декомпозиции и инкапсуляции кода. А уж глобальные функции и методы зачастую отличаются еще и семантически.
D>Как же тогда живется схеме у которой afaik функции — сахар поверх
D>(define inc (lambda (x) (+ x 1))

Нормальные люди так не пишут, а используют специализированный синтаксис.

Потом языки разные бывают. Схема не даром не пользуется особой популярностью.

В Немереле, например, лямбды определены через локальные функции. Но методы являются отдельными сущностями. Они не поддерживают замыкания и поддерживают перегрузку. А раз так, то смысла в унификации синтаксиса нет.

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

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

VD>>>В назначении. Лямбды, в основном, предназначены для передачи небольших кусков кода в другие функции. Функции же для декомпозиции и инкапсуляции кода. А уж глобальные функции и методы зачастую отличаются еще и семантически.
D>>Как же тогда живется схеме у которой afaik функции — сахар поверх
D>>(define inc (lambda (x) (+ x 1))

VD>Нормальные люди так не пишут, а используют специализированный синтаксис.

VD>Потом языки разные бывают. Схема не даром не пользуется особой популярностью.

VD>В Немереле, например, лямбды определены через локальные функции. Но методы являются отдельными сущностями. Они не поддерживают замыкания и поддерживают перегрузку. А раз так, то смысла в унификации синтаксиса нет.
Конечно можно придумать язык у которого на каждый чих будет по сущности, но лично мне импонирует идея о минимальном базисе поверх которого макросами делается все остальное, по сути та же схема.

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

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

От того что методы, локальные функции и лямбды имеют немного разный синтаксис минималистичность базы особо не страдает.

Наличие пяти видов циклов на это куда больше влияет.

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

XC>Вопрос касается скорее "эргономики синтаксиса языка", чем философии... Два варианта:
XC>

int func(int x)

XC>vs
XC>

def func(int x) int

XC>Второй вариант немного длиннее, но ИМХО более удобен...
XC>Что думаете?

Удобнее, не удобнее, какая разница? Это не си-подобный синтаксис, и программирующие массы его отвергнут.

Если бы Nemerle назывался С## и типы записывались спереди, для него все могло бы сложиться по-другому. А так... боюсь, ПМ, everything is expression и макросы будут введены в обиход каким-нибудь C# 6.

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

VD>Когда я в первый раз увидел Nemerle, то меня покоробило использование такой "паскалевской" нотации. Но со временем я понял, что это действительно удобно и хорошо (и что это не паскалевская, а ML-ная нотация ).

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

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

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

SV.>А остальные 99% видят "паскалевскую" нотацию, говорят "шозанах" и закрывают мануал. И остаются в убеждении, что это паскалевская нотация.

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

SV.>Если это было больше, чем дипломная работа,

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

SV.>а именно — попытка популяризовать язык, большим просчетом было отличаться одновременно в большом, и в мелочах.

Какая-то витиеватая мысль. Можно ее пояснить?

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

SV.>>А остальные 99% видят "паскалевскую" нотацию, говорят "шозанах" и закрывают мануал. И остаются в убеждении, что это паскалевская нотация.

VD>Мне кажется, что если человек видя паскалевскую нотацию закрывает "мануал" и говорит "шозанах", то оно и слава богу, так как он все равно дурак. А проку от дураков не много. Ну, а не дурак будет разбираться по существу.

SV.>>Если это было больше, чем дипломная работа,

VD>Ты депломной работой называешь немерл? Ну, это говорит исключительно о тебе. Вообще-то немерл — это труд более чем тридцати программистов на протяжении ~ семи лет.

SV.>>а именно — попытка популяризовать язык, большим просчетом было отличаться одновременно в большом, и в мелочах.

VD>Какая-то витиеватая мысль. Можно ее пояснить?

Что тут пояснять? Все части связаны, просто не надо делать попытки нитпикинга.

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

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

SV.>Если разработка велась с академическими целями, то "оно", может, "и слава богу". Если целью была популярность, то начинать надо было помаленьку. Нововведений более, чем достаточно без смены нотации указания типа.

Когда начинали писать Немерле средств вроде PEG-а еще не было. Неоднозначности грамматики серьезно усложняли разработку расширяемого языка. Как я понимаю, многие синтаксические решения были приняты в том числе и под давлением желания избавиться от неоднозначность. Описание типов одна из таких возможностей. От туда же растут ноги и квадратных скобок для указания параметров типов и приведения типов. Везде где были неоднозначности были выбраны решения из ML-подобных языков. Там же где это было возможно взяли решения из C#.

SV.>Удобнее, не удобнее, какая разница? Это не си-подобный синтаксис, и программирующие массы его отвергнут.

Правда думаешь это решает? Программирующие массы пишут на чём им сказали, и не могут выбирать даже версию фреймворка. Тут вон люди которые понимают что за счёт Nemerle могут серьёзно выиграть, сетуют что всё супер, но им в конторе никто не даст на нём писать. Максимум выбивают на Nemerle всякие штуки по-мелочи вроде утилиток для внутреннего использования.

SV.>Если бы Nemerle назывался С## и типы записывались спереди, для него все могло бы сложиться по-другому. А так... боюсь, ПМ, everything is expression и макросы будут введены в обиход каким-нибудь C# 6.

Ну если в C#6 таки осилят что-либо дельное — то это же хорошо, меньше сил придётся потратить тем кто уже на Nemerle на популяризацию полезных вещей. Только вот как-то повелось что команда C# принимает вечно какието полу-решения, и ПМ в их реализации вполне может выродиться до switch/case по константам количеством от 1 до 3 .

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

SV.>Удобнее, не удобнее, какая разница? Это не си-подобный синтаксис, и программирующие массы его отвергнут.

Питон и руби как-то не отвергли. Да и бейсик не из-за синтаксиса теряет популярность.

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

SV.>>Удобнее, не удобнее, какая разница? Это не си-подобный синтаксис, и программирующие массы его отвергнут.

FR>Питон и руби как-то не отвергли. Да и бейсик не из-за синтаксиса теряет популярность.

Пять процентов и полтора? Си-подобные языки держат первые 4 места, при этом с контрольным пакетом (>50%). Что и называется — массовые. Вывод, по-моему, очевиден: если кто-то что-то хорошее придумает на языковом поприще, заворачивать надо в привычные си. Чтобы пипл хавал.

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

FR>>Питон и руби как-то не отвергли. Да и бейсик не из-за синтаксиса теряет популярность.

SV.>Пять процентов и полтора? Си-подобные языки держат первые 4 места, при этом с контрольным пакетом (>50%). Что и называется — массовые.

Откуда статистика?
Tiobe вообще шум меряет. Там D на котором никто ничего никогда ни писал в десятку входил.

SV.>Вывод, по-моему, очевиден: если кто-то что-то хорошее придумает на языковом поприще, заворачивать надо в привычные си. Чтобы пипл хавал.

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

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

SV.>>Пять процентов и полтора? Си-подобные языки держат первые 4 места, при этом с контрольным пакетом (>50%). Что и называется — массовые.

FR>Откуда статистика?
FR>Tiobe вообще шум меряет. Там D на котором никто ничего никогда ни писал в десятку входил.

Шум значит, что интерес есть. Пробовали, крутили, вертели, выкинули. Это важно. А нет шума — будет Nemerle. Крутой язык, с крутыми фишками, но настолько малоизвестный, что публикаций насобирать даже на прописку в wiki не смогли.

SV.>>Вывод, по-моему, очевиден: если кто-то что-то хорошее придумает на языковом поприще, заворачивать надо в привычные си. Чтобы пипл хавал.

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

Не помню такого. Всегда какие-то скрипты писали, прототипы. В мейнстрим он никогда не проникал.

Причем тут мейнстрим? Целься в мейнстрим, человек сто может и не обломятся разбираться с твоим языком. Не целься — будешь сам на нем писать. Каким бы эргономичным не был синтаксис.

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

SV.>Шум значит, что интерес есть. Пробовали, крутили, вертели, выкинули. Это важно. А нет шума — будет Nemerle. Крутой язык, с крутыми фишками, но настолько малоизвестный, что публикаций насобирать даже на прописку в wiki не смогли.

D несмотря на шум примерно в том же положении. Да и Go не сильно далеко ушел.

SV.>Не помню такого. Всегда какие-то скрипты писали, прототипы. В мейнстрим он никогда не проникал.

10 лет назад под винды за бугром пишущих на VB было чуть ли не больше чем на C/C++, у нас это место занимал Delphi.

SV.>Причем тут мейнстрим? Целься в мейнстрим, человек сто может и не обломятся разбираться с твоим языком. Не целься — будешь сам на нем писать. Каким бы эргономичным не был синтаксис.

1 из 100 освоит — это будет уже весьма популярный язык.

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

XC>Еще этот вариант хорош тем, что красиво реализуются всякие множественые возвращаемые значения и т.п.

А какие проблемы с множественными возвращаемыми значениями? В C# прикрутили, наконец, анонимные типы. В С++ отродясь можно было юзать неанонимные:

struct Result{int x, y;} someFunc() {  
  Result result={1, 2}; 
  return result; 
}