(Извиняюсь, но просто не знаю в какой форум это нужно постить)

Вот сделал в скрипте (tiscript) slicing в стиле D:

var s = "Hello Universe";
var s1 = s[6..12];
assert(s1 == "Univer");

Вопрос следующий: часто нужно делать slicing c открытой границей,
у меня сейчас это сделано так:

var s2 = s[..5];
assert(s2 == "Hello");

var s3 = s[6..];
assert(s3 == "Universe");

Какие будут у народа мысли по поводу идеологической чистоты этого
безобразия?

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

CS>var s1 = s[6..12];
CS>var s2 = s[..5];
CS>var s3 = s[6..];

CS>Какие будут у народа мысли по поводу идеологической чистоты этого
CS>безобразия?

Ну, прямо как в Python.
Только там двоеточие не горизонтально, а вертикально ориентировано

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

B>Ну, прямо как в Python.
B>Только там двоеточие не горизонтально, а вертикально ориентировано

и в PCRE, только там запятая...

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

B>Здравствуйте, c-smile, Вы писали:

CS>>var s1 = s[6..12];
CS>>var s2 = s[..5];
CS>>var s3 = s[6..];

CS>>Какие будут у народа мысли по поводу идеологической чистоты этого
CS>>безобразия?

B>Ну, прямо как в Python.
B>Только там двоеточие не горизонтально, а вертикально ориентировано

Только ещё надо завернуть индексацию в кольцо, ввести отрицательные индексы и обработку невалидных интервалов

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

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

B>>Здравствуйте, c-smile, Вы писали:

CS>>>var s1 = s[6..12];
CS>>>var s2 = s[..5];
CS>>>var s3 = s[6..];

CS>>>Какие будут у народа мысли по поводу идеологической чистоты этого
CS>>>безобразия?

B>>Ну, прямо как в Python.
B>>Только там двоеточие не горизонтально, а вертикально ориентировано

RK>Только ещё надо завернуть индексацию в кольцо, ввести отрицательные индексы и обработку невалидных интервалов

"завернуть индексацию в кольцо" а зачем? я что-то глобальное пропустил?

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

CS>Здравствуйте, R.K., Вы писали:

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

B>>>Здравствуйте, c-smile, Вы писали:

CS>>>>Какие будут у народа мысли по поводу идеологической чистоты этого
CS>>>>безобразия?

B>>>Ну, прямо как в Python.
B>>>Только там двоеточие не горизонтально, а вертикально ориентировано

RK>>Только ещё надо завернуть индексацию в кольцо, ввести отрицательные индексы и обработку невалидных интервалов

CS>"завернуть индексацию в кольцо" а зачем? я что-то глобальное пропустил?

Это я просто изобрел несуществующую фичу в Питоне

>>> a=[0,1,2,3,4]
>>> a[-4:4] # так можно
[1, 2, 3]
>>> a[4:-4] # и так можно, но вернет пустой список
[]

И вообще, индексация списков выглядит не самым эффективным способом их обработки. Или это не связные списки?

PS Python начал изучать совсем недавно.

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

RK>И вообще, индексация списков выглядит не самым эффективным способом их обработки. Или это не связные списки?

Это обычные векторы или индексируемые (целым числом) коллекции.
Понятно что для hash map это уже не подходит.

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

CS>Это обычные векторы или индексируемые (целым числом) коллекции.
CS>Понятно что для hash map это уже не подходит.

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

Т.е. получается, что "5.." и "1..2" — это полноценные объекты, представляющие список значений ключей. Это означает, что можно скармливать в телефонную книгу такие выражения:

phonebook["Иванов".."Петров"]
phonebook["Булгаков"..]

Ну как, вполне безумно?

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

S>phonebook["Иванов".."Петров"]
S>phonebook["Булгаков"..]
S>Ну как, вполне безумно?

Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений. Разве сделать вместо строк специальные объекты с перегруженной операцией __slice__, но полезность вообще для меня сомнительна Вот для числовых индексов это чрезвычайно удобно.

Здравствуйте, Кодёнок, Вы писали:
Кё>Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений.
Не, список значений надо делать из списка ключей, фильтруя по предикату key>="Иванов" && key<= "Петров".

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

CS>Какие будут у народа мысли по поводу идеологической чистоты этого
CS>безобразия?

Чудненько

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

S>Здравствуйте, Кодёнок, Вы писали:
Кё>>Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений.
S>Не, список значений надо делать из списка ключей, фильтруя по предикату key>="Иванов" && key<= "Петров".

Технически это возможно. Практически надо ли?
Принимая во внимание
1) array.sort([func]) наличествует и в нем можно использовать custom sort func.
2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется).

По поводу последнего вот кстати вопрос: нужно придумать способ расширения синтаксиса
другими языками (если сие в принципе возможно и нужно).

Т.е. хотелось бы например (и технически возможно) иметь конструкции вида:

var val = ...;
var rs = db_connection <- select one,two from tbl where one = @val;

хотя по мне, например, и так тоже нормально ( и меньше неоднозначности ):

var rs = db_connection.queryf( "select one,two from tbl where one = %s", val);

( queryf это фактически query + printf )

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

CS>2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется).

CS>По поводу последнего вот кстати вопрос: нужно придумать способ расширения синтаксиса
CS>другими языками (если сие в принципе возможно и нужно).

В Tcl (tclodbc), например, так сделано:

% database connect db "DRIVER=SQL Server;SERVER=dbs1;DBQ=mydb"
  db
% db "select id from employees where salary < 1000"
  {222 333 444}
% db disconnect

Здравствуйте, c-smile, Вы писали:
CS>Принимая во внимание
CS>1) array.sort([func]) наличествует и в нем можно использовать custom sort func.
Это просто попытка поднять слайс на более высокий уровень абстракции.
В нем предполагается, что слайсить можно любую коллекцию, если она индексируется упорядоченными ключами.
Например, массив — это частный случай коллекции, индексированной целыми числами.

CS>2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется).
Ну, слайсинг к языку запросов прямого отношения не имеет. По поводу вмуровывания запросов в язык, имхо, лучшее достижение — LINQ (C#3).

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

S>Здравствуйте, c-smile, Вы писали:
CS>>Принимая во внимание
CS>>1) array.sort([func]) наличествует и в нем можно использовать custom sort func.
S>Это просто попытка поднять слайс на более высокий уровень абстракции.
S>В нем предполагается, что слайсить можно любую коллекцию, если она индексируется упорядоченными ключами.
S>Например, массив — это частный случай коллекции, индексированной целыми числами.

В принципе языки семейства JavaScript имеют только одну коллекцию.
Технически, например, JScript (в IE) использует hash tables и для массивов тоже (эдакий sparse array).
Т.е. ranges там не так эффективны как хотелось.

Если же говорить про ranges для произвольных ключей то нужно еще как-то
уметь задавать фуннкцию отношения (less) что сильно утяжеляет всю конструкцию.

Когда я говорю про SQLite то предполагается что задачи типа a["one"..."three"]
могут эффективнее всего делаться в нем потому как 1) SQLite имеет механизм in-memory tables
2) SQLite/scripting позволяет описывать функции less в самом скрипте.
Т.е. select v from tbl where v >= "one" and v < "three"
может звать custom функцию.


CS>>2) Скорее всего в язык и рантайм будет "вмурован" SQLite (дискутируется).
S>Ну, слайсинг к языку запросов прямого отношения не имеет. По поводу вмуровывания запросов в язык, имхо, лучшее достижение — LINQ (C#3).

Это уж слишком круто. Так далеко (в т.ч. по объему требуемого кодирвания) смысла идти особого нет я думаю.

Скорее всего я остановлюсь на традиционном

var rs = db_connection.queryf( "select one,two from tbl where one = %s", val);

Ибо дешево и сердито.

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

CS>>По поводу последнего вот кстати вопрос: нужно придумать способ расширения синтаксиса
CS>>другими языками (если сие в принципе возможно и нужно).

ANS>В Tcl (tclodbc), например, так сделано:

ANS>

ANS>% database connect db "DRIVER=SQL Server;SERVER=dbs1;DBQ=mydb"
ANS>  db
ANS>% db "select id from employees where salary < 1000"
ANS>  {222 333 444}
ANS>% db disconnect
ANS>

Хммм... насколько я вижу это стандартный способ когда
запрос это строка в терминах host языка (script per se)...
Или я чего не разглядел?

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

ANS>>В Tcl (tclodbc), например, так сделано:

ANS>>

ANS>>% database connect db "DRIVER=SQL Server;SERVER=dbs1;DBQ=mydb"
ANS>>  db
ANS>>% db "select id from employees where salary < 1000"
ANS>>  {222 333 444}
ANS>>% db disconnect
ANS>>

CS>Хммм... насколько я вижу это стандартный способ когда
CS>запрос это строка в терминах host языка (script per se)...
CS>Или я чего не разглядел?

Теперь уже не знаю насколько это соотносится с тем, что ты хотел
В tclodbc всё зависит от первого параметра. Если это не команда (как "disconnect"), то считается, что это SQL запрос.

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

S>Здравствуйте, Кодёнок, Вы писали:
Кё>>Я не понимаю, как из "Иванов".."Петров" можно (однозначно) построить список значений.
S>Не, список значений надо делать из списка ключей, фильтруя по предикату key>="Иванов" && key<= "Петров".

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

Здравствуйте, VladD2, Вы писали:
VD>Только для таких выкрутасов нуже лучше использовать сортированные массивы или деревья. Но не как не хэш-таблинцы.
Дык это уже implementation-specific. Мне такие фичи тем и нравятся, что пишешь некоторый код, а уж потом натравливаешь профайлер. Если результат тебя не устраивает — заменяешь хэшмэп сортированным массивом или деревом.

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

S>Дык это уже implementation-specific. Мне такие фичи тем и нравятся, что пишешь некоторый код, а уж потом натравливаешь профайлер. Если результат тебя не устраивает — заменяешь хэшмэп сортированным массивом или деревом.

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

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